next »

[substract]

Hi
I also wanted to thank you for your feedback and nice words
You have an interesting project, I am just afraid I'm not able to give much feedback because this is not the kind of game I have been playing too much. I certainly like the Idea of discovering mysterious unknown places, though

[Thaumaturge]

Hi. ^_^

It's my pleasure, and thank you for your kind words on my project in turn! Don't worry if it's not your sort of game; I doubt that any game is to everyone's tastes. ^_^

[Thaumaturge]

Blog post (20th of November, 2017)
Lighting, Colours, and Textures

Greetings and salutations!

For this week's screenshot, a look at a change made to the lighting of darker areas under the sun-light:



The work of the week just past was somewhat of a miscellany, almost all focussed on level-geometry and shaders, but across a variety of individual elements.

First, however, a salient change that is not related to level-geometry or shaders: There is now a "Goal" tab in the "Collections" screen, which holds a brief description of the player's current objective. Along with this is a new popup, informing them when this text changes.

This does use an entire tab for a single, brief piece of text, but I think that it may be useful, and I didn't see a better place for it. It was tempting to add it to the "Inventory" tab, which has space, but I felt that this would be a rather unobvious place to look for a reminder of one's goal.

I was also tempted to put the new tab to greater use, adding in further notes discovered over the course of a level. However, I think that I felt this to be a bit too much of an addition to the game at this stage in development.

Moving on to matters of the first level, work continues on the woods that surround the barrow. These are coming along, I do think.

One element that I'm particularly happy with is the use of a "noise image" to vary the colour of the trees. I had previously achieved this via a shader input applied to each individual tree-top, and this worked well enough. However, I realised that it had a problem: For performance reasons, I wanted to merge the trees into a few large chunks, reducing the number of nodes in the scene-graph. But in doing so, I would of course lose those individually-applied input-values, since there would no longer be individual nodes to which to apply them.

So what I now have is a texture that is sampled to replace that shader-input, using the world-space coordinates of the trees' vertices to generate coordinates. This seems to work well, and has the additional advantage that these colour-offsets blend into each other, rather than changing sharply from one tree to the next.

Unfortunately, the woods are currently somewhat broken: I'm trying to squeeze some additional data in via multiple sets of texture-coordinates, but for some reason I'm not getting that data out in my shaders. I've asked for help on the Panda3D forum, and am waiting for a reply!

I've shown my sky-shader before, I believe. Something that I've been unsatisfied with in it has been the lack of clouds--the sky is always entirely clear. In the week just past I gave some time to addressing that.

My first attempt, as I recall, was to generate them in the shader itself, using a noise-texture as their basis. This proved quite difficult: creating cloud-like forms wasn't a major problem, but generating texture-coordinates that spread them across the sky in appropriate fashion proved more troublesome. In the end I gave up on this approach.

Instead, what I've done is somewhat simpler, and in many ways rather easier: Clouds are represented via flat geometry with an appropriate texture applied, tagged to be treated as part of the "view" (much like the surrounding countryside in the prologue level). "View" objects are automatically attached to the sky-object, and thus remain in place as the player moves, giving the impression of distance. Painting the clouds themselves proved a minor challenge, but I think that I'm fairly happy with the result.

The sunlight shader saw two changes that I'd like to mention:

First is a "saturation" value, stored in vertex colours. This allows me to selectively desaturate certain elements, thus varying their colours a little bit. I added it for use on the trunks of the woodland trees, as I recall, but I could see it being used elsewhere in future.

Second is a change to the lighting: where before parts of a model that were turned away from the sun-light were uniformly dim, they are now darker the more they're turned from it. This, I feel, gives darker areas a little more shape than they previously had, and allows their normal-maps to show. The effect is, however, still somewhat experimental and probationary.

I also did a little work on two of the level's 3D models, finishing off the the wooden keys used to access the upper tombs and a small hinged box in which some important items are found. (Although the latter might see some touch-ups.)

And finally, a few other things were done that don't seem worth further lengthening this post!

That then is all for this week--stay well, and thank you for reading! ^_^

[Thaumaturge]

Blog post (27th of November, 2017)
Lots of Trees

Greetings and salutations!

For this week's screenshots, a few images showing progress on the woodland surrounding the first level:




It's still a work-in-progress--note the lack of ground or undergrowth--but it's coming along, I do think. ^_^

Once again, most of the work done in the week just past was focussed on filling out the outdoors section of the first level, with various digressions into other matters.

First of all, I believe that I mentioned last week that I was having some trouble accessing data stored in extra UV-maps. This has been dealt with, thanks to help from the Panda3D forum! It appears that accessing the extra UV-maps calls for them to be associated with a texture--but that's not the solution that I'm using.

Instead, it turns out that there's an easier way, a means of essentially providing extra layers of vertex-colours. With some minor changes to the model-exporter that I use, I'm now able to store the data that I want in these additional layers, and access them in the relevant shader!

Speaking of shaders, I continued to work on the base "sunlight" shader. And in testing some changes, I discovered bugs in the shaders as applied to the prologue level, bugs that likely pre-dated the changes being tested. :/

It took some work, but I did find solutions to them in the end, I believe.

(I also discovered and fixed, I believe, a minor bug in how I calculated highlights in the sunlight shader.)

On the technical side, I've made steps, I believe, towards dealing with a long-standing problem. I believe that I've mentioned before that objects straddling the borders of the cells used for portal-culling are in a somewhat uncertain state: to which cell--if any--should they belong?

As I recall, I had previously decided to leave certain such objects outside of portal-culling, meaning that they would always be rendered, as long as they were within view. But I wasn't entirely happy with this. For one thing, while fine in the first level, in larger levels it potentially left a fair few objects to be always-rendered.

So, going by advice given on the Panda3D forum, I started in on a new approach in the week just past. It turns out that there are ways of giving a single object multiple "parent-nodes" in Panda3D, allowing me to attach objects on cell-borders to both cells. My method of doing so right now is simple: a tag attached to the object, naming its parent-cells. It's clunky, but it works.

There are still a few problems: The first is that such objects are rendered once per "parent", which is not ideal. It remains to be seen whether this will actually be a problem, however, and I have a potential solution in mind if it is. The second problem is that my current method results in at least one of those renderings being incorrectly placed. Once again, I'm seeking advice on the Panda3D forum regarding this.

Otherwise, as previously mentioned, a fair bit of work went into the level-geometry itself, and some of the scripting for the level. The woods are filling out, the stone pillars have their faded animal signs, and more besides.

Perhaps my favourite bit of this is a tree used for traversal near the back of the "courtyard". Up until now it's been a fairly basic model, just describing the related collision geometry. It has now been filled out to look like a tree (and some tweaks made to said collision geometry), and I actually find that it feels fun to climb! ^_^

(You should be able to see this tree near the bottom-right of the first screenshot above.)

As per usual, other changes were made that don't seem worth mentioning here!

That's all then for this week--stay well, and thank you for reading! ^_^

[Pixel Noise]

It's definitely "coming along"; I think it's looking pretty nice already! Will look great once you get some undergrowth and other detail in there.

[Thaumaturge]

Thank you very much! That's good to read. ^_^

Alas, I seem to have hit a performance issue, and while I'm still working on finding the cause, it looks as though it may be in my treetops. If so, I may end up simplifying them in some way. :/

[edit]
I'll admit that I'm glad that this should be the last level that has a surrounding forest. As much as I love them (and I do!), forests can be a pain in level-building, it seems! ^^;

(Indeed, the next level takes place entirely indoors. Sort of.)

[io3 creations]

Thank you very much! That's good to read. ^_^

Alas, I seem to have hit a performance issue, and while I'm still working on finding the cause, it looks as though it may be in my treetops. If so, I may end up simplifying them in some way. :/

[edit]
I'll admit that I'm glad that this should be the last level that has a surrounding forest. As much as I love them (and I do!), forests can be a pain in level-building, it seems! ^^;

(Indeed, the next level takes place entirely indoors. Sort of.)

Are the leaves separate polygons that are completely filled or use partially transparent textures?  Either way, those seem to add a lot of extra polygons, hence performance will more than likely decrease.  Chances are, you have to use a simpler tree model.

[Thaumaturge]

Are the leaves separate polygons that are completely filled or use partially transparent textures?  Either way, those seem to add a lot of extra polygons, hence performance will more than likely decrease.  Chances are, you have to use a simpler tree model.

Do you mean a polygon for each individual leaf? No, far from it!

What I had was about three polygons per leaf-cluster, with a texture applied that depicted a few twigs and a bunch of leaves. However, I fear that I had too many of these, the leaf-clusters being too small. :/

(I also had simpler geometry that was used at range, but that doesn't seem to have been a major issue, I believe.)

I'm currently working on simpler geometry, trying to find something that looks halfway-decent, and also performs well.

[io3 creations]

Do you mean a polygon for each individual leaf? No, far from it!

Yes, that was one of my guesses. 

What I had was about three polygons per leaf-cluster, with a texture applied that depicted a few twigs and a bunch of leaves. However, I fear that I had too many of these, the leaf-clusters being too small. :/

Yes, if you have many, that will of course need more performance.  But one possibility might be the use of partially transparent images.  If you want, you could use texture images with no transparency to see if that makes a difference.

Other than that, as you mentioned, going with simpler geometry will likely be the way.

[Thaumaturge]

Yes, that was one of my guesses.

Fair enough! As I said, I wasn't going quite that far!

Yes, if you have many, that will of course need more performance.  But one possibility might be the use of partially transparent images. 

Indeed--it's a matter of balance, I suppose. I fear that I had leaned a little too far away from performance in search of beauty, and now am pulling back in the other direction.

If you want, you could use texture images with no transparency to see if that makes a difference.

Hmm... I'm not quite sure of how this would work. Would you mind elaborating, please?

Without transparency, and without using a ridiculous number of vertices per tree, how would I represent leaves without transparency? The only way that I see is some sort of low-poly aesthetic, which would be a significant change from my current intended aesthetic.

Other than that, as you mentioned, going with simpler geometry will likely be the way.

Indeed! It's less pretty, I fear, but it performs far better. (It is still a work-in-progress right now, admittedly.)

[io3 creations]

Indeed--it's a matter of balance, I suppose. I fear that I had leaned a little too far away from performance in search of beauty, and now am pulling back in the other direction.

While the average computer is quite fast now, chances are good that performance considerations and optimizations will be part of the game development process, even if you set your minimum requirements reasonable high. 

If you want, you could use texture images with no transparency to see if that makes a difference.

Hmm... I'm not quite sure of how this would work. Would you mind elaborating, please?

Oh, I meant that for determining if the transparent images caused the performance issue.  Or if you were curious what is the performance impact of using transparent images.

[Thaumaturge]

While the average computer is quite fast now, chances are good that performance considerations and optimizations will be part of the game development process, even if you set your minimum requirements reasonable high.

Indeed. And indeed, I've done a few rounds of optimisation in this project before this one.

(I'm actually not setting my requirements very high, I don't think. That said, I don't have a specific "minimum specification"--my current rough goal is to try to keep the game above 70fps in most views on my machine, I think.)

Oh, I meant that for determining if the transparent images caused the performance issue.  Or if you were curious what is the performance impact of using transparent images.

Ah, I see. Thank you for explaining!

If I recall correctly, I checked which elements were causing the problem by simply exporting the level (or rather the chunk that I' currently working in) with various pieces omitted, noting the change in performance for each.

[io3 creations]

Indeed. And indeed, I've done a few rounds of optimisation in this project before this one.

(I'm actually not setting my requirements very high, I don't think. That said, I don't have a specific "minimum specification"--my current rough goal is to try to keep the game above 70fps in most views on my machine, I think.)

Sounds good. 

Come to think of it, I remember some devs mentioning targeting 60fps at 1680x1050 (or 1920x1080?).  That would probably imply a certain minimum hardware requirement, but it's good to have something concrete that you can use for benchmarking.  As you saw with your forest implementation.

[Thaumaturge]

Heh, I'm not sure that either of my monitors will reach those resolutions! XD;

(At the moment I'm running in a 1280x720 window.)

Of course, it may be worth mentioning that these tests aren't distributable builds--they're running via the SDK (which I imagine has debugging elements slowing it a little), and with the IDE in the background. A distributable build, lacking these impediments, may perhaps run a little faster still.

[io3 creations]

You're right.  The extra IDE do add to CPU usage.  Thought, the gain will vary based on the project. 

I find it's a good idea to create builds from time to time to make sure that everything works as expected.

On a similar note, have considered at least the aspect ratio - i.e. do you use only one screen aspect ratio or allow the game to display full screen with any ratio?

[Thaumaturge]

I find it's a good idea to create builds from time to time to make sure that everything works as expected.

That's probably not a bad idea, but making a distributable build can take some time, I find. (But then perhaps I'm a little spoiled by the fact that my engine of choice uses Python, allowing me to run via the SDK without waiting for compilation.)

On a similar note, have considered at least the aspect ratio - i.e. do you use only one screen aspect ratio or allow the game to display full screen with any ratio?

As I said, I'm running in a window at the moment, so the game's aspect ratio doesn't necessarily match that of the monitor. I can set the game to run in full-screen, but for some reason my configuration (Ubuntu Linux with a NVidia card and two monitors) doesn't like changing the resolution of a full-screen window, it seems--or otherwise I'm doing so incorrectly. As a result, it seems that for now it runs in full-screen, but at whatever resolution the computer wants to run at.

I've also had some trouble getting a list of available window-sizes under my current configuration, an issue that I have yet to get around to dealing with. For now I have a pre-set list of resolutions, including the one mentioned in my post above.

(I'm not sure that I've tested either issue under Windows just yet.)

That said, I haven't tested these issues for a while, so it's possible that driver updates since last I tested them have fixed one or both.

[io3 creations]

I find it's a good idea to create builds from time to time to make sure that everything works as expected.

That's probably not a bad idea, but making a distributable build can take some time, I find. (But then perhaps I'm a little spoiled by the fact that my engine of choice uses Python, allowing me to run via the SDK without waiting for compilation.)

That's why you'd do only once in a while.    Technically, it would be to make sure that you can catch issues early on  i.e.  with fewer new changes made, there are less "new issues" and it is easier to track down what could be the cause.  Unlike if you wait until the end when potentially many issues appear and you may not be sure why.  Especially, if you release the game on systems (e.g. consoles) where you don't even have the same access to the IDE (e.g. console).

Out of curiousity, how long does it take the make a build (obviously for the current game)

On a similar note, have considered at least the aspect ratio - i.e. do you use only one screen aspect ratio or allow the game to display full screen with any ratio?

As I said, I'm running in a window at the moment, so the game's aspect ratio doesn't necessarily match that of the monitor. I can set the game to run in full-screen, but for some reason my configuration (Ubuntu Linux with a NVidia card and two monitors) doesn't like changing the resolution of a full-screen window, it seems--or otherwise I'm doing so incorrectly. As a result, it seems that for now it runs in full-screen, but at whatever resolution the computer wants to run at.

I've also had some trouble getting a list of available window-sizes under my current configuration, an issue that I have yet to get around to dealing with. For now I have a pre-set list of resolutions, including the one mentioned in my post above.

(I'm not sure that I've tested either issue under Windows just yet.)

That said, I haven't tested these issues for a while, so it's possible that driver updates since last I tested them have fixed one or both.

That's true.  It's good to give resolution options to players, though, I was wondering also if you considered how that effects the gameplay.  For example, if you have UI elemnts that let's say are fixed to the left edge of the screen on a 16:10 aspect ratio, then those elements may not be visible on a lower aspect ratio.  For some reason, sometimes Unity games only give me 3:2 ratios and had a few times then I couldn't select button or see certain UI elements.  So, if the aspect ratio is fixed, in full screen mode does your game have black lines either on the sides or top/bottom?

That said, I haven't tested these issues for a while, so it's possible that driver updates since last I tested them have fixed one or both.

True.  Though, due to various system configurations there's always the possibility that only a few people will have issues.  You've probably seen those Not Recommended reviews on Steam where people say that the game crashes ... even though for 99.999% the game runs fine.

[Thaumaturge]

That's why you'd do only once in a while. ...

That's fair enough, all. Perhaps I should consider doing (very) occasional distributable builds.

Out of curiousity, how long does it take the make a build (obviously for the current game)

Honestly, I'm not sure--I don't think that I've ever timed it, for this game or another. Long enough that I tend to do something else while it works, at least. (Much of the time seems to be spent on downloading various packages.)

That said, I believe that the new version of the engine (which I'm likely to move over to soon) has a new build system, so who knows how things will be under that!

It's good to give resolution options to players, ...

And I intend to! That I haven't gotten around to dealing with the issue in question doesn't mean that I won't.

(And if I don't, I at the least have my current pre-defined list of resolutions, which I think includes both wide-screen and non-wide-screen options.)

... though, I was wondering also if you considered how that effects the gameplay.  For example, if you have UI elemnts that let's say are fixed to the left edge of the screen on a 16:10 aspect ratio, then those elements may not be visible on a lower aspect ratio.  For some reason, sometimes Unity games only give me 3:2 ratios and had a few times then I couldn't select button or see certain UI elements.  So, if the aspect ratio is fixed, in full screen mode does your game have black lines either on the sides or top/bottom?

The aspect ratio isn't fixed, and I think that I have the UI largely adjusting to various resolutions. I tend to design for non-wide-screen monitors, leaving space on either side. In addition, I have some code that automatically resizes at least some of my UIs (I forget whether I've tested this with all) such that they're always entirely visible, even if that means shrinking them a bit.

True.  Though, due to various system configurations there's always the possibility that only a few people will have issues.

Indeed--although having the issue crop up on my machine makes it hard to test the case in which it doesn't!

[Thaumaturge]

Blog post (4th of December, 2017)
Revisions and Simplifications

Greetings and salutations!

For this week's screenshot, further progress on the woods surrounding the first level:



You may note that the trees look somewhat simpler than they did last week, and you would be quite correct in doing so. Let me explain:

A big part of the week just past was cycles of reworking both the trees and the undergrowth, for both aesthetic and performance reasons.

The most salient change is perhaps in the trees. Alas, I discovered that as they were, the game's performance was not to my satisfaction. (I think that I was seeing around forty-five to fifty frames per second in some views.) So, though it pained me a little to lose the more detailed trees that I previously had, I rebuilt them with simpler geometry. They're less lovely, perhaps, and I lose the effect of leaves moving aside as the player passes through them, but they do at least seem to perform well enough.

I don't think that I've yet tested performance with the grass present, or the tomb-interiors, so it's possible that further rounds of optimisation may be done at a later stage.

As for the undergrowth, I also simplified what I had there--while not, I think, a major performance problem, I recall that I did want a lower vertex-count than I had.

However, the major revision to the undergrowth was aesthetic: I simply wasn't happy with the appearance of the foreground bushes that I had. While they looked fine enough by themselves, I think that I found them to not blend well into the more distant shrubbery. So I reworked them, and I think that I like their new look.

There's one little trick that I'm quite happy with, used in both the undergrowth and tree-tops: You see, the transparency for these is thresholded, allowing me to get away with not sorting them for depth. The trick, then, is to adjust that threshold according to the fragment's distance from the viewer. The further away it is, the lower the threshold, allowing more of the image to show through. This results in leaves and bushes "solidifying" in the distance, becoming less "bitty", and perhaps a little more "painterly".

(That thresholding is at least in part, as I recall, in response to learning that the "discard" shader command and associated use of "if-statements" in shaders is perhaps a bad idea for performance.)

As shown above, I also set about building the forest floor. Dealing with the transition from leaf-litter in the foreground to the vague greenness of the background took a few attempts, but I think that what I have works.

The woodland isn't quite done yet, I intend, but once again, I feel that it's coming along!

And as is commonly the case, there were a few things done that don't seem worth mentioning here.

That then is all for this week--stay well, and thank you for reading! ^_^

[Grhyll]

Damn, I wanted to update myself on your project, but I'll confess it's a bit too late for me to read those walls of texts ^^' Maybe you should consider doing a short tldr at the end of your posts :D Anyway, at least I've taken a look at the screenshots, and it's nice to see you're still making good progress