next »

[Grhyll]

Sorry if I have made you waste time with my suggestions ^^' Everything always seem very easy as long as one doesn't start working on it!

[Thaumaturge]

Sorry if I have made you waste time with my suggestions ^^'

Not at all! I'm grateful for the suggestion. ^_^

It may not have worked out, but that doesn't mean that it's necessarily for the worse that you suggested it.

While I've already moved back to the Bullet version, I've actually had another idea that I want to try in the line-intersection vein...

Everything always seem very easy as long as one doesn't start working on it!

Hah, it can indeed be so! And this "radial heightfield" idea looked so to me, too, at the outset!

[Thaumaturge]

Blog post (3rd of April, 2017)
A Few Lines

Greetings and salutations!

For this week's screenshot, a short gif that shows the screenshake that now occurs when the player is hit in combat:


The week just past was for the most part a somewhat technical one, quite a bit of which centred around line segments and their intersections. Specifically, I spent a fair bit of time working on some of the underlying logic of the combat system and the lockpicking prototype.

Fixing Combat

I mentioned last week, I believe, that I had begun reworking the logic behind attacks in the combat mechanic, using a line-intersection technique. In the week just past I completed this, and moved on to making the various attack- and defence- types work under the new system.

(Although funnily enough, vertical attacks continue to use their old logic: it seems to work well for them.)

With that done, I returned to, and fixed, the original problem: the AI not accurately predicting which attacks would land and which would be stopped by a parry. The AI seems to new more reliably predict which of its defences will stop an incoming attack, and which attacks will get past a given parry by the player.

I also added a few bits of polish:

As shown above, the screen now shakes a little when the player is hit. This may see revision in the future, but for now I think that it adds a buit more "impact" to taking damage.

During the work on the underlying logic, I discovered that when combatants lunged forward into attack, they were able--during a certain window, I think--to adjust the target-distance of their lunge. This didn't seem quite right to me, so I've changed the code such that it should no longer happen.

Similarly, the speed at which combatants step backwards has been reduced, and now looks (to my eye, at least) rather more reasonable. My guess is that the backstep-speed was previously quite so high because of the above-mentioned lunge-adjustment: I think that it allowed a backstep to escape a lunge even despite that adjustment.

Conversely, I decided that combatants shouldn't be able to attack while backstepping. My thought here is to prevent players from repeatedly waiting for an attack, stepping back, then launching an attack as the enemy misses.

The second mummy's "flurry" attack should now be a little smoother when it misses--I felt that it previously looked a little stilted, I believe.

I also tweaked the logic behind the combat tutorial; it should hopefully be a little less prone to breaking. (The breaks weren't catastrophic, by any means, but if I recall correctly they could interrupt the tutorial.)

Finally, I tweaked various attack- and defence- values so that attacks landed or were parried a bit closer to the positions that I might expect. (Although the player-character's right-hand parry is still a little off.)

Picking the Right Physics

The other mechanic on which I spent a fair bit of time was the lockpicking mechanic. Some time ago I uploaded to my TIGSource thread a simple prototype of a new lockpicking system. The main feedback that I received was that the mechanic was poorly taught (and especially that it was unclear about where, precisely, the player is expected to interact). I have some ideas regarding this.

However, there was also some feedback on the physics of the thing. Aside from a known issue in which the lockpick could occasionally slip out of the puzzle, I was told that the pick's movements, both away from the "walls" and on them, left somewhat to be desired.

I spent a fair bit of time attempting to rectify this.

My first approach was to treat the lock's inner geometry as a cylindrical heightmap, snapping the pick to the surface of the lock when it would otherwise fall beyond. The heightmap part of this worked fairly well, and was reasonably simple to implement, as I recall.

The problem, however, was in colliding with the walls of the tiers that compose the lock. Having the pick slide up and down these, rather than snapping from tier-top to tier-top, proved rather tricky; indeed, I would likely have ended up building a fairly general line-segment collision system, I believe. Such a thing is by no means impossible--but doesn't seem worth spending the time on for this mechanic.

So I returned to Bullet, and played around with the various settings and options available to me there. This started to show promise, with the pick feeling perhaps a little more intuitive under my hand.

I may even have found a means of hedging out that bug in which the pick slipped free, by replacing the box-colliders that I had been using with convex hulls: where the right-angles of boxes leave gaps when radiating outwards behind the tiers, convex hulls can pretty much fill up the space. However, the absence of the bug hasn't yet been extensively tested.

Convex hulls also allow me to easily give a slight bevel to the corners of the tiers, which I think makes those corners feel a little less unforgiving.

I did briefly attempt another line-intersection approach, based on the thought that the pick, being larger than a single point, should never be able to cross the borders of the tiers. I think that it might have worked--but by that time the Bullet approach was shaping up, and I decided to leave it be.

Overall, I think that the mechanic feels a little better now! There is some work yet to be done on it, I feel, especially in terms of aesthetics and in communicating the mechanic to the player. I may also want to add a slight complication to the mechanic, primarily to prevent an exploit that I'm aware of.

Miscellaneous

Finally, I worked on a few things not part of the combat- or lockpicking- mechanics: I restored a chunk of visible geometry that seems to have been accidentally deleted from the prologue level, and reworked the "combat radius" ring to use geometry rather than a texture.

(There's a little irony to the latter: As I recall, I reworked the "combat radius" ring because the new shadows no longer observed texture-transparency. However, while working on the ring I also decided to have it no longer cast shadows (it's not an in-universe object, after all). Ah well, I think that it may look better now, anyway.)

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

[Thaumaturge]

Blog post (10th of April, 2017)
Carvings and Corpses

For this week's screenshots, two views from within the upper level of the barrow-tomb. The first was taken from the entrance ramp, looking down into the tomb; the second from the far end of the main corridor, with the ramp in the distance.




The week just past was a bit of a short one for me, in terms of work: between a major family event over the weekend and various things peripheral to that, less time than usual was given to the game. Still, somewhat did get done!

To start with, I spent a little more time working on performance. I tried out a simpler model for the walls in the upper level of the tomb--but this didn't improve performance as I'd hoped, and looked rather worse, I feel, so I reverted the change. I also tried running the game with only a single monitor active (which gave a slight boost to performance), and running it in full-screen (which produced a dip in performance--although this may be due to a concomitant change in resolution).

Ultimately, it looks as though the main culprit is antialiasing: disabling this produces a significant improvement in performance. I'm still slightly mystified as to why it's so much worse in some rooms than others, but at the least I'm reasonably comfortable with moving forward.

I also experimented a little with shaders and shadow-camera lenses, but found no real advantage in those attempts.

For the remainder of the week, I moved away from technical matters and back to work on the first level--and it felt good to be back at it, I believe!

Aside from general work on the upper-level rooms, I spent time on two things in particular:

First was the corpse found in the first tomb of the upper level. This one is nowhere near as well-preserved as the mummies found below; indeed, it's nearly skeletal.

The model isn't yet complete, with the majority of the texturing still to be done.

I intend for this model and its textures to serve as a base (with perhaps some changes) for other skeletal characters encountered later in the game.

The second piece of work was rather smaller and quicker, and finishes off the upper-level hallway: the carvings found above the three tomb-doors in the upper level. These each give a name associated with the one interred (or originally interred) in the room beyond the door; as such, they should help in indicating which key goes to which door.

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

[Thaumaturge]

Blog post (17th of April, 2017)
A Question of Lore

Greetings and salutations!

For this week's screenshot, a look at the still-work-in-progress "old corpse" model that I've been working on (or rather, the skull thereof), taken from within Blender:



The week just past was a very short one! Between Easter and various other calls on my time, I ended up working on the project far less than I usually do, I believe. A little got done, but not much.

Since there's little progress to discuss, then, I want to use this blog post to ask for feedback on a matter that I've been pondering of late: how to approach lore entries.

To start with, the progress update:

What work I did get done during the week just past was entirely on the "old corpse" model shown above, I believe.

It's proved a little trickier than expected, and I've ended up reworking some parts of the mesh; the hands in particular saw a fair bit of work, separating out each of the bones of the fingers, and the main of the hand as a single chunk.

It's still somewhat sketchy, but starting to get there, I think.

That covered, on to the main topic of this blog post: lore entries.

I believe that I described the lore system in a previous blog post, but for those not familiar with it, let me do so again in short: Lore in A Door to the Mists is essentially another form of collectible. However, unlike the physical collectibles, lore is intended to be somewhat mysterious: To start with, there's no UI indication of how many entries there are, or whether one has been missed. Further, the requirements for each entry vary--some may require no more than looking at a single object, while others may require looking at several, or having collected a previous lore entry, or other conditions besides.

That much I'm confident of. Where I'm uncertain is in the content.

Some entries provide general setting lore--describing animata, or spirits, or animal signs, for example. They provide information that the character would know, but that may not be apparent to the player.

Others are essentially bits of story discovered in the levels--and it's on these that I could use some feedback.

Right now, these story-entries are written from the perspective of the protagonist, and as such, include only the information found within the level, and her thoughts on it.

But is this sufficient reward to the player? After all, it essentially summarises what they've already discovered in order to acquire the entry.

The other option that occurs to me is to write these entries from an "omniscient third-person" perspective--not the protagonist's responses, but the full story, including things not known to the protagonist. While such entries would presumably not include the protagonist's thoughts, said thoughts could perhaps be given within the level, instead.

But while likely more rewarding, this sort of entry seems as though it might feel a little more distant, and the sudden addition of information that wasn't in evidence a little inexplicable.

Right now I'm uncertain--and so I turn to you. What do you think?

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

[Thaumaturge]

Blog post (24th of April, 2017)
Things Ill-Preserved

Greetings and salutations!

This week's screenshot shows some of the contents of the first tomb, in particular its books. Alas, the contents of the room have fallen to ruin, and the books are rotted beyond reading.



The week just past was much more productive than the two before it, I do believe! For the most part, it focussed on art:

First of all--as seen briefly above, but more clearly below--I completed the "old corpse" model, and placed it on its slab in the barrow-tomb. (Although I may go back and touch up the region within the pelvis, which looks a little "flat" to me.) A copy of this has also been saved out as the basis of future "skeleton" models, likely with a little bit of rework (again around the pelvis, as it happens).



That done, I moved on to the other major feature of the room: the books, standing on a shelf behind the corpse.

I already had a rough 3D model of a book, as well as an early texture (designed to include book-covers in four different colours). These I refined and reworked, as well as adding normal maps.

With the four base book-models done, I duplicated them into a few sets of books, both standing and piled, allowing for relatively-quick placement.

But not all books have been kept well enough that they may still be read--as shown in the gif above. To this end, I set about ruining the books: creating a second set of textures and models that showed significant water-damage. The covers are worn, the pages damaged, and covers and pages both show stains and black marks. The ink of the text within has soaked and spread, leaving the words nigh-unreadable. It took me a few attempts to find an approach to this that I was happy with, but I think that I like the final result. (Well, aside from my dislike of damage to books, that is.)

Now, I had debated at times how I should handle the player reading some of the texts in the game. Should I just give the character's comments (as I have been thus far), or show actual pages? I decided in the week just past to go with the latter: while more work, I feel that it's likely to be more immersive.

I thus wanted a representation of an open book for those cases in which the text in question is a book (as opposed to a loose page or scroll). I started in on a 3D model, but ended up concluding that, as with the lore-entries, a painted approach seemed likely to better suit my intended aesthetic.

So I painted such a book, as well as a ruined version. These want for some touch-ups, I feel, but overall I'm fairly happy with the results.

When I came to implement these books into the game, I encountered a few stumbling blocks:

First, I discovered that while I had a means of placing an object into a level that allowed access to a set of books, I didn't have one that displayed just a single book. This wasn't too difficult to rectify.

A little trickier was the fact that while I had a working means of showing in-game documents, it was still rather prototypical, and didn't yet have support for background images. For now I've implemented the beginnings of this, enough at least for the damaged books shown above. There's more yet to be done for documents intended to show legible text, I believe!

(Along the way I discovered and fixed a number of minor bugs and issues, too. I also made a minor change to the logic behind what I call "gameplay" menus, in order to allow some of them to show the level behind them--as in the case of books.)

Finally, prompted by a dev. who I follow on Twitter posting theirs, I've been giving some thought to a tagline for A Door to the Mists. I'm finding it difficult thus far--I'm not sure that taglines (or brevity in general) are my forte--but I've jotted down a few initial thoughts, at least.

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

[Pixel Noise]

Cool info about the book - and I think it looks good! Also agree on the tagline thing - you should definitely have one. You should have a "tagline", one sentence summary, and a short "elevator pitch" ready to go at any time. I've learned this by not having those things prepared

[Thaumaturge]

Cool info about the book - and I think it looks good!

Thank you! ^_^

(It's a little smaller above than I have it now, I believe (even aside from the gif being scaled down, that is)--I ended up increasing the on-screen size of books in order to fit more text onto the undamaged ones.)

Also agree on the tagline thing - you should definitely have one. You should have a "tagline", one sentence summary, and a short "elevator pitch" ready to go at any time. I've learned this by not having those things prepared

Heh, I do tend to struggle to come up with such short summaries, I fear. ^^;

As to a "one-sentence summary", the text that I have in my signature ("Traversal, exploration, puzzles, and combat in a heroic-fantasy setting") covers the gameplay of it, and suggests somewhat about the setting, but doesn't really convey anything about the story... On the other hand, it seems unwise to attempt to cram too much into a single sentence.

As to an elevator pitch, looking back to my first post in this thread, would the first section of that--beneath the heading "Introduction"--work, do you think?

The tagline I'm still thinking on...

[Pixel Noise]

I think the tagline you have is pretty decent - though I'm sure it could be improved, made more efficient, specific, etc. But I think it's a good start.

As for the elevator pitch - the description you mentioned is basically the summary of the backstory/motivation for the character, but doesn't really say much about gameplay, so I'm not sure it quite hits all the talking points you would want it to.

I'm definitely no expert on this, so don't take my word for it. Ughhh...and we did a "game pitch" workshop at one of my local meetup groups sometime last year, which was really enlightening as to this whole process, and how to get a good pitch...but I ended up skipping that meeting due to teaching obligations   but I'll ask around and see if anyone has a link to some resources on it. For some reason I feel like Rami Ismail has an article or something about this...

He did! Here is a link to him talking about it (~1 hr)  http://www.gdcvault.com/play/1020877/In-3-Sentences-or-Less

And here is an article which summarizes the entire talk, I think

http://www.gamedonia.com/blog/game-pitch-how-to

[Thaumaturge]

I think the tagline you have is pretty decent - though I'm sure it could be improved, made more efficient, specific, etc. But I think it's a good start.

Thank you. ^_^

Hmm... So the tagline and and "one-sentence summary" are the same thing? I thought that you were describing two separate things (the summary presumably being intended to describe the game to others, and the tagline intended to be part of the advertising of the game).

Would a tagline not tend to be more emotional in nature--more about the experience of the game, or its themes, or the "fantasy" being conveyed, etc.?

As for the elevator pitch - the description you mentioned is basically the summary of the backstory/motivation for the character, but doesn't really say much about gameplay, so I'm not sure it quite hits all the talking points you would want it to.

Hmm... That's a good point, I think. Fair enough! I'll work on something separate for this, then, I intend.

I'm definitely no expert on this, so don't take my word for it. Ughhh...and we did a "game pitch" workshop at one of my local meetup groups sometime last year, which was really enlightening as to this whole process, and how to get a good pitch...but I ended up skipping that meeting due to teaching obligations  but I'll ask around and see if anyone has a link to some resources on it. For some reason I feel like Rami Ismail has an article or something about this...

He did! Here is a link to him talking about it (~1 hr)  http://www.gdcvault.com/play/1020877/In-3-Sentences-or-Less

And here is an article which summarizes the entire talk, I think

http://www.gamedonia.com/blog/game-pitch-how-to

Ah, thank you! I'll read that soon, I intend! ^_^

[Thaumaturge]

TIGSource headings:
Blog post (1st of May, 2017) (Technically the 2nd, where I am.)
Deeper into the Tombs

Greetings and salutations!

For this week's screenshot, an update of sorts to last week's gif: some books and pages can now be read, having survived the passage of years rather better than the book shown last week:



The week just past was a fairly productive one, I think!

I mentioned last week, as I recall, that I was thinking about taglines. I believe that I have one now:

"Adventure is my path."

One thing that I quite like about this is that it connects to four major elements of the story: First, the path followed in the game is one of adventure--of caves, tombs, and ruins, of foes to fight and treasures to find; second, adventure is what the protagonist seeks beyond the mist-door; third, adventure is her chosen path in life; and finally, the fact that adventure is her path, and her reason for wanting to enter the mist-world, is the reason that she can't simply take up magic to do so. Adventure being her path is her goal, her obstacle, and the way forward for her.

As to work on the game itself, as shown above, I continued implementing readable documents--this should now be complete (save perhaps additional backdrops, if called for). Some of the code here is, confessedly, a little hacky, at least in part working around old code.

In order to test these books, and also advancing the progress of the first level, I wrote drafts of the documents shown above: a journal, describing the group of people there interred, and a paper discussing the process of mummification that they used. The journal in particular has the advantage of being long enough to span multiple pages, thus allowing me to test that functionality.

I also returned to work on the level itself in the week just past, primarily focussing on the room and staircase that provide access to the lower level.

This room was once a tomb much like the first room entered--indeed, the slab remains in place--but its occupant has been removed and a door opened in its back wall, leading onto the spiral stair and down to the lower tombs. Room and stair have both been completed, I believe (save perhaps some touching up).




This then, along with some miscellaneous changes, completes the upper level of the tomb!

And thus I've begun work on the lower level.

Aside from placing some (automatically tiled) floors, I've started with the first room entered after leaving the staircase--a simple entryway, block-walled and pillared (as with most of this level of the tomb). The walls show the remnants of murals, but so disintegrated by now that their subjects are no longer discernable.

These murals are the first of several encountered in this level of the tomb (although the rest are rather better-preserved), and so I've begun working on an approach to depicting them.

I'm a little dubious of simply painting such murals as textures: I fear that, stretched over large walls, they'd either lose quality or call for rather large images. I also want them to reflect the shape of their wall, as defined by its normal map. Finally, I want them to not be completely solid--the paint might not have reached into cracks, and might be flaking away in places.

To this end, I currently intend to represent murals via vertex-painted geometry, using the relevant wall's colour- and normal- maps. A specialised shader then applies the normal map as usual, and uses the colour map to distress the mural: where the image is particularly dark (taken to represent cracks and gaps), the mural becomes transparent. I haven't yet addressed more-general flaking away.

The image below shows my current, simple test-mural. It doesn't represent any mural intended to be found in the game; I just happen to like dragons.



As per usual, I daresay that there were a few bug-fixes and miscellaneous changes not mentioned in the above.

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

[Thaumaturge]

Blog post (8th of May, 2017)
Saving and Loading Revisited

Greetings and salutations!

This week I have a few screenshots to show, covering the progress made towards the first level. As a result, I intend to scatter them throughout the post, both preventing this initial section from becoming too long and breaking up the text below. None of the rooms shown are complete, but they're getting there, I believe.

To start with, the room at the foot of the spiral stairs. It's a simple ante-room--but flakes of paint on the walls suggest that there were paintings here once, the forms of which are now lost. (The model used for the table is intended to be temporary.)



This week was another productive one, I feel! Conceptually, it was split between technical matters and artistic ones:

I started the week with the technical, working specifically on the saving and loading of games. Not terribly exciting, but somewhat important, I feel. It's something that I've been somewhat putting off, but in the week just past decided to sit down and attend to.

To some degree this was already working--indeed, it shares much with the saving and loading of levels, which (as one might guess from recent progress) already works. Further, I'd given this some time previously, and had it functional.

So what was there to do? Well, there were two issues to attend to:

First, it hadn't seen work in quite some time, and some elements that aren't intended to be saved when designing a level, but that are intended to be saved during play, have thus been missed. For example, I believe that when I instituted the old saving-code, support hadn't yet been added for enemies leaving bodies after defeat--they simply vanished. As a result, elements of this "defeated state" weren't saved, and thus weren't loaded, leading to some incorrect behaviour.

Aside from a few tricky cases, dealing with this wasn't terribly difficult, if a little tedious.



But this wasn't the main reason that I wanted to attend to saving and loading. The main reason was the second issue:

The saving and loading system was initially written for an earlier concept, a rather larger game than A Door to the Mists. In particular, it was intended to have a "semi-open world": There would be levels as in A Door to the Mists, but the player could access them in nearly arbitrary order (once they'd been discovered), and potentially leave and enter multiple times, as I recall. In addition, changes made within a level would persist--enemies defeated would stay defeated, doors unlocked would stay unlocked, etc.

This meant that it wasn't enough to just save the current level; I wanted to save all levels already visited. To this end, my save-game system did just that, writing out all visited levels (along with additional data, such as the player's state). This was then collected into a "multifile"--an archive-type provided by the engine that I use, Panda3D. When loading a level (and some other types of object), the system would first check the most recent save-file to see whether the level (or object) had been stored there. If it was, the system would load that version; if not, it would load the default version.

This worked. When run with the SDK, at least. For some reason it didn't work in distributable versions, and a visit to the Panda3D forum didn't resolve the issue.

Between the system not working in distributable builds and the relative simplicity of A Door to the Mists, I decided to strip out the more-complex approach and build something simpler--which is what I did in the week just past.



The new version saves three files: the actual save-game, including the level's data and the player's; a metadata file (intended for use in eventual save- and load- menus); and a screenshot (again, intended for those menus).

While I haven't yet tried this in a distributable build, the new, simpler system seems to work well! ^_^

I don't yet have manual saving implemented, nor save- and load- menus; right now there's only auto-saving, and a simple "load autosave" button on the main menu.

With all of that done, I moved on to some art. First, I created a new "saving" icon, which pulses briefly to indicate that the game has been saved. The old one was not intended to be final art, and I'm rather happier with this new icon. You should see it below, at the bottom-right of this cropped gif:



For the remainder of the week, I worked primarily on the first level.

A big part of this was continued work on murals, and especially "distressing" them, making their outer edges a little less geometrically sharp and representing the effects of paint flaking away to greater or lesser degrees. Some of this can be seen in the flecks of paint shown in the first screenshot above, but as those murals are so heavily disintegrated, let me show the overall effect via a simple-and-rough demonstration mural:



One tricky part of this was that I wanted one additional layer of colour-data in the mural's vertex colours, in order to store the degree to which the mural was distressed in that region. The alpha channel would have likely worked well--save that Blender apparently doesn't support an alpha channel in vertex colours.

In the end, I found that I could add a second layer of vertex colours, which I simply painted in greyscale; I then modified the exporter that I use to apply this to the alpha-value of the vertex colour in the exported model.

Otherwise, I continued work on the level geometry itself, moving out from the ante-room into a long corridor, and thence into the first tomb-room of the lower-tombs.

As per usual, there were a number of other things done that don't seem worth mentioning: cleanup of code, bug-fixing, miscellaneous changes, and so on.

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

[Thaumaturge]

Blog post (15th of May, 2017)
A Variety of Progress

Greetings and salutations!

Once again, I have a few images to share this week, and so intend to scatter them throughout the post. They should be a little more relevant to their preceding paragraphs than were last week's, however!

To start with, a look at two of the murals adorning walls in the lower tombs. Though somewhat damaged, they're far better preserved than those in the entry-room:



The week just past was a productive one, I feel, and one with a bit of variety: I worked on level-geometry, UI-textures, the logic and UI of the save-game system, and the aforementioned murals. To elaborate:

I started the week, I believe, with work on the geometry of the lower tombs, and specifically on the broken wall found in the first tomb that the player enters on that floor. This proved a little tricky.

You see, the unbroken walls have flat geometry, relying on normal maps to provide a sense of shape and surface-texture. Since the breach in the wall is three-dimensional, it exposes the sides, tops, and bottoms of some of the blocks that compose the wall, and as a result the wall transitions from flat to 3D. For the most part this isn't a problem: the normal maps apply just as well to surfaces other than the front-faces. The tricky bit lies in the rough, bevelled edges of the blocks.

Perhaps the simplest approach is to leave the three-dimensional blocks unbevelled, and rely on the normal map to create an impression of bevelling. This works reasonably well, as it turns out--but the shape of the blocks, and how they map the textures applied to them, somewhat gives away the trick.

Another thought, then, is to bevel the block-geometry but use normals from unbevelled sections of the normal map. (Since the normal maps effectively alter the apparent normal-vector of the surface, applying a bevelling normal-map to a bevelled surface results in the normals pointing in the wrong directions.) This works--but it loses the surface-texture of the bevels, and I think that I had some difficulty at the transitions between the flat and 3D sections.

The answer, in the end, was somewhat a combination of the two. In short, I bevelled the blocks, but then used a Blender modifier to alter their normals to point in the direction of the flat wall's normals. This allowed me to use the bevelling normals applied to the flat surface, while retaining the three-dimensional geometry, thus keeping the advantages of both.

(There was also a minor pitfall in the colour-texture being used, and some of the UV-mapping was a little tricky, but nothing worth going into detail about here, I feel.)



For a while now I've been a little dissatisfied with the textures that I've been using for various UI elements. While largely fine in and of themselves, I think, I felt that they didn't really match the overall aesthetic. In addition, I wasn't happy with the images that I had for my UI-buttons.

In the week just past, then, I attempted to improve matters there. I repainted the UI-button, updated the "tabbed-frame" tab-buttons, made use of my reusable "stone" texture for stone UI backdrops, and made a handful of other adjustments. Concomitantly, I adjusted some of the extant UIs a little to account for the new elements, in particular the new UI-button.

I haven't yet decided what I'm going to do about my current "leather" backdrop (seen for instance behind the inventory, below). I experimented a little, but wasn't happy with the results.

However, that aside, I'm rather happier with the UI as it is now, I do believe!



I believe that I mentioned last week that I spent time on the functionality of saving and loading. In the week just past, I moved on to working on the UI and functionality of manual saving, as well as adding in quick -saving and -loading. Quick-saving was pretty straightforward, as I recall: in essence, it's just autosaving, but at a button-press rather than via in-game trigger or other logic, and with a different save-name and file-name.

Manual saving called for a bit more work, both in figuring out the intended flow for its UI, and in implementing said flow. The details are perhaps not very interesting; suffice it then simply to say that one should now be able to manually save and load games (including overwriting old saves), and delete extant saves. This all seems to be working as expected, although it perhaps hasn't been tested extensively.

(I may also want to add a confirmation dialogue to the process of deletion; there is one for overwriting, at least.)

On a related note, the main menu now has buttons that provide access to manual -saving and -loading. There's also a "continue game" button--when a game is paused in the background, this button should return the player to it; when there isn't, it should load the most recent save (if any is found).



Alongside the above, I moved some of the logic related to autosaving. In short, the game should still autosave before leaving a level, but should no longer save just before combat. (I am contemplating having it additionally save just after combat, however.)

The final piece of major work done in the week just past went into the murals shown in the leading image above. These are the first of a number that decorate the walls of the lower tomb. While I considered them done as of Saturday, I currently intend to go back and rework them a little, both in content and in the mural shader used to depict them.




As with last week, there was also, I believe, a miscellany of other work done in the week just past!

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

[Thaumaturge]

Blog post (22nd of May, 2017)
Reworking Mural Distressing

Greetings and salutations!

For this week's screenshot (or rather screenshots), the revised versions of the murals that I believe that I showed last week:




The week just past was focussed on the first level:

Perhaps most interesting (to my mind, at least) are the changes to the murals, primarily in the shader that displays them. (As shown above, there were changes to their content, too.)

One of the actions of this shader is to distress the mural near the edges of the blocks (or bricks, cracks, etc.) of the wall behind the mural. Previously, as I recall, this was informed by the colour-map of said wall, on the presumption that darker areas corresponded to such edges.

However, this seemed a little wasteful, given that I was already making use of the wall's normal map, which seemed to carry similar information. In addition, the murals felt a little overly-"flat", and I wanted to add a bit more texture to them--but was hesitant to do so by adding yet another image to the process.

I believe that I had previously tried using the normal map instead of the colour map in distressing the walls--after all, the normals should be at their most extreme near the desired edges. However, I found that this was only partly true: while they were indeed more intense in the surrounding regions, they sometimes flattened out again at the centre of the gaps. If the cracks between blocks were canyons, at the bottom of each was sometimes a ribbon of flat ground.

In the week just past, however, I realised that I had one more source of information to draw on: As I believe that I've mentioned in the past, I store information on a given surface's "shininess" in the the alpha channels of my normal-maps--and I generally decrease this "shininess" in cracks and gaps, in order that specular highlights not undermine the effect.

Now, this gradation of shininess can be a bit smooth by itself for use in distressing. However, the normal map tends to be more textured--and so, by combining the two, I found that I could produce the desired effect.

This meant that the wall's colour map was no longer being used, and as such, I replaced it with a simple "brush-stroke" texture, intended to add a bit of variation to the surface of the mural.

The mural-shader is still not perfect--in particular, internal edges are still rather straight and sharp, the only fix that I have at the moment being adding vertices with which to vary their lines a little. However, I do think that the murals are improved, and I'm overall happy with them, I believe.

Otherwise, progress on the level was made in a number of ways: I added a little "dirt" to the colour-texture for the lower-level's wall-blocks, hopefully making them look a little less uniformly "clean", and thus feel a little more "used".  I tweaked the geometry of the first of the lower tombs, and of the room above. I modelled, textured, and normal-mapped the sarcophagi of the lower level, and replaced the old stand-in models with them. I added ceilings to the some of the rooms, and a first-pass at pillars in at least one. I started in on the bookshelf in the first of the lower tombs, and on its contents.

(Some of the items modelled for these purposes may see reuse in later levels; while possibly not quite in keeping with those locations, they should do well enough, and so reduce the workload for those levels.)

It's none of it exciting stuff, perhaps, but it all contributes to moving the level forward, and thus coming closer to completing it! ^_^

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

[Thaumaturge]

Blog post (29th of May, 2017)
Of Animal Signs, Room-Work, and Technical Challenges

Greetings and salutations!

For this week's screenshots, a look at the progress made on the first of the lower tombs, and a glimpse of the room beyond:




The week just past once again focussed primarily on building the first level--but there were a few technical challenges and changes, too.

First of all, as shown above, the first of the lower tombs is, I think, nearing completion. Aside from the new sarcophagus (which I believe was added in the week before last), a bookcase has been added, along with books (some well-preserved, some not), a handful of other items, and a mark on the top--more on which later. The breach in the wall is filling out: there's now fallen soil around it, and fallen blocks. Interestingly, these blocks aren't scattered as one might expect them to be after a fall--they're lined up in front of the breach, and otherwise stacked to one side...

I've also worked somewhat on the room beyond the breach. To some degree this had been previously begun, primarily in applying some of the common elements of the tombs: the tiled floor, the columns, and the sarcophagi. This week--because of the mark mentioned above, as I recall--I added a pair of shelves holding books, and completed the unbroken walls of the room. The room's columns have been completed, too, placed in what will likely be their final positions, and made significantly larger.

Those shelves (well, one of them--I realise now that I didn't do so for the other! ^^; ) have that same mark found on the bookshelf mentioned above. It's a little different here, however. It glows.

Those marks aren't just decorations, neither on the shelves nor the bookshelf. Indeed, they're one of my favourite elements of this setting: animal signs.

The animal signs are images of animals, each represented a specific way. Applying one to a surface confers a boon, the exact effect depending on the animal depicted--one might conceal, another might provide great stamina, while yet another might grant protection from biting insects, for example. No-one knows exactly how or why they work, as far as I know; they're unconnected to magic, or the mist-world. In addition, they only work in areas where the animal in question is well-established. Their effects are very temporary, but can be renewed.

I was somewhat excited to finally be setting about implementing animal signs, as I recall. The basics went fairly smoothly: they're essentially decals, with the colour-texture of the object on which they sit applied to them, and with a normal map that produces the impression that they're carved.

Adding the basis of the glow effect was fairly straightforward, I believe. The tricky bit was adding the details of that glow. Animal signs are supposed to glimmer, almost twinkle--think of blue starlight, and you might have a roughly-appropriate mental image.

The obvious thought is perhaps a particle effect, or a shader-based analogue. However, I was hesitant to take this approach--it seemed a bit heavy-handed, I think. I also didn't want to use too many texture-lookups in the shader. Conversely, I didn't want something that was too static, or that "flowed" too much.

In the end, what I did was use an image composed of layers of "sparkles", in four gradations each of red, green, and blue. This is saved as part of a "mask" image that I was already using to define the area in which the glow appeared, confining that mask to the alpha channel. This is then read in the shader as a single pixel-value, and the red, green, and blue channels carved up into four values each. These values are applied to a set of sine-functions that cause them to fade in and out.

The effect doesn't stand up to really close scrutiny, but I think that it looks rather good, overall. Take a look:



On the technical side, I made a minor change to the player's lantern-light: it now shifts up and down a little with the vertical angle of the player's view: when the player looks up, it's held higher, and when the player looks down, it's held lower. I find that this makes it a little easier to see things a little above and below the player's position, both in terms of lighting the object and in terms of reducing problematic shadows.

Still on technical matters, I discovered a potentially-significant problem in the week just past: I leave gaps between the cells used for portal-culling. This means that an object placed in such a gap may be assigned to no cell. While the resultant lighting issues may be fixed by manually specifying the relevant light, this also means that such objects aren't affected by the portal-culling system.

I'm not yet sure of what to do about this--I've asked after the matter on the Panda3D forum, for now.

Returning to art, I reworked one of my "tiling stone" normal maps. For a while I had been somewhat dissatisfied with the look of certain stone surfaces, in particular the large slabs used in various parts of the tombs: they looked a little like they'd had camouflage paint applied to them, I think. In the week just past, I replaced these, and I'm rather happier with the new version, I believe!

Note that this new normal-map doesn't entirely replace the old: there are some places in which the old normal-map works well, I think.

Finally, as per usual, there were a number of minor changes not mentioned here.

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

[Thaumaturge]

Blog post (5th of June, 2017)
Light in the Tombs

Greetings and salutations!

This week's screenshots show a cool glow illuminating one corner of the tomb:

(And, confessedly, some unfinished geometry. ^^; )




The week just past was a bit of a slow one, I feel. For the most part, work focussed on the first level, with a few excursions into other elements:

As noted above, most of the work in the week just past centred around the first level, both in the first of the lower tombs and branching out to work in earnest on its neighbour. Most of this would likely make for a fairly uninteresting list, so let me describe only a few particular items:

The second of the lower tombs is (as things stand) the first room to make use of the "blob lights" that my "player-light" shader allows. In essence, each object handled by the "player-light" shader is additionally lit by a somewhat-diffuse, non-shadow-casting point light. In most cases this uses default parameters that result in no apparent lighting, but with a change to those parameters a locational glow can be achieved. In the tomb in question, a cool blue light emanates from a point near one corner of the room, above a set of corner shelves.

I actually ran into a small issue, here: when I tried to add the light, it insisted on shining from the centre of the culling-cell, near the centre of the room. To my frustration, no change that I found had an apparent effect, and the code that handled the blob-light seemed much like the working code that handled the player-light, as I recall.

In the end, I discovered the source of the problem: The blob-lights are placed as "models" in the modelling program, and exported with the level. This is then loaded, and--amongst other things--the blob-lights are found and created according to the tags on the models. So far so good.

However, for performance reasons, I "flatten" the level-geometry within each cell--one of the effects of which is to essentially zero the position of the geometry-objects within, moving that information into their vertex-positions. As a result, the blob-lights were being read as having a position of zero--i.e. centred within the cell. To fix this, I now instead find their position by retrieving their bounding-sphere, and using the centre of that object.

Two models of chests have been created. However, these are both unopenable (indeed, neither is animated)--instead of acting (in gameplay terms) as containers, these are carriable, and intended to be used for traversal.

Indeed, they added a minor complication to the design of the level: I wanted to have a few of the smaller boxes in the first tomb, but stacking them up allowed relatively trivial access to the hole in that tomb's ceiling. Now, in general that's not entirely a bad thing: I want players to be able to find alternate routes and solutions in matters of traversal. However, in this specific case I want the player to first move into the next tomb, take a chest from there, and so trigger the first fight of the level.

To this end, I made some adjustments to the debris below the hole, lowering the base on which the player stacks the chests, and removed one chest. The remaining chests, stacked on the lowered base, should no longer reach quite high enough to climb into the room above, thus calling for the player to still range a little further to finish the job!


(The image above isn't the one shown previously on Twitter; I made some minor changes after posting that.)

For a while now I've been a little dissatisfied with the textures in use for books: they seemed a little too simple, a little too uniform, and the repetition of titles was a little too apparent, I think. So in the week just past I attended to that, adding several new colours or variations on colours, individual "water damage" for the spines of illegible books, and additional distressing to the spines and covers of the legible versions. I did get a little lazy with the new front- and back- covers: they simply re-use the distressing and water damage used for the original four, but slightly rearranged amongst themselves to somewhat hide this fact. For the moment this re-use doesn't look too bad, to my eye, but if it becomes a problem I may go back and give them individual textures.




Moving away from the first level and returning to the prologue for a moment, I've added a new tutorial there that covers (in brief) saving and loading.

On the technical side, I discovered a minor bug: it seems that I left the game-window's aspect ratio unchanged when changing the resolution, resulting in the view being stretched to one degree or another in various resolutions. This should be fixed, now!

Finally, I believe that I previously mentioned that anti-aliasing has seemed to be a source of poor performance on my machine. In addition, the engine-provided function intended to toggle anti-aliasing seems to no longer work, on my machine, at least.

In the week just past I began to investigate alternative approaches, primarily by asking for advice on forums (this one included). From the responses that I've been given, I may have a way forward: Instead of rendering directly and relying on the engine to handle the toggling of antialiasing, I might render to an off-screen buffer and then present that. This allows the off-screen buffer to be replaced relatively easily, I gather, allowing me switch between an antialiased buffer and a non-antialiased buffer (hopefully) without too much trouble.

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

[Thaumaturge]

Blog post (12th of June, 2017)
Tables, Tiles, and Climbing

Greetings and salutations!

For this week's screenshots a look through the breach in the first of the lower tombs, showing some of the progress made on the tomb beyond:




The week just past feels, I think, both somewhat slow and somewhat productive; I suppose that, while I didn't get as much done as in some weeks, I'm fairly happy with some of what I did get done:

First of all, as shown above, the first level itself continues to fill out. In particular, the second of the lower tombs is starting to look less bare than I feel that it previously had: Alongside the previously-extant shelves and books, chests and tables have been added (the latter of which were amongst the new models produced during the week), providing some variety to the scene, I think.

Beyond that, I've started work on some of the other rooms in the lower tombs. Perhaps most notable is the second "double tomb" (that is, a tomb-room that, like the one beyond the breach, has two sarcophagi). In particular--aside from adding shelves and new tables--I've set in place the damaged tiles that give way to an alternate means of reaching the "pit" area, made progress on that passage, and begun work on the "pit", too.




I mentioned the tables, above. One minor issue that I've had with them in the past has been that most objects in A Door to the Mists are represented in the physics simulation by primitive objects--boxes, cylinders, spheres, and so on. This means that there's no easy way for there to be space beneath a table (or other such object); an object placed there would be occluded by the table's box-shaped physics object.

There is the capacity to load a non-primitive collider from the level geometry (which likewise tends to be non-primitive), but this is perhaps a little constricting.

To deal with this, I've added the ability for the game to load an object's physics representation from its model-file, overriding the default behaviour if such a representation is found. It's a fairly straightforward change, but one that may prove useful, I think.

I made some progress on the code-side, too, I believe. Some of this was simply bug-fixing or other minor changes, but two points may be worth mentioning here:

First, the player now moves a little more slowly while crouched. I had debated this previously--it seemed a little superfluous in the context of the game's mechanics, I think. However, it does also allow for finer control of movement, and so I've included it.

Second, I believe that I've fixed two bugs in the "climbing" mechanic. The first of these could sometimes result in the "climb" not being properly concluded, and player thus being stuck, and so was somewhat serious. The other could result in the character standing after climbing, even when there was little space above; while not serious, it could be unsightly (allowing the camera to peek through the ceiling) and a little uncomfortable, I feel. Both of these may well be fixed by the changes made. Fixing the first issue did involve changes to the underlying logic, so the "feel" of climbing may have changed a little--it's something that that I may want to revisit and refine a little, perhaps.

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

[Thaumaturge]

Blog post (19th of June, 2017)
A Short One

Greetings and salutations!

For this week's screenshot, a look at the (work-in-progress) "pit" area, an earth-and-stone cavity beside the tomb, connected to it in places where the tomb has begun to give way:



The week just past was a very slow one, I feel. Still, some work did get done, both on the level itself and on more technical points:

First of all, progress on the first level continued, now focussed more on the "pit" area shown above, and the tunnel and broken tiles that open onto it. I'm not yet sure of how happy I am with the look and feel of this pit. Further, some adjustments may be called for, as I've realised that it's awfully close to some of the tomb-walls surrounding it, and that the rock-outcroppings may be a little inexplicable. Nevertheless, it's a decent start, I think.

I also tinkered a little with the player-light shaders, making the shading a little more intense in my efforts to achieve that "somewhat-painted" aesthetic that I'm aiming for. I also removed the "flattening" of normals in the distance; while I hadn't liked the results previously, I feel that it may work better with the intenser lighting.

Once again, I'm not yet quite sure of how I feel about the effect as I have it thus far.

Continuing on the subject of shaders, I believe that I've made some improvements to the shadows, significantly reducing a set of artefacts that previously had been visible. With the player-light this comes at a slight reduction in the quality of the shadow-edges, and likely a slight drop in performance, as I ended up widening the shadow-camera's field of view. I think that it's a worthwhile trade-off, however.

On a more technical note, I've switched to rendering levels and combat-areas to an off-screen buffer. This allows me to more easily replace that buffer, which in turn allows me to (relatively) easily swap between a multisampled (i.e. antialiased) and a non-multisampled (i.e. non-antialiased) buffer. On which note, it's once again possible to toggle antialiasing from the options menu, I believe!

(The switch to off-screen rendering also allows for post-processing filters, should I decide to implement any in the future.)

I believe that I previously mentioned the addition of screen-shaking when the player is hit in combat. In the week just past, prompted by it being mentioned as a useful piece of accessibility, I believe, I made this feature optional: it should now be possible to toggle this screen-shake on or off from the options menu.

Finally, as per usual, there were a few minor bugs fixed that don't seem worth a more-detailed mention.

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

[Thaumaturge]

Blog post (26th of June, 2017)
Poetry, Shading, Level-building, and Movement

Greetings and salutations!

For this week's screenshot, some tidbits of traversal in the "pit" area that I've been working on:



The week just past was far more productive than the one before, I feel! Much of the work done was technical, but--as partially shown above--the first level continues to progress. Let me elaborate:

To start with, something slightly tangential: I spent some time listening to some of the game- and movie- related music of Gavin Dunne (a.k.a. "Miracle of Sound"), and was inspired to try something similar for A Door to the Mists. I'm no great musician or singer, I fear, so I've kept it to text--a poem, essentially. You should be able to read it here:

"Lose Myself in the Mist".

On a related note, I've rearranged the website just a little:

• Gone is the "media" page (I believe that I concluded that it didn't make a lot of sense to have a single page for media related to all and any projects).
• Instead, the project-page for A Door to the Mists now has sub-pages each for "videos" and "screenshots"--and one for "Lose Myself in the Mist", above.
  
  • These sub-pages each have navigation links, allowing visitors to quickly return to either the "Projects" or "A Door to the Mists" pages.
• On a minor note, I've removed the old concept/promo art that I had previously posted there.

Along with this, I replaced the screenshots on those pages with newer ones.

Returning to the game itself, as I said, a fair bit of the week's work was technical in nature. I made a number of tweaks to both climbing and crouching; overall, I feel that both of these should be smoother and less buggy, now.

(For example, I believe that I found a place in which the player could stand from a crouch and have their "standing collider" immediately intersect a wall, thus resulting in the character being ejected out into the "pit". This should no longer happen, thanks to adjustments to the collider used to detect whether there's space enough to stand.)

On a similar--but slightly less successful--note, I discovered that it was possible for the player to push themselves into a particular low tunnel while still standing, despite the tunnel being (ostensibly) too low for this. This resulted in some glitchy behaviour (such as the camera clipping through the ceiling). Further, this has been an issue in at least one other part of the level, as I recall.

The issue, it seems, is that the player-character's physics collider is "pill-shaped", and thus curved on the top. This means that, as it's pushed into certain ceiling surfaces, it's forced downwards. The game's logic tries to push it up again, and glitchy behaviour can result.

I tried two separate adjustments to the player-character's physics in attempts to solve this issue, but neither worked out.

For now, then, I'm simply keeping an eye open for such places, and attempting to adjust the level-geometry to be less prone to such issues. I've done this for the tunnel in question, for example, and thus far it seems to have worked.

Moving from gameplay to graphics, I've further tweaked the various shaders in use. Perhaps the most interesting change (to my mind, at least), is "normal quantisation":

In short, normal-vectors--or rather the components thereof not aligned with the surface normal--are now divided up into "bins" by length. The number of bins, however, varies by distance from the viewer: the further away the fragment is, the fewer bins there are, and thus the less-complex the normals are. This slightly simplifies normals in the distance, the intention being to reflect the simplified strokes that might be used in painting a backdrop. The effect is somewhat subtle right now, but overall, I like it.

Returning to level-editing, work continued in the week just past on the first level, and especially on and around the "pit" area shown in the animation above. It's not quite done, but I feel that it's coming close.

You might note in that animation that the distant ledges have a cool light about them. This comes from another "blob-light", pale, large, and dim. Perhaps more noteworthy, however, is that the light's direction is a bit odd: this particular "blob-light" produces light shining inwards, towards the origin of the "blob", rather than radiating outwards.

I also changed how the player's translation-lexicon is updated in this level. Up until this point, the player's lexicon was automatically updated as soon as they entered the level. I wasn't terribly happy with this, so I've now added a "book", found in the outdoors part of the level, that produces this effect instead.

The prologue level saw a few touch-ups, too: the outer wall was made a little paler, the vines draping it have seen changes to their normals and shininess, and the interior pedestals have had some fixes to their geometry.

Finally, as per usual, there were other changes and bug-fixes not mentioned above.

As you can see, a somewhat busy week! :D

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

[Thaumaturge]

Blog post (3rd of July, 2017)
A Return to Grass

Greetings and salutations!

For this week's screenshot, a look at some changes made to the aesthetics of the prologue level:



As shown above, the week just past saw a return to work on the prologue level, as well as further work on the first level. Let me elaborate:

Work continued on the "pit" area of the first level--and indeed, barring some elements around its edges (in particular the doors that open onto two of the tombs), I think that it's more or less done.

As part of this, I blocked off a particular approach along the platforms in this region that I felt made traversal a little simpler than I'd like.

Doing so proved surprisingly tricky: as it turns out, the movement mechanics of A Door to the Mists are sufficiently forgiving that it can actually be somewhat hard to completely block off a route. However, this is perhaps not entirely a bad thing, I feel: while it may add to the challenge of designing levels for this game, I like that the mechanics allow the player to move around so easily. Will I make good use of this freedom? That depends, I daresay, on how well I design the levels, which remains to be seen...

As mentioned above, I also went back and began touching up the aesthetics of the prologue level in the week just past. In particular, I focussed on the vines hanging on the outer walls, and--once again--on the grass filling the courtyard, two elements that I hadn't been quite satisfied with.

The vines were a little tricky: I was happy with the colour-textures that I had for them, but not their "flatness", as I recall. However, the colours were arranged in my working-file as a single layer per vine-cluster, meaning that I didn't have access to the individual leaves for the purpose of generating normals; attempts at processing the image in GIMP didn't help sufficiently. I tried simply painting in randomised normals (I even made a little program to generate and print out random normal-map colours within a given range), but wasn't happy with the result.

In the end, I turned to Blender. The basis is a simple "leaf" model, which was then duplicated over and over again to build up new vine-clusters. These were given colours appropriate to a normal map via a trick that I picked up from a forum-post: I created a simple, circular image containing normal-map colours, then applied it to the leaves using Blender's ability to generate UV-coordinates from normals. The leaves were then given random orientations and offsets via a simple Python script. Finally, the new vines were rendered twice: once to generate a normal-map, and then a second time to generate a depth-map.

These two images were then imported into GIMP and applied to generate various layers (including masks), which in turn produced the final colour- and normal- textures.

The process has taken a few iterations to get quite right (indeed, I'm not yet quite done, I think), but I'm overall reasonably happy with the results.

As to grass... Those of you familiar with these blog entries may recall my previous struggles with that verdant foe of mine. I believe that I had previously attempted traditional approaches to grass, but found them unsatisfying, both in appearance and performance. I ended up settling on a particular look that worked well enough on both counts--but I wasn't quite happy with it.

In the week just past I tried again. Having identified antialiasing as a source of performance issues, I reimplemented a more traditional approach to grass, and, with antialiasing off, found that it worked acceptably. After a fair bit of tinkering, I managed to produce something that both looks and performs well enough that I'm reasonably satisfied--and rather more so than before, I believe. The frame-rate does drop somewhat when antialiasing is enabled--but then, it does so in certain unvegetated scenes, too, so I'm inclined to lay the blame at least partially with it, again.

Finally, as is often the case, there were a few other things done in the week just past, but which don't seem much worth detailing here.

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