next »

[Thaumaturge]

Blog post (25th of June, 2018)
The Deadly Window-Merging Script

Summary: In which a lot of little things are done, including: textures are updated and added; as too are sounds; the player-light shaders are tinkered with; level two's exit is near-complete; a script merges windows; the window-merging script causes trouble; and some work is done on Panda3D's particles.

Greetings and salutations!

For this week's screenshot, some touch-ups to the look of level two:




The week just past was another of those in which I worked on many little things, with no single central thrust to them:

To start with, aesthetic work for level two continued:

A few new textures were added, including versions of the "grey wood" and "sandstone" texturing that lacked the grooves that describe planks or blocks.

With appropriate wood-textures made, I also re-exported the ladder model so that it used them, along with some touch-ups to the model itself.

Perhaps more saliently, I significantly reworked the block-edges in my "sandstone block" textures: I felt that the previous attempt was a little too uneven, and so remade the edges, but a little straighter this time. (The results are shown above.)

I also tinkered with the player-light shaders a little. In the end, the only change that I kept was an increase to the strength of the normal-quantisation.

As to level two itself, I began implementing the exit to the level--a piece of design that had been troubling me up until the week just past. Now it's a leap from a box placed on a low rooftop into an open window; then down a ladder to find something bigger to stand on (the bigger thing hasn't yet been added); up through a broken floor; and then finally up the outside of the building (likely using the bigger thing a second time) to reach the hole by which the player originally entered.

I also removed some of the static windows that should be left open for traversal.

At one point in the level there is a cache of books hidden behind a stone plate. This had been implemented before I created the stone-block textures, and so didn't match up with them. Thus, I adjusted the plate, the gap behind, and the logical objects involved to be aligned to the textures in question.

One problem that I've been facing is that I haven't wanted to export the level due to the number of scene-nodes that the various separate windows add. Conversely, I've been hesitant to merge the windows until I had a good idea of which I would be keeping, and which I would be replacing.

In the week just past, an idea came to me that largely solves this issue: I wrote a script to seek out the various windows (and their frames and attached parts), and then automatically merge them in a somewhat-appropriate manner. It takes a little time to run, but it seems to work well, I believe!

(I am still left with quite a few nodes even so, I'm afraid; this is something that I may want to look into at some point.)

There was a complication during the development of this script: When I ran it, it would run... and keep running... and continue to run. I think that I recall it even locking up the computer while it worked. Until, at long last... it would crash Blender.

Eventually I realised what was (presumably) happening: The windows all share a single mesh. Thus, as successive groups of windows were merged, they gained the vertices of previous groups, and so the windows accumulated, and accumulated further. Thus each merging likely became more taxing, and each merged result became a heavier load for the system--until at last Blender keeled over under the strain.

The fix was fairly simple: as part of the process, the script now copies each window's mesh, making it unique. Thus the windows don't accumulate, and the script completes successfully!

I also did a little sound-work in the week just past, focussing on the noises made while climbing. I added some new sounds for catching onto climbable geometry (and implemented logic for their playing), tweaked some old "climbing" sounds, and removed a few sounds that I didn't like.

At the end of the week, I spent a little time on something not (directly) related to A Door to the Mists: One thing that annoys me about Panda3D's particle system is that it doesn't explicitly support the emission of singular "bursts" of particles--imagine a ring of dust being sent out when a character lands, or sparks bursting from a wall when hit by bullets.

I had already put in a feature request for this, but I decided to take a shot at it myself. In the end, my solution was fairly simple, and seems to work. I've provided a patch of the changes to the Panda3D devs, and am awaiting feedback.

And once again, there were things done that don't seem worth mentioning here.

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

[Thaumaturge]

Blog post (2nd of July, 2018)
The Round-About Route

Summary: In which a traversal-route in level two sees work; windows are unified; chairs are made; doors and windows see work, and an interactive one each is added to the level; and I experiment with the title-screen backdrop.

Greetings and salutations!

For this week's screenshots, a bit of traversal; specifically, part of the way out of the level. Since I have three screenshots this week, I'll scatter them over the course of the post. To start with, the problem: how do we get up there?



The week just past saw a lot of minor changes and fixes to level two, but nevertheless a number of more-salient things were also done:

First of all, as mentioned above, I made a lot of minor fixes and changes in level two: cleaning up geometry, fixing object-parenting issues, working on scripts, etc. And similar minor changes were made in other areas, such as the level-editor.

Perhaps more interestingly, I've been working a little on the routes through the level. In particular, I've altered a ground-based route through a particular section: Previously, the player could potentially drop to the ground and walk to the end of that section. Now, the street-level path is blocked--but there is a round-about way, a narrow gap, and a short "tunnel" beneath a building that a ranging player might find. It's a little more interesting, I think!

I mentioned last week, I believe, that I still had a fair few nodes in the level. In particular, the windows were a bit of a problem: each ended up composed of two objects, and due to multiple materials being used, one of those may have produced two separate draw-calls.

So, after a little bit of debate, I decided to unify them: to make a single set of colour- and normal- textures that handled all elements of a given window, thus allowing me me to combine windows into just a single object.

I also mentioned last week, I believe, that the exit to the level involved an as-yet unbuilt carriable object. In the week just past, I made that object: a chair, its back broken off (to obviate the question of collision with said back), but still with four stable legs.

(I ended up adding two to the level, as one alone turned out to be not quite high enough.)

One pleasant discovery was that a carriable object's orientation in the world doesn't affect its orientation when carried or set down. This means that I can have such objects placed at various angles, which may look a little more natural than having them all upright!


Hmm... These look useful...

While the model in question has no back, it didn't start that way, as I recall: instead, I modelled an entire chair, and then made copies. One of these had its back removed to make the carriable object above. The others became props to litter the scene, with legs (largely) removed, and back either present or removed.

The doors and windows of the level also saw some work: While the window-model existed previously, I now have animations for it, and an openable window has been placed in the level. (Openable from one side, at least--it's barred.) The doors have been both modelled and animated, and much like the window mentioned above, one has been placed in the level that can be opened from inside its building.

Finally, I experimented a little with my title-screen, playing with "warmer" colours--I'm not sure that it's current state isn't a little too melancholy. We'll see how that goes!



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

[Thaumaturge]

Blog post (9th of July, 2018)
The Streets Underfoot

Summary: In which the buildings meet the streets; the streets gain distinct meshes; the streets are cobbled; stairs and ladders are added; a script varies the level's colours; "additional transparency" is replaced by "lightening" in a shader; and the music to the intro cutscene sees revision.

Greetings and salutations!

Once again, I have a number of screenshots this week, and so intend to spread them out over the course of the post. In this case, they show some of the work that has been done on level two:



The week just past was a bit of a slow one, I feel, but a number of things did get done:

Perhaps the most salient changes are those to the level-geometry, as shown in the screenshots in this post.

The simplest is that I've begun lowering the "skirts" of the level's buildings so that they intersect the rather sloping streets of this part of the city. It's a somewhat slow and tedious business, and it's not quite done yet: the visual- and collision- geometries of the buildings are separate, and while I believe that I've completed the former, I haven't yet done much of the latter.

The other major change is that I've been working on the streets themselves.

Previously, there was only a rough approximation of the street-surface in place--a large, broad mesh beneath the entire level. (Later split into two.) What's more, due to the grid-culling system and the way that the floor-mesh was parented, it wasn't visible in large portions of the level, leaving the player walking over an abyssal black. And while this makes for a charming horror set-piece, perhaps, that's not quite what I'm going for in this level!

So, in the week just past I set about creating a set of proper street-meshes, one per grid-cell. Furthermore, they have been modelled around the buildings, reducing the chances of overlap issues with the building-floors. The general shape was referenced from those original rough-floor meshes mentioned above.

This isn't quite done yet: I still have some holes to fill, the places where two street-meshes meet to cover, and likely some tweaks to make.



The streets here are cobbled, and so another task of the week just past was the making of appropriate textures for this. You can see the result in the screenshots of this post; I'm quite happy with the result!

With so steep a grade to the streets, there are places where doorways end up noticeably above street-level. In addition, there are some places where the streets themselves become a bit steep, or have sudden drops. In such places, I've begun adding steps and stairs as appropriate. (Although the particularly high doorways tend to have ladders, instead.) Once again, this process is incomplete, but coming along, I feel.

Over the past few weeks, I've been working with a Blender-script that applies random vertex-colours to visible meshes in the level. The vertex colours in question are used by my shaders to alter the colour of the rendered mesh, thus allowing me to add a little bit of variety to the level's appearance.

As I recall, I started off just applying desaturation, but this alone wasn't satisfactory, I felt. What I wanted, as I recall, was more a lightening of the stone than a simple greying. (And on top of that I added in some darkening too, as I recall.)



Now, my shaders already allowed darkening and desaturation, but lacked lightening. It would be easy enough to add--but I was already using all of the channels of a single layer of vertex colours, and I think that I didn't want to add another.

However, one of those channels was being used to assign "additional transparency" to the mesh. I honestly don't recall with confidence when or for what purpose I added this, and thinking my way through the extant levels, I don't think that I'm using it anywhere. On the other hand, I'm not sure that I'm not.

(There is one case that occurs to me that I believe uses vertex-based transparency--but that also uses a separate shader.)

So, despite some hesitance due to said uncertainty, I decided to replace this feature with lightening, using the vertex-colour channel that it had employed.

I implemented it, and it seems to work as intended. We'll see whether later testing of the other levels shows some forgotten use for the "additional transparency" feature--hopefully not!

The final change that I want to mention specifically in this post is that I went back to the intro cutscene and reworked the music-selection being used there. As I recall, I noted previously that I wasn't entirely happy with what I had; while I'm still not entirely happy with the new selection, I believe that I'm happier.

And once again, there were a number of things done that don't seem worth mentioning here!



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

[Thaumaturge]

Blog post (16th of July, 2018)
Painting Over Holes

Summary: In which building skirts and street-stairs are finished (for now, at least); rubble proves challenging; the meetings of street-meshes are fixed; I accidentally paint over a bunch of darkness (then fix it); and a fair few other changes are made, but not detailed.

Greetings and salutations!

For this week's screenshot, some rubble choking a square--but also providing a means of ascent--in the buried city in which level two takes place:



I'm not sure to what degree that rubble is final. I'm not entirely happy with it, so I may well rework it entirely.

The week just past was one of work on a variety of elements of the level, but perhaps especially on its geometry. Let me elaborate:

I believe that I mentioned last week that I had lowered the "skirts" of the buildings so that they intersected the streets below, but that I hadn't yet done much of the same for their collision geometry. In the week just past, then, I attended to that, as well as tweaking some of the visual geometry as called for. I also continued to add steps in various places. As things stand, I believe that I have both done now!

As shown above, I've been working on a section of rubble that fills a square early in the game. It's proven rather challenging, I fear; indeed, as noted above, I'm still not entirely happy with what I have.

A problem that I had been struggling with was that of how to handle the meeting of street-meshes. As with most objects, the street-meshes are children of one or another cell. Where a street runs across two cells, there are therefore two meshes: one for the section of the street in the first cell, and one for the section in the second. The problem, then, is that of how to handle the places at which they meet.

You see, even if I match the vertex-positions of their edges closely, numerical effects may result in their edges taking up slightly different lines of pixels, potentially resulting in little gaps between them through which the backdrop may be seen. (I believe that these are sometimes called "sparklies".)

Furthermore, the normal-vectors of those edges are unlikely to be the same, resulting in a discontinuity in their shading.

In the week just past, a solution came to me:

In addition to matching the vertex-positions, I simply add a short "skirt" beneath each; any "sparklies" would thus simply show more street. And since the streets' UV-maps are projected by Blender, they should match up sufficiently closely that any discontinuity should be negligible.

As to the normals, I simply used a trick that has served me well in the past: I applied Blender's UV-alteration modifier to force their normals to match.

And it seems to work well! Indeed, I believe that I have all of the major (visible) meetings of street-sections handled, either this way or with stairs. (I have skipped some minor ones, in which I feel that a simpler but more-unsightly solution is unlikely to be serious.)

Speaking of problems, you may recall that my shaders use a channel of a given model's vertex-colours to darken certain areas. One way in which I use this is to create regions of artificial darkness--an example might be the "depths" of a doorway's bolt-hole.

You may also recall that I've been working with a script that randomly assigns vertex colours to vary the colouring of the level's geometry, including saturation, lightening, and darkening.

You might thus see the problem.

To my annoyance, I managed to overwrite the former darkness with the latter, which was often far less dark! As a result, a variety of pieces of geometry that were supposed to be lightless blackness were suddenly revealed.

Thankfully, this didn't affect too many objects. The main issue was with doorways: there are a fair few of those, and I had already made them individual (in terms of their internal data in Blender). this resulted in it being less trivial to find them all, and meaning that a change to one would not be reflected in the others.

However, I realised that the doorways, while technically individual, were still the same. In particular, they each had the same number of vertices, and it seemed very unlikely that another mesh would have exactly the same count.

So I wrote a quick script to look through all objects, and select those that had the same number of vertices in their meshes as in a single given doorway. Then I re-unified them--made them all use the same data. That allowed me to fix the bolt-hole on one, and have the change affect all!

As to the original problem, I've addressed it in two ways: First, the colour-variation script now checks for very dark vertices, and if found, ignores them. Second, I've moved objects that use darkening (doorways, water-cisterns, and toilets, if I recall correctly) onto a separate layer, so that I can apply colour variation without affecting them. (I've also moved windows onto this layer, having decided to omit colour-variation from them.)

Otherwise, I made quite a few changes besides--tweaking geometry, adding doors, fixing miscellaneous problems, and so on--most of which doesn't seem worth detailing here.

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

[Thaumaturge]

Blog post (23rd of July, 2018)
Rubble, Rubble, Toil and Trouble

Summary: In which rubble proves troublesome, but is (I think) improved; but not much else is done.

Greetings and salutations!

For this week's screenshot, a revised version of the rubble from last week:



The week just past was dominated almost entirely by that rubble (not helped, perhaps, by some lack of sleep):

As I think that I mentioned last week, I wan't entirely happy with the rubble model that I had then. In particular, I think that the pieces of which it was composed were rather too large.

So, in the week just past, I deleted that model and began work on a new one.

But how to approach this? In the original model, the pieces had been placed, rotated, and scaled by hand. But using smaller pieces would result in their total count being rather larger, making for a very slow and tiresome business.

I experimented with a few different options, often a few times over with varying details. Offhand, I recall two:
 - Placing a grid of "boxes" which might then be randomly -scaled and -offset, then hand-edited.
 - And using Blender's particle effects to randomly scatter pieces (and in some experiments, using Blender's physics system to then resolve their positions and orientations without significant intersection).

I think that I may have tried other approaches, too, but I don't remember offhand what those were.

But none of these produced satisfactory results, I felt.

And in the end, I returned to hand-placement. However, I did make it slightly easier on myself: While I started out performing placement, rotation, and scaling by hand, I soon wrote a short script to randomise a given piece's rotation and scaling. This I eventually improved upon, such that in the end, running it would duplicate one of a set of rubble pieces, apply a random rotation and scale to the duplicate, and then select it, ready to be hand-placed.

It was still slow and tiresome, but the use of that script made it far less so than it might have been, I imagine!

With the visual rubble placed, I turned to its collision mesh. This presented its own problem: I wanted the mesh to broadly match the form of the rubble, but not every nook and cranny.

One attempt at this involved creating a grid, then manually adjusting its vertices to match the rubble. This was not an ideal approach--and I realised that there was a way to make life a little easier:

Blender has a rather neat "shrink-wrap" modifier, which allows one to have the vertices of a mesh conform to the surface of another mesh--just what I wanted! It wasn't perfect, but it provided a starting point, and made manual adjustment a little easier (as the vertices conformed to the underlying surface even when edited).

I did have one rather unpleasant stumble during this: at some point, I managed to accidentally sub-divide the entire collision mesh--and in a way that produced issues in some places. Unfortunately, this went unnoticed for some time--long enough that the operation had fallen off of the bottom of the "undo history".

For a while I wasn't sure of what to do--but thankfully I discovered an automatic backup file that had been made before the incident. It resulted in my re-doing some work that had also been performed after the save, as I recall--but less so, I daresay, than might have been the case!

As things stand, there are some points on which I'm still not quite happy: For two, there are some discontinuities in the rubble's texturing, and I feel that the collision mesh hews a little too closely to the underlying surface, making for an unpleasant walk.

Still, I think that it's likely better than the rubble that I had last week!

A few other minor changes were made (including a little bit of writing), but nothing that seems worth reporting here.

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

[Thaumaturge]

Blog post (30th of July, 2018)
Building Blocks

Summary: In which stone blocks are made; said blocks make for some detritus and traversal; a "pit area" is detailed; some ruined buildings look better-ruined; text accessibility options are added; and a grid-cell line-of-sight issue is addressed.

Greetings and salutations!

This week's screenshots show that not all buildings in level two are entirely in one piece:




(There's also a third screenshot of another of the week's changes within the post-body.)

The week just past was rather more productive than the one before, I feel!

As shown above, two major points on which I worked in the week just past were the two buildings (or remains thereof) shown above.

This started, as I recall, with the sandstone blocks piled and scattered in and around them: loose stones of the sort used to build these structures. The models for these were quite simple to make, unlike the loose blocks from the previous level. The new model was then used to replace the stand-in visible geometry that had previously been in place, and the collision geometry altered to match.

While these blocks might end up being scattered in various parts of the level (and indeed, there's already a small pile of them elsewhere), there were two places in which they were particularly intended to appear--those being the two shown above.

One of these, as you can see, includes a small "pit" area, a place where the flooring is lost and the stuff of the hill below shows through. Up until the week just past I hadn't yet worked on the details of this area; I just had a rough form for it, enough to be playable.

In the week just past then, alongside filling in the stone blocks that make up part of it, I set to work on filling in the rest. Some minor changes were made along the way, albeit little that was significant. For example, a new set of stairs on one side allowed me to keep the blocks in that area level, and extending the building to near-surround the "pit" allowed me to avoid dealing with a fringe of cobblestones.

As I recall, I wanted to share screenshots of the new stone-block piles, but I had a problem: the buildings themselves were somewhat rough, with iffy geometry that wanted for some polish. So, in the interests of those screenshots, I set about applying that polish--some of the results of which are shown in the screenshots above.

It's not quite done--in particular, some elements of the walls' UV-mapping wants for fixing (the tops in particular). Still, I think that those buildings are rather improved!

Another significant change made during the week just past was in a matter of accessibility. Specifically, I added two new options (available from the options menu): the player can now set the speed at which in-game text passes, or have in-game text only disappear as a result of certain actions on the part of the player. This may hopefully allow those who either read slowly, or otherwise have trouble reading, to enjoy the game a little better.

Unfortunately, these options do not affect cutscenes. While I considered having them do so, I fear that it would conflict with the timing of music and sounds.

You can see the new options below:


After the player reaches the end-most part of the level and achieves the level's objective, the way back starts with a long, straight road. This road runs through three of the level's grid-cells--and thus incurs a problem:

If the player happens to be looking back towards that end-most part of the level when crossing into the third of those grid-cells, that distant section, still visible thanks to a light-source, suddenly vanishes. If it weren't for the light-source, that section would presumably be lost in darkness at this point, and its vanishing thus not be a problem. If line-of-sight were obscured, its vanishing might seem less sudden, and thus less jarring.

And in that last point lies my solution: while the road is still long and straight, I've added a new wall just before the crossing into the third grid-cell. The player climbs this wall, and only after leaving it do they cross the grid-boundary--at which point the wall obscures sight of the distant section in question.

In addition, this allows for an additional bit of (simple) traversal, with the player tasked with finding a carriable item to allow them to climb up and over the wall.

And finally, once again there were a number of things done that don't seem worth mentioning here!

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

[Thaumaturge]

Blog post (6th of August, 2018)
Shifty Shelving

Summary: In which shelving may be hiding something; scratches call for a new shader; more rubble is made; more building-meshes are cleaned up; the streets see cleanup too; a set of shelves obviates the question of a missing entrance; and doors are nailed shut.

Greetings and salutations!

For this week's screenshots, some shelving that's a little suspicious, and a close-up of what's suspicious about it:





In the week just past I continued to focus on cleaning up and filling in the level's geometry, as well as one or two other minor tasks:

To start with, the shelving shown above, found in a building at the edge of a small square. At this point in the level there may seem to be no clear way forward, neither from elsewhere in the square or from this building. But the scratches visible on the floor here suggest that the shelving has been moved in the past. And indeed, if the player examines the scratches, then examines the shelves, the option to "push aside" said shelves becomes available! Doing so reveals a hole in the wall, by which the player can then progress...

The shelving itself was quick to make: it's just a modification of a model that I had previously made, with a different set of textures.

The scratches called for a little more work:

My first attempt, as I recall, was to use my extant "mural" shader. But while this did sort-of work, I felt that it wasn't well-suited to this particular use. It's intended to portray a solid layer of colour (as of paint, etc.), flaking away in places, and showing the texture of the surface beneath. Scratches, however, might be softer, and add their own texture in the direction in which they run.

So I set to work on a new specialised shader. It's essentially a slightly-simplified version of the standard "player-light" shader--but with the addition of transparency (smoothly quantised via GLSL's "smoothstep" function), varied slightly via an additional texture.

Another major task in the week just past was the creation of two piles of rubble to replace two respective stand-in models. This went rather more quickly than the rubble-filled courtyard previously made, I'm glad to report! I'm not sure that I'm quite happy with them yet, however.

In addition, I worked on cleaning up the geometry of a few more of the level's damaged buildings (and one external wall). Specifically, these were the buildings associated with the above-mentioned rubble-piles, the building in which the above-shown shelving is found, and one other.

Here is one of the rubble-piles, along with the cleaned-up building associated with it:



The streets, too, saw some cleaning up: I went over each street-mesh, looking for places in which their models seemed to change direction a little too sharply, and generally smoothed those out a little. With this done, I also separated the collision meshes from the visible meshes.

That last helped in particular with the street-section that holds the "fake shadow" that I showed some time ago: those shadows are vertex-based, and can thus involve a dense cluster of vertices--which is superfluous for collision purposes. Separating the meshes thus allowed me to simplify the collision mesh somewhat, without affecting the shadow.

There's a large room in one building that serves to allow a player who misses a specific jump to return back to the roof from which they jumped. But there's a problem: this room doesn't have any apparent entrance, as I'd neglected to add one. A simple hole in the floor is all that's called for, allowing access down to the ground floor. But conversely, I don't really want it to have an entrance, as the rest of the building serves no particular purpose.

So in the week just past I cheated: there's now a set of shelves lying in one corner of the room, ostensibly covering the "entrance" that isn't there.

Another minor change was to the model used for non-interactive doors in this level: they now have a board nailed across them, hopefully making it clear that these doors are not openable.

And a number of other changes were made, but which don't seem worth detailing here.

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

[Thaumaturge]

Blog post (13th of August, 2018)
Polishing Ruins

Summary: In which a lot of geometry-cleanup is done; wooden planks prove tricky; a tunnel is perplexing; another vertex-shadow is added; and some aesthetic shader-experiments are made, but not kept

Greetings and salutations!

For this week's screenshots, a bit more (work-in-progress) ruin:




The work of the week just past was almost entirely further cleanup of various buildings. As a result, this post will be a relatively short one, although a fair bit of work was done!

As just noted, I spent time cleaning up various ruined buildings; two of these are shown in the screenshots above. This wasn't particularly difficult, but did take time, and was a little tedious.

There is more to be done--for one, I'm still experimenting with approaches to representing broken planks, and for another, various wall -tops and -edges will likely want for some manual UV-( and perhaps vertex- )work.

In one place, there's a sort of "tunnel" beneath a building, which provides an alternate route though part of the level. When I came to clean it up, I realised that I had a problem: I didn't know why such a thing would be there, and thus quite how to go about detailing it. Is there a reason for a straight tunnel in such a place, in which case it might be left more or less whole? Should it be ostensibly the result of damage to the building--in which case why did it take the form of a tunnel?

For now I'm somewhat inclined to make it look decent, and hope that it goes largely unquestioned... ^^;

I also did a little bit of miscellaneous cleanup work, fixing or touching up various bits of geometry.

Aside from cleanup, I put in some work on two things:

First, you may recall the vertex-shadows that I previously showed. In the week just past I added another such shadow around the stone block on which the ostensibly-shadow-casting lantern rests.

And second, I experimented with some aesthetic changes to the player-light shader. In the end, however, I wasn't happy with any of them, and reverted the changes.

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

[Thaumaturge]

Blog post (20th of August, 2018)
A Skeleton That Can Gape

Summary: In which a skeleton is made; aesthetic experimentations continue; and some miscellaneous changes are performed.

Greetings and salutations!

In this week's screenshot, a skeleton is shocked, shocked they say!



(That animation isn't intended for the game; it just amused me.)

And an overview of the skeleton:



The skeleton shown above took up the main of the week, I believe, but a few other things did get done:

First of all, the skeleton above. As I recall, I decided to work on it in the week just past as a treat after the tedium of the previous week's work--it's something that I had been somewhat wanting to get to. And, barring a few tricky bits, it was indeed a fun model to work on!

I didn't start from scratch: this model is a slightly-altered version of the "old corpse" model used in the upper section of the first level, which itself is an altered version of the mummy model used deeper within the same level.

The model itself was changed in a few places, as I recall. Three perhaps worth noting here are these:

First, as this skeleton has a less flesh clinging to its bones than the "old corpse", I opened up its pelvis.

Second, I discovered a mistake in its shoulder blades (specifically, that they were too big). This wasn't likely a major issue in the "old corpse" model, as it's found lying on its back, but this new model is intended for more varied (and sometimes more mobile ) use, and so I modified it.

Third and perhaps most salient, the jaw of the "old corpse" model was modelled as part of the head, and with no interior. Thinking that I may want to animate or move the new skeleton's jaw--even if it's just removing it in a prop skeleton--I set about making the jaw a separate, animatable piece. This took a bit of work, but was done in the end, as can be seen above!

The model's colour- and normal-map- textures called for changes, too.

Thankfully I had made the working image-file for the "old corpse" model with the intention of using it as a base for a skeleton model--specifically, the bones were painted on a set of layers separate from the flesh.

Nevertheless, between the bones being now more exposed and the changes to the model's geometry, a fair bit of work was called for.

While I am contemplating a minor fix (the front teeth are a bit narrow), the model is overall done, I believe, and I'm quite happy with it. ^_^


Hi! :D

Another task on which I spent some time in the week just past was further experimentation with the aesthetics of the game.

Long-time readers may recall that I've worked on this on several previous occasions, spread out over quite some time. More often than not, I find that the changes made in these experimentations don't improve the aesthetics of the game. And indeed, so it was in the week just past: I tried a variety of techniques that in the end I discarded.

But every so often I find a change that I feel does improve the look of the game. And so, too, it was in the week just past.

The change is fairly simple: In short, I (smoothly) threshold both the upper and lower ranges of the lighting used for the "player light". This separates some of the highlights from the mid-tones, and makes dimmer areas fall suddenly into blackness. I quite like it, and think that it contributes to that "slightly painted" feel that I've been working towards.

You can somewhat see the effect in the screenshot a few paragraphs above.

(This change will likely not be applied to the "sunlight" shaders: they seldom produce true blackness, making the lower threshold of dubious utility, and I feel that their highlights look good already.)

And finally, I touched up or fixed a number of other elements related to level two.

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

[Thaumaturge]

Blog post (27th of August, 2018)
A Mysterious Tableaux

Summary: In which a skeleton is found in mysterious circumstances; a bookstand is recoloured without adding a texture; the colour-variation script is dropped; polish and cleanup continue; rubble is perhaps improved; and alterations to the player-light shader are propagated to its kin

Greetings and salutations!

For this week's screenshot, a scene that may be found in level two, if the player searches around:



The week just past was perhaps a little slow, but not terribly so, I feel:

Perhaps my favourite part was building the scene above: much like the skeleton shown last week, it's something that I've been excited to do. (And indeed, as you might note, it even includes the aforementioned skeleton!)

This area is found just beside the main route in one of the more-linear sections of the level, separated from the path by a slightly-tricky jump. If the player successfully gains the relevant window, they find the tableaux shown above--and perhaps answers as to what happened there.

A small thing that I'm happy about in this is the colouring of the bookstand: while I had no wood-grain texture of that particular colouring, making this object didn't call for a new texture. Instead, I've used the features of the player-light shaders to desaturate and (if I recall correctly) to lighten it, directed by vertex-colours.

Speaking of vertex colours, in the week just past I continued to work with the colour-variation script. Alas, in the end I've decided that it's not working out: while randomised darkening of vertices seems to hold promise, the layouts of the meshes result in some unsightly artefacts. :/

Hand-darkening the meshes could perhaps work, especially since I might adjust the geometry to account for the artefacts. But doing so would likely be slow and tedious, and I'm not convinced that it's worth it.

Otherwise, I continued to polish and adjust the level's appearance. A few more buildings saw cleanup, others received some touch-ups, the outer walls and the ceilings were bevelled, and so on.

You may recall the rubble shown in previous blog-entries. One of the aforementioned adjustments was to apply a rougher normal-map to it, hoping to thus improve its appearance. And I think that doing so has succeeded in that!

One issue that remains in the rubble is that the UV-maps have some discontinuities that can be unsightly if spotted. Alas, re-mapping the models seems problematic, fused as the models now are: automatic mapping didn't produce the results that I'd hoped for, and manual re-mapping would be a very long, fiddly, and unpleasant task, I fear.

Nevertheless, here is a screenshot of the altered rubble, as seen in the large rubble-slope that fills one particular square:



And finally, I copied the changes in the main "player-light" shader that I believe that I mentioned last week into the other "player-light" shaders, as appropriate.

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

[Thaumaturge]

Blog post (3rd of September, 2018)
All A-board!

Summary: In which broken planks are given jagged edges; a script aids in this; and some miscellaneous fixes and touch-ups are made.

Greetings and salutations!

This week's screenshot shows a ruin and traversal challenge found in level two, and in particular the damaged boards recently updated in it:



The week just past was a little slow, I fear, but not entirely unproductive:

For the most part, the work of the week just past went into the broken planks found at various points throughout the level.

As you might notice above, these planks show jagged edges where they ostensibly broke. There are also quite a lot of them: not only are there the multiple ranks visible in the screenshot above, but planks like these appear in other places, too.

Hand-modelling each plank would be feasible, but slow, and rather tiresome. Re-using a single model, or small set of models, would incur the risk of the repetition becoming apparent.

So what I did was this: I created a single "template" model, and marked in vertex-colours the vertices that were intended to appear jagged. I then wrote a script that offset vertices that were so marked, and adjusted their UV-coordinates appropriately. It also examined the length of each board, comparing it to a reference value, and automatically adjusted the board's UVs to compensate.

This allowed me to quickly generate a randomised "jagged edge" to a number of boards at once. The effect isn't perfect, but it works, I do think!



There are places where these planks are intended to fit in with flat floor-planes that use normal-maps and colours to convey the edges of their boards. To match these seams, the planks each bow out a little at their sides, which are additionally darkened, thus producing similar dark grooves. (I also ended up exporting a new version of the "wood" normal-map, as I turned out to not have one that quite matched the normal-map used by wooden floor-planes.)



The darkening of the plank-sides does incur some hand-adjustment in places: Where the sides of the planks are exposed, they should generally not be darkened. In these cases, the darkening is by hand either curtailed, or removed entirely. A bit of a nuisance, but a relatively minor one, I feel.

And as I went, I also performed a number of generally-minor fixes and touch-ups where I found them called for. Perhaps most salient was a ruined building that I had apparently missed when cleaning up such models, and which is now done, I believe.

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

[Thaumaturge]

Blog post (10th of September, 2018)
Blocking the Way (And Opening It)

Summary: In which an obstruction is made; said obstruction (hopefully) teaches a lesson; barricades are built; books are composed and made; a glass jar is modelled; the glass shader is edited; static windows are edited; an alternate route is added; an engine issue gives a transient fright; mummy AI is tweaked; and the level-editor gains some improvements.

Greetings and salutations!

In this week's screenshot, a gap is visible behind obstructing debris:



The week just past feels to have been quite productive, to me!

To start with, I created several new models for the level.

Shown above is one of these: a barrier of debris that somewhat-hides a gap behind it. This obstruction is intended to serve as a reminder for the player that not everything in this game is highlighted:

When the player first approaches, no name appears for it, and no action-icon is shown. Yet there is a clearly-visible gap behind, and a lack of other apparent means to progress. The hope is that this will prompt players to attempt to "examine" the obstruction. Doing so causes it to be "revealed", with name given and an interaction icon shown.

At this point, simply "using" the barrier will cause the player-character to clear it, allowing passage forward through the gap that it had covered.

It's a lesson that is first taught earlier in the game: the previous level's goal is hidden behind a curtain that is similarly un-highlighted. However, as it's a fairly non-obvious lesson, I feel that it might bear repeating. And it becomes useful later in this level, when the player encounters the moveable shelves that I believe that I previously showed.

I've mentioned the model for the obstruction; alongside that, I also made a model for it in its "cleared" state--after all, the various pieces of wood that compose it don't just vanish.

Speaking of barricades, there are two earlier in the level that are more solidly-constructed, and not removable. The stand-in boxes that had previously represented these have been replaced now with proper models.

Elsewhere in the level, a little cache of books can be found. A pile of books for use here has now been composed (using previously-made book-models), and work has begun on the collectible book that can be taken from it. This is not yet complete, however!

And finally, I modelled a glass jar, wax-sealed and filled with an unidentified dust, or powder. This I intend to be placed in a magic-worker's building that can be discovered in the level. And it may well find use, either whole or in parts, in other places during the game.

Alongside this, I made some minor changes to the "glass" shader. In particular, the blue "edging" of the glass now expands with distance, causing it to remain visible at a variety of ranges. It's perhaps not ideal on flat glass surfaces, but for the rounded shape of the jar I think that it works very well!

Here you can see the jar:



I also made a change to an extant model: I've removed the bars from static, non-interactive windows. (Note that they still have boards nailed to their outsides.) This was done so that an interactive, barred window might stand out a bit more when encountered.

Moving away from modelling (more or less, at least), I've added a new alternate route out of a particular section of the level. You may recall the moveable shelving that I mentioned above. There's now another instance of this same trick earlier in the level, concealing an open window. However, unlike that later shelf, this one is placed somewhat out of the way, and there are other ways forward, making it perhaps more-easily missed.

I had a bit of a fright in the week just past: while testing a minor change, I discovered that the lockpicking minigame was freezing! It had been working previously--but then, I presumably hadn't tested it in some time.

Thankfully, this seems to have been an issue introduced in the engine, and subsequently fixed: simply updating my version of Panda3D seems to have solved it!

That same testing also led me to make a minor change to the combat AI of the first mummy enemy:

I found that it could sometimes end up using its "shove" attack several times in a row. As this attack "stuns" the player and drains their stamina, having it happen so often could result in the player having little stamina or opportunity by which to dodge the "shove", and so find themselves once again stunned and drained. This could be rather annoying.

So I've placed additional limitations on its use: When the player's stamina drops below a certain point, the mummy is prohibited from using that attack. When the player's stamina rises again above a certain (higher) level, the mummy is again allowed to use it.

Even the level-editor saw improvements: I fixed a minor bug, and added the ability to "teleport" to a given object. The latter seems likely to be quite useful, especially in larger levels, as it can obviate my flying out to distant objects. It may even occasionally aid in locating missing ones.

And finally, I made quite a few minor changes, fixes, and touch-ups that don't seem worth mentioning here!

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

[Thaumaturge]

Blog post (17th of September, 2018)
Interior Decoration

Summary: In which decor items are made; cloth uses the mural shader; combat "stun-flashes" are changed; the combat AI sees some minor changes; and a frame-rate problem is found in combat, and fixed.

Greetings and salutations!

This week's screenshot shows some progress on props intended to populate level two's interiors:



The week just past was perhaps one of those odd miscellaneous weeks, in which I ended up working on a variety of things with only tenuous connections:

First of all, the items shown in the above screenshot: One of the major pieces of work done in the week just past went into things with which to fill out level two. It's a desolate place, long-abandoned--but it's not entirely empty. Various scraps and artefacts remain behind, echoes of the lives once lived there.

The element that I'm perhaps happiest with is the representation of frayed cloth, as seen above carpeting the floor, and in a scrap hanging from the wall. This uses the mural shader created for level one, but with appropriate textures and scales applied, I think that it works quite nicely for this purpose, too!

Doing so involved further parameterising the mural-shader: there were two factors that, while appropriate for the murals, didn't work out as well with my intended cloth textures. As parameters, they can now be further tuned to a specific use.

As a result of introducing these new parameters, I ended up re-exporting level one, with the relevant parameters added to its murals. A minor nuisance, but nothing serious. And it did allow me to test a potential optimisation that I had in mind--it didn't work out, but at least I have that answer now!

The bowl and wooden chest seen above are based on previously-made models, by the way, and the animated version of the chest re-uses the old chest's animations.

(Although I did attempt a more-complex version of the chest--only to find that it had over six thousand vertices, which seemed a bit much for such a model! I thus went back to an earlier attempt, building on that earlier chest-model, and produced something with only about one-and-a-half thousand vertices, as I recall.)

I also did some work on the combat mechanic.

To start with, I changed the "stun-flash" animation a little: where it previously appeared as two spikes entering from the sides, it now expands outwards from the centre. I think that it feels a little better this way, although I'm not yet confident that I'm happy with it.

I also attempted to force enemies to use attacks that they had been neglecting. This proved somewhat tricky, in particular in determining just what condition I wanted to look for. Should I be comparing the number of uses per attack to the average, for a given total number of attacks? How many attacks have been made since a given attack had been used? Something else? And should I be looking to break "streaks" of attacks?

What I have now seems to work, I think, although once again I'm not yet confident that I'm happy.

On a minor note, I increased the rate at which the second mummy-enemy's tendency to use their "flurry" attack increases when they're hit by rapid attacks from the player.

I think that it was during testing of one or more of the above combat changes that I noticed something odd: while the (admittedly simple) test-level ran happily at well over a hundred frames-per-second, combat ran at around seventy--despite being pretty simple itself.

Via Panda3D's performance tool, PStats, I saw that there seemed to be an increase in something to do with "bounds", which seems to have been of little importance in this case, and in drawing the scene, which was quite salient.

In particular, it seemed that the floor was the major culprit: removing it or having its shader just output pure white caused the frame-rate to jump up. Oddly, it seemed that the more frequently the floor's texture was repeated, the lower the frame-rate became.

But why should drawing so simple a scene be so expensive (relatively speaking, at least)? And why was the floor such a problem?

Asking on the Panda3D forum, it was suggested that the problem was a lack of mip-mapping. And indeed, a quick test indicated that this was the case: forcing the engine to use mip-mapping significantly increased the frame-rate!

Why then was mip-mapping not enabled? Especially as I had good reason to believe that it was enabled elsewhere in the game.

As it turned out, the answer was in how I was loading textures to be applied to the floor: in the method used for explicitly loading textures, the mip-mapping settings are optional. By setting mip-mapping as appropriate, the frame-rate in combat increased again, and now happily runs at well over a hundred frames-per-second, I believe.

And once again, a few things were done that don't seem worth detailing here.

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

[Thaumaturge]

Blog post (24th of September, 2018)
Kitchen Decor

Summary: In which a kitchen and toilet are outfitted; decals are a little tricky; a script aligns UVs; and animated models lose tags.

Greetings and salutations!

This week's screenshots, like last week's, show a domestic scene; in this case, kitchen and toilet areas in one of the buildings of level two. As I have three screenshots to show, I intend to scatter them across this post.



The week just past was a fairly busy one, with work done on a number of elements. Most of these were minor, or likely not all that interesting, with a few that I would like to detail:

As (partially) shown in this week's screenshots, I made a few new props for use in level two, such as simple tables, and a kitchen cupboard.

Perhaps more interestingly, I also made some decals for use with them.

One of these is the new animal-sign visible on the cupboard: a spider-like creature, with long, barbed forelimbs.

Along with this, I modelled the creature depicted in the sign; they can be found lying dead beneath cupboards so marked.



The other is a stain used to mark the tables; it's not terribly visible in the screenshots, I'm afraid, beyond being slightly visible in the corner of the first screenshot above. This "stain" uses the same shader as the scratches shown previously near a moveable set of shelves, but darker, and using the same normal-map as the table in order to blend with it.

That last was the tricky bit: how might I align the UVs of an arbitrary decal-mesh with those of the table beneath, such that their normals matched up?

My answer to that was a Blender-script. In short (if I recall correctly): Given a "target" object (in this case a table) with the relevant vertices marked with vertex-colours, the script finds the minimum- and maximum- U- and V- coordinates of the relevant section. Then, for each vertex of the decal-mesh, it finds that vertex's position relative to the "target". From this it then calculates U- and V- coordinates, using the maximum- and minimum values mentioned above.

It's not perfect, but it seems to work well enough, I think!

(If you look closely at the first screenshot, above, you can see that the decal is in fact misaligned. I think that I forgot to re-run the script after resizing the decal! ^^; )



Applying the animal-sign to the kitchen cupboard also incurred some difficulty. In short, Panda3D doesn't handle animated models in quite the same way as it does static models. As a result, I was losing the tags that instructed my game to load and apply the relevant custom shader.

Having discussed the matter on the Panda3D forum, there are, I believe, some workarounds to this issue. However, these, too, come with issues of their own. And it occurred to me that I didn't really intend to keep anything in these kitchen cabinets. (And indeed, the dusty remnants of foodstuffs and yet more dead spider-things seem unlikely to make for interesting exploration.) So I've settled for now on simply having these kitchen cabinets be static.

If this issue with animated models comes up again, then it may be worth revisiting the matter for that new case, starting with the two workarounds that I'm already aware of.

The shader used for animal-signs also saw some tweaks. One of these was simply an update to its lighting: it seems that it hadn't been updated alongside some of the changes to the player-light shaders, resulting in its appearance being visibly different under some circumstances. Perhaps more interesting is that animal-signs should now render a black line-art version of their design at range, making them more visible at a variety of distances.

And alongside the above I made quite a few other changes that don't seem worth detailing here: bug-fixes, tweaks, new textures, and so on. (Although I am quite happy with my new normal-map for metallic objects.)

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

[Thaumaturge]

Blog post (1st of October, 2018)
A Helper in Decoration

Summary: In which interior decoration continues; models are made; a set of Blender's tools is discovered; a script aids with the interior decoration; highlights are touched-up; and some aesthetic changes are attempted, but largely discarded.

Greetings and salutations!

This week's screenshots depict another interior scene: a simple bedroom (with a few elements of its adjoining kitchen visible in places).




The week just past was a rather productive one, I feel!

Perhaps the most salient element of the work done in the week just past was the continued decoration of building interiors, some of which can be seen in the screenshots above.

Many of the pieces used for this had already been made, as I believe that I described in previous weeks. Nevertheless, a few new models were added in the week just past.

I'm perhaps happiest with a simple bucket-model: I discovered that Blender has some quite neat tools for modelling along a path, which I feel were rather a boon in building the rope-handle of said bucket! I can very much see these tools proving useful in the future. ^_^

But the tricky part of this interior decoration was the question of workflow.

Duplicating objects in Blender is easy enough. However, I keep my "palette" of interior objects somewhat separated from the level itself, and manoeuvring them into place can be a little awkward at times. Furthermore, the relationships between connected objects (such as may be with a visible model and its collision geometry) can mean that moving all at the same time can result in unintended offsets between them.

In the week just past, the idea came to me to write a script that would duplicate a set of objects, then place them at the location of Blender's 3D cursor. Thus I could simply select the desired pieces, place the 3D cursor as desired, run the script, and have the new duplicates in more or less the right place.

So I wrote the script in question. There were a few challenges, but in the end, I think that it works quite nicely. And as I worked with it, I built on it, expanding its functionality: it now causes the appropriate duplicates to be selected, for convenient adjustment of position, and moves the duplicates to appropriate layers. Overall, I'm quite happy with this tool. ^_^

On a minor note, I touched-up the highlights produced by the player-light: I found that shiny objects had too broad a highlight, relative to duller objects. I've corrected this, and I think that the result is rather better.

I also conducted a variety of experiments with the game's aesthetics, but with little real effect. (The only change that remains in place, if I'm not much mistaken, is that, as the player tilts the view up and down, the player-light now moves slightly higher and lower than it previously did.)

And in addition to the above, I made quite a few changes, fixes, and tweaks that don't seem worth detailing here!

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

[Thaumaturge]

Blog post (8th of October, 2018)
Aesthetic Reworkings

Summary: In which combat aesthetics are reworked; and nearby darkness in the player-light shaders gains some blue.

Greetings and salutations!

I have a few screenshots to show this week, so once again I intend to spread them out over the course of this post. Those in the body of the post show changes to the player-light's approach to lighting. This first, however, shows several aesthetic changes to the combat mechanic:



The major changes of the week just past were the above-mentioned aesthetic ones, although a few other things did get done.

First of all, as shown above, I reworked a number of aesthetic elements in the combat mechanic:

Health was previously represented by hearts, which I felt didn't really fit the tone of the game; now it's represented by circular drops of what might be blood.

The stamina bar is broadly the same as it previously was, but now has (to my eye, at least) a more pleasing form. In addition, that form conveys a little bit of additional information: it becomes shakier at about the point at which lowered stamina starts to result in lowered damage, and thready at about the point at which no damage is done at all.



The combatants' titles are now given a black backdrop, so that they're easily legible even when the player is at low health, and the concomitant red border ends up behind them.

And finally, I've added a simple, "painterly" backdrop behind the action itself, replacing the solid black of before. (Furthermore, this backdrop may be tinted, to better match the fight's environment.) In addition to this being a little more aesthetically pleasing to me, I have in mind at least one enemy that would likely be hard to see against solid black, I think.



The other major aesthetic change, as mentioned above, was to the player-light. During the week just past I posted on Twitter a request for feedback regarding the look of the game. One of my friends replied with some critique, which gave me some direction for (I hope) improvement.

The biggest element of this is that the player-light now fades to a cool blue in the shadows, and thence to the familiar black. This not only means that nearby shadows aren't entirely impenetrable, but also, I think, makes for more interesting colouring.

Other than that, I continued decorating the interiors of buildings, fixed some bugs that were discovered, and made a number of tweaks, fixes and touch-ups that don't seem worth elaborating on here.



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

[Thaumaturge]

Blog post (15th of October, 2018)
Blue-Tinted Further

Summary: In which the collectible view backdrop is tinted; inventory items gain a blue tint in dark regions; a brass bowl is touched-up; inventory items are clipped; combat backdrop elements are blue-tinted; a potential sticking point in level two is fixed; and interior decoration continues.

Greetings and salutations!

This week's screenshot shows a few touch-ups to the close-up view given for collectibles, and to the collectible brass bowl from the prologue level:



The week just past was a bit of a slow one, I fear. Still, some things did get done:

As shown above, I continued to touch up various aesthetic elements in the week just past:

Starting with the inventory, the close-up view of available for collectible items now has a slight blue tint to it, which I find a little more appealing than the dull grey that was previously in place. Further, inventory items now have a customised shader that introduces a similar blueness in darker regions to that used by the player-light shader.

The normal-map for the brass bowl shown in the screenshot was also tweaked--I wasn't happy with it's appearance, given, I think, that it's intended to be seen at such close range, and to be a reward item.

During testing, as I recall, I discovered that one of the collectible items--an open book--could in some orientations poke out of the close-up view. This doesn't look terribly good, and so I set about attempting to fix it.

The most expedient approach seemed to be a change to the inventory shader, as it meant few changes, and changes that I was a little relatively comfortable with.

This wasn't entirely an easy matter, however: To start with, I had to figure out just what transformation to perform in order to get values that would provide a good basis for clipping a given object. And with that done, I found myself a little mystified that the clipping didn't seem consistent: as I rotated an object, the clipping seemed to shift about on the screen. This turned out to result from the object's origin not being centred; to fix it, I ended up re-centring and re-exporting the relevant objects.

With all that done, however, I'm glad to say that this inventory clipping seems to now work! ^_^

As with the inventory, I further adjusted the aesthetics of the combat mechanic by introducing a slight blue tint to the darker parts of the floor and the backdrop. I experimented with something similar for the combat-characters, too, but felt that it didn't really work there.

Turning to level-building, I discovered that there was a point in level two at which the player could become stuck if they failed to take a carriable ladder with them. A simple "staircase" of fallen stone blocks seems to have fixed this problem, allowing the player to backtrack and retrieve a ladder left behind.

I also continued to work on the interior decoration of the level, advancing through two or three more buildings, I believe.

And a number of other changes, tweaks, fixes, and suchlike were made that don't seem worth detailing here!

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

[Thaumaturge]

Blog post (22nd of October, 2018)
A Small Detail

Summary: In which a skeletal hand pokes out; interior decoration continues; animal signs are not examinable; simple examinable objects are supported; street-edging is attempted; autosave-points are added; and an adventurer is begun

Greetings and salutations!

This week's screenshot shows a small detail in level two: a skeletal hand protruding from a gap in the rubble near the start of the level. There's no lore or collectible to be found here--just a sight that the player may stumble upon.



The week just past was a bit of a slow one, if perhaps not as slow as the week before, I think:

To start with, work continued on the interior decoration of level two. While I think that I advanced only a little in the number of buildings so filled-out, I did also enact some tweaks and fixes in some of those previously attended-to.

I also removed the display-name markers from the animal signs visible on cupboards in level two: They were at the time non-functional, and while I could have made them work, I also realised that there were rather a lot of them and that unlike those in level one, these seemed relatively unimportant. It seems to me that it's not worth proliferating game-objects in this case, nor frequently distracting the player with objects that have little import.

The reason that they were non-functional, as I recall, was that while they specified a "display-name", the code that loads examinable objects from level-geometry was only reacting when certain other tags were present. Objects with just a "display-name" were thus missed.

Although I removed the "display-name" markers from the aforementioned animal signs, I nevertheless also implemented support for such objects as they were: objects can now be made examinable with only a "display-name" or "examinable" tag.

I did this for use with the object shown in the screenshot above: a skeletal hand that might be found in the rubble of level two.

The streets of the level currently run directly into the bases of the adjoining buildings. In the week just past, I made some preliminary attempts at adding edging to them.

Hoping to avoid building edges manually for every street, I attempted to use Blender's curve features, based on the outside-edges of the street-meshes. This showed some promise--but didn't quite work out, I fear. In addition, I realised that the street-meshes actually ended slightly inside the buildings, leaving the generated edges hidden.

What to do here is thus still under consideration. It's tempting to leave the streets as they are--but we'll see.

On the logical side, I went through the level and added autosave points. This was a little tricky: I didn't want these points to be too few, but I also didn't want them to disrupt the pacing of the level, as I recall. Further, the level is laid out in such a way that there are relatively few narrow choke-points through which I can be confident that the player will pass.

Still, I have a set of save-points laid down now, I believe!

In the most distant part of the level, the player encounters a fellow adventurer; in the week just past, I started in on modelling this character. Thankfully, this needn't be done from scratch: instead, I've based it on the player-model used in combat, modified as appropriate. The modifications are fairly significant, and it's very much a work-in-progress, however!

And once again, there were a number of changes made that don't seem worth detailing here!

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

[Thaumaturge]

Blog post (29th of October, 2018)
The Making of an Adventurer

Summary: In which an adventurer is (largely) completed; inverse kinematics aid in animation-building; eyes are separate; the adventurer's logic is scripted; conversations gain lip-flaps; a blob-light issue is fixed; and elements at the adventurer's location are rescaled and touched-up

Greetings and salutations!

This week's screenshot shows the adventurer the meeting of whom is the goal of level two:



That adventurer was the primary work of the week just past:

As I believe that I wrote last week, work on this adventurer had already begun at the start of the week just past. Nevertheless, there was much to do during the week--and indeed, I may yet make further touch-ups!

I think that most of the modelling had been completed in the previous week--although some touch-ups, tweaks, and fixes were made in the week just past, as I recall. Instead, most of the time spent on the model itself in the week just past went to texturing it (a task begun in the previous week, but not at all completed), and to animating it.

One animation that gave me some trouble was that in which the character stands up: it proved quite tricky to get their feet to remain steadily in place on the ground, without jittering or oscillating unpleasantly.

In the end, some searching led me to discover Blender's "inverse kinematics" tools: these allowed me to place the feet, and have the legs follow. There were still some challenges, but far less than when attempting to make the animation without inverse kinematics!

One thing that might be worth mentioning about the model is that its eyes are a separate object. This allows me to apply a custom shader (also made during the week just past), which both gives them a nicely shiny appearance and also gives the iris some counter-shading and additional lighting. Hopefully this makes them feel a bit "deeper", and more "alive". The application of an offset even allows them to somewhat follow the player as the latter moves!

On the logical side, I implemented the adventurer's scripting in the week just past: (Save for the conversation scripting, which had already been done.)

The adventurer, when found, is initially digging at a flagstone in the square in which they're encountered. When the player approaches, however, they look up, dropping the rod that they had been using. When the player draws nearer still, they stand, ready to talk. And finally, when the conversation is done, they enter a simple "idle" animation, waiting for the player to move along.

Furthermore, they turn to track the player as the latter moves around (this code stolen from the "Enemy" class), and some additional scripting makes their eyelids blink.

The conversation code also saw some touch-ups: it now supports the playing of a basic "lip-flap" animation while a given character is speaking, and a simple "idle" loop when they are not.

When I came to place the adventurer in the level, I discovered something odd: although they were placed well within the range of a nearby "blob-light", they were nevertheless unlit!

In the end, I came upon the problem: an additional "flattening" of the geometry of grid-cells. At a guess, this "flattening" was changing the origin of the geometry in the cell, and thus resulting in the blob-light's relative position being incorrect.

Quite how this came to be in place I'm not sure--perhaps it was a remnant from before grid-cells were descended from ordinary cells. But removing it seems to have fixed the problem!

Placing the adventurer also resulted in my discovering that some of the elements related to the blob-light--specifically, the lantern that ostensibly emits it, the block on which that rests, and the "vertex-shadows" that it ostensibly casts--were all rather too large. So, in the week just past I scaled them down, and furthermore set to work touching-up those "shadows". (That last may not be quite complete.)

And finally, a few more minor things were done that don't seem worth mentioning here.

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

[Thaumaturge]

Blog post (5th of November, 2018)
Outfitting a Shop

Summary: In which level two's adventurer is finished (I hope); a shop is furnished; a coin collectible is added; a tally-board is made; a shader is tweaked for it; table-tops prove problematic; and some trickery gets around that problem in one case, at least.

Greetings and salutations!

Once again, I have a few screenshots to show this week, and so intend to scatter them throughout this post.

Those in the body of the post show a shop outfitted in the week just past. But to start with, a gif showing the adventurer who I've described in the past few posts, animated, with logic in place, and with vertex-based shadow fitted and adjusted:



A number of things were done in the week just past:

First of all, as shown above, I finished off the adventurer who is met in the most-distant part of the level.

On the minor side, I touched-up the vertex-based shadows ostensibly cast by the adventurer's lantern, turned down the power of said lantern, and adjusted the adventurer's location a bit.

I also decided to prevent the adventurer from rotating around to always face the player: the vertex-based shadows don't react to this, which I felt looked a bit odd. Along with this, I added some restrictions to the rate at which the adventurer can turn their back, neck, and head (and possibly eyes; I forget) to look at the player: this prevents them from suddenly snapping from one side to the other if the player passes behind them.

With that--and excluding sound effects, which have yet to be added--I think that said adventurer is done! ^_^

But perhaps the most salient change of the week just past was the outfitting of a long-abandoned shop that can be found as the player progresses through the level.

In each major "section" of the level, save the first, I want to have at least one interesting "scene" for the player to discover. In the case of the most-distant section, it's the aforementioned shop.



Coming down from the residential section above, the player enters behind the shop-counter. A head of them lies the door leading out. Behind that is a table-top holding a shard of shaped stone, and a display case, its glass shattered, and only scraps of cloth within. On the wall to the side is a large animal-sign, one which may only be found in this place.

On the counter itself the player may notice a small bronze coin: this is a new collectible item, also modelled in the week just past.

Some work was done towards another scene elsewhere in the level. This, however, is rather more nascent: all that's been built of it thus far is a rough wooden tally-board, marked in sevens using what might be charcoal.

There was some challenge in getting those markings to look decent, as I recall.

I tried my "decal" shader--the one that I've previously used for scratch-marks--but the levels of transparency that it produced made the markings look a bit watery, I felt. I also tried the "mural" shader, and after some frustration, realised that it was specialised in a way that made it awkward to use for this purpose.

In the end, I went back to the "decal" shader, but added a new parameter that allows me to control the number of levels of transparency that it produces. I can thus now have two levels for scratches, as before, and also have a single, somewhat hard-edged level, as here.

Getting the geometry for the markings--and in particular for their tips--took a few attempts to get right, but was not a major issue, I think.



When working on the shop, I ran into a problem that I've seen once or twice before: it can be difficult to see the tops of tables, or flat objects on them.  In short, this is a consequence of the lighting that I have in place, including some thresholding done in darker regions.

This was particularly a problem for the collectible coin mentioned above: being quite small and flat, and placed at table-top level, I feared that it was quite easy to miss.

I conducted a few experiments, attempting to find a way of both increasing visibility on table-tops and retaining the aesthetic qualities that I like in my current lighting. Alas, nothing quite seemed to achieve both goals.

In the end, the coin situation at least was resolved by brightening the cloth on which it rests, and adding a faint and subtle blob-light over it. This makes it rather more visible, I do think!

And once again, a few other tweaks, changes, and fixes were done in the week just past that don't seem worth detailing here!



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