next »

[Thaumaturge]

Blog post (8th of April, 2019)
What Do You Mean, "The Table is Transparent"?!

Summary: In which a cutscene sees work; pain-slowness is removed; a few tweaks are made to level two; and a frustrating and unexpected transparency is dealt with.

Greetings and salutations!

This week's screenshot is an excerpt from the work-in-progress intro-cutscene to level two. It's an establishing shot of the location of the level, Tenereth:



The week just past was largely another art-week, but in which a few other things were dealt with, too--including one surprising, initially-mystifying, and slightly annoying issue...

To start with, the art: During the week just past I continued to work on the intro cutscene for level two. I finished off the backdrop for the fourth scene, painted the backdrop for the second (which is shown in the screenshot above), and started in on the backdrop for the third. Furthermore, I implemented the second scene; like the first scene, it's a simple one.

Overall, I'm fairly happy with my progress there! ^_^

On the technical/gameplay side, what should happen when the player falls from sufficient height that it incurs a warning that too great a fall results in death? Up until the week just past, such a fall (or rather, the impact that ended it) had three effects: First, a red border signifying "pain" would appear on the screen--much as when the player is injured in combat. Second, the character exclaimed in pain. And third, the player's movement was briefly slowed a little.

In the week just past, I removed that last effect. In short, I felt that it added little, and that the gradual recovery of movement speed made the point of complete restoration somewhat hard to detect. Indeed, it occurs to me that in a game in which leaps are so important, and in which jump-distance is affected by speed, having the player's current maximum speed be unclear--even if briefly--was likely a poor idea.

I also fixed or tweaked a few things in level two.

To start with, a particular curb no longer visibly pops into view, and I changed the distance at which a few objects were examinable. (The latter to prevent them from being examined before taking the jump that leads to them.)

Perhaps more interesting was an odd issue involving transparency:

I think that it was in the week before last that I discovered that there was a rendering issue at at the edges of certain stains on a certain table-top: through those edges I could see objects behind the table.

Thinking that I had simply forgotten a tag on the stain-objects, I checked them--but they seemed to be comparable to various other, well-behaved stains around the level.

I activated a debug mode in Panda3D that flashes transparent objects, and looked at the stains. And here I discovered something very odd: it looked as though the tables were draped by some unknown, fully-transparent object!

And indeed, having transparent objects overlap can result in rendering issues.

And yet, when I examined the scene in Blender, I found no such object. It was perplexing.

Eventually, I realised what was likely happening: there was indeed no such additional object. The transparent object was, in fact, the table itself--or rather, part of the table--some of it was being treated as opaque, and some of it was being treated as transparent!

It would seem that the reason for this was that some of its vertices had vertex-colours with alpha-values (that is, "opacity" values) less than one (one being "fully opaque"). Panda3D was detecting that transparency, and thus sorting those elements into the "transparent" rendering-bin.

Furthermore, I discovered that there were a number of such objects scattered around the level--although these others were fairly harmless, I think.

In some cases I think that it was due to the use of vertex-colours to store information for my shaders; in others, it was likely the result of their use to inform some of the scripts that aided me in building level two. (And there may have been some that gained such colours by accident.)

It was a bit of a frustrating issue, as I recall. :/

Thankfully, however, the solution was quite simple: asking on the Panda forum, I was directed to a tag that I could add to such objects that essentially marked them as "not transparent". With this in place, the troublesome table is (and other such objects likewise are) treated as being opaque, it seems--and thus no longer incur transparency-ordering issues with stains placed atop!

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

[Thaumaturge]

Blog post (15th of April, 2019)
Below the Streets of Tenereth

Summary: In a cutscene is completed; parallax is used; and a broken cutscene is fixed.

Greetings and salutations!

In place of a screenshot, this week I have a video: the full introductory cutscene to level two!





The week just past was almost entirely focussed on the above-shown cutscene:

To start with, I continued and completed work on the backdrop-elements for scene three, then implemented the scene in the cutscene itself.

Where most of the scenes in this cutscene are fairly basic, scene three is a little more complex: It shows a downwards pan from a street of Tenereth to the under-city below. To that end, it's composed of several layers, allowing both the street and the under-city to parallax as the view moves.

Getting everything to line up quite right, to move as intended, and to do so without leaving gaps between layers, proved a little tricky at times, as I recall. In particular, the under-city layers were painted in their final states, while their in-cutscene tracks start at their initial states, meaning that I was more or less working backwards.

(I also found that I'd neglected to extend those layers downwards as called for, to account for the regions exposed by the parallax effect. This, however, only incurred some additional painting, and some adjustments in the cutscene editor.)

The fourth and final scene of the cutscene was also implemented in the week just past. (I had painted the backdrop in a previous week.) This one is a simple scene: just a slow zoom on a doorway, with text overlaying it.

With all of that done, I moved on to finding music for the cutscene. After much searching, I ended up using a piece that I already had to hand, having used it in previous cutscenes. While perhaps not perfect, I think that it works fairly well here.

And with that, as shown above, the intro. cutscene to level two is now complete! ^_^

Along the way, I discovered that the alternate-ending cutscene had broken at some point. Specifically, the code that attempts to import a custom cutscene-script was failing in the case of the alternate-ending: there was no such script, and the code was throwing an error that I wasn't handling. As this cutscene had previously worked, my guess is that the error thrown in this situation changed between Python 2.7 and Python 3.

To fix the problem, I simply added a stub-script to the cutscene. Not perhaps an ideal solution, but an expedient one.

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

[Thaumaturge]

Blog post (22nd of April, 2019)
The Key-Mapping Retrofit

Summary: In which additional device support in the key-mapper is worked on; key-map profiles are added; and a handful of assorted changes are made.

Greetings and salutations!

This week's screenshot shows some changes to the key-mapping module. Since these changes are work-in-progress, and haven't yet been reflected in the main game, this screenshot comes from a simple test-program--hence the simplicity of its appearance.



The week just past was almost entirely given to work on the key-mapper, with only a few minor things being done otherwise, I believe:

As mentioned above, the main work of the week just past was on the key-mapping module. Specifically, Panda3D recently added support for devices other than keyboard and mouse (such as gamepads). However, these additional devices are not handled in entirely the same way as the the keyboard and mouse, and thus some retro-fitting was called for in the key-mapper. In addition, with the ability to use a variety of devices, I wanted to add support for selectable key-map profiles, allowing convenient selection of mappings, where available.

Overall, the retro-fit proved to be... somewhat of a headache. Figuring out quite how to work with some of the device-handling elements, especially within the previously-built framework of the key-mapper, proved quite tricky. And in addition to that general difficulty, I bumped into various problems along the way.

Still, with the aid of one of the Panda3D developers, I believe that I've made significant progress. It's not quite done yet--there's at least one bug and one or two major features yet to be dealt with, I believe--but I think that it's getting there.

One new feature that's working better than I'd expected is profile selection.

For a while I wasn't quite sure of how to handle multiple profiles: while saving and loading them seemed likely to be easy enough (and it was), I was uncertain of how to handle switching between the automatically-updated "custom" profile and any previously-saved ones. Should the "custom" profile be overwritten by any and all changes? But then would it be counter-intuitive to select the "custom" profile after selecting and changing another profile, and to find it no longer the same as one left it? And so on.

It was tempting to just take the easy route and not provide the option to save new profiles. This would leave the player with only the default profiles and a single auto-saved "custom" profile.

In the end, however, I found a simple solution that enabled both default profiles and user-saved ones: simply put, the "custom" profile isn't explicitly selectable. With the "custom"/"current" setting not available to select, it's hopefully more obvious that selecting a saved profile resets the current mapping. The "custom" profile still exists, but behind the scenes, ensuring that changes aren't lost between sessions.

There is still at least one issue with profile-saving that I want to look into, but overall it seems to work well, I think! ^_^

Aside from key-mapping work, I also removed a superfluous full-stop in a piece of text; made minor changes to some key-mapper test/example programs to get them to run in Python 3; added a convenience feature to one of my DirectGUI sub-classes; and made the very beginnings of work on a new key-mapper test-game, which I hope to use to get feedback on the key-mapper and its new features.

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

[Thaumaturge]

Blog post (29th of April, 2019)
A Key-Testing Digression

Summary: In which a game is made to test key-mapping; and a few minor bugs are addressed.

Greetings and salutations!

This week's screenshots come from a little digression that I made in the week just past--more on which in the main of the post:



(The name is a stand-in for now.)

The week just past was... perhaps not my most productive, I fear. Still, some things did get done:

As shown above, the majority of the work of the week just past was a digression: a little side-game, in this case made as a sort of test-platform for my changes to the key-mapping module. My intention is to release it, and ask players to give feedback on the key-mapper.

As to what sort of game it is, it's essentially a brief, linear twin-stick shooter: the player moves from one room to the next, clearing them of enemies in order to open the door leading onwards. At the end, a boss is fought.

There is a bit of a twist, however: shooting drains the player-character's health--but conversely, health is regained simply by sitting still. Of course, sitting still while being shot at isn't necessarily easy... Furthermore, the player's size--and thus the target that they present--is proportional to their health. Thus having more health makes one easier to hit.

The game itself is almost done, I believe--just a few things remain, as far as I'm aware.

The key-mapping module isn't quite ready yet, however: there are some things still to be done, and some elements whose intended behaviour I haven't yet figured out.

On the technical side, I made two minor changes behind the scenes: I added a response to the entry of an invalid file-name in the key-mapper's profile-saving code, and a workaround for a minor nuisance-issue in Panda3D's option-menu.

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

[Thaumaturge]

Blog post (6th of May, 2019)
Axes Mapped!

Summary: In which the key-mapper test-game is polished; the same gains a new player-ability, and with it a new control-type to test; the key-mapper itself is near-done; axial-inputs can simulate button-presses; the key-mapper is polished and documented a bit; and an old key-mapper example-game is removed.

Greetings and salutations!

For this week's screenshot, one more look at the key-mapper testing-game that I've been working on; this shows a new player-ability that's been added to the game, as well as the final boss:



Most of the work of the week just past was technical in nature, focussed once again on upgrading the key-mapper to support Panda3D's new input-device handling:

To start with, something (slightly) aside from that: I polished (and have just about finished) the key-mapper-testing minigame that I showed last week, and which is shown in the screenshot above.

As part of this, I added one more feature to the game: the player can now press a button to emit a burst of power, shoving away enemies and destroying all projectiles.

It's not without cost to the player, however: using it removes a quarter of the player's health at the time. This means that it will never remove all remaining health--it's always safe to use in and of itself--but overuse can leave the player vulnerable...

And in terms of key-mapping, it gives the game an "activate on button-press" control to test.

On the technical side, I continued to work on the functionality of the key-mapper, including the polling of axial-inputs; keeping proper track of the axes in use, and of what controls they're bound to; and saving- and loading axial inputs.

This work proved quite difficult, I'll confess. (Perhaps in part because I was rather short on sleep over the week just past.)

Still, I think it's almost entirely done: to the best of my knowledge--and presuming that nothing comes up in testing--I have only one more minor feature to implement! ^_^

One feature that I'm quite happy with is that, in addition to the usual axis-polling, axial inputs can be used as button-presses, calling press- and release- callbacks just like key-press events.

In all fairness, this is done via the standard polling interface, meaning that a sufficiently quick press or a sufficiently low frame-rate could result in such an input being missed. However, under most modern conditions I think that it should be fine, and it broadens the options available to players.

I also did a little work intended to make the key-mapper module more friendly to other devs.

One such change that's perhaps worth mentioning here is that the key-mapper no longer assumes the use of my game-saving module. Instead, it now requires that devs provide their own file-saving methods, allowing them to approach the matter as they prefer. Conversely, however, I provide a separate convenience-script that implements saving and loading via my game-saving class, for both my own use and that of any others who might wish to use it.

On the non-technical side, I also did a bit of cleanup and documentation regarding the key-mapper module.

And finally, I removed my old key-mapper example-game. While I did like it, and it had its charms, it also had some elements that might have called for more work given the key-mapper's new functionality. On top of that, its files were largely included in the base key-mapper directory, cluttering the place somewhat.

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

[Thaumaturge]

Blog post (13th of May, 2019)
Control-Mapping Done!

Summary: In which the key-mapper is finished; said key-mapper is available on GitHub; the GitHub version includes a Lander-style sample-game; a test-game for the key-mapper is available on itch.io; A Door to the Mists' key-mapper is updated to reflect the recent changes; A Door to the Mists now uses the new key-mapper functionality, and can thus be played by gamepad, etc.; and a new "wandering visual novel" side-project is begun.

Greetings and salutations!

This week's screenshots show the key-mapper for A Door to the Mists, now updated with the key-mapping module's recently-added functionality!

(Please excuse the lack of a mouse-pointer in them; it wasn't captured with the screenshots.)




The week just past was a busy one, I feel! Once again, most of its work was related to the key-mapping module, whether directly or peripherally:

To start with, I believe that I have my key-mapping module complete! ^_^

This involved some tweaks, and the addition of a few new features (including the separation of the key-mapping "profile" directory into a "default profile" directory and a "user profile" directory). But perhaps more than that, it involved a lot of bug-fixing, as I discovered a number of issues along the way--but thankfully, I believe that I've fixed all that I found.

With the module pretty much done, I believe, I've uploaded it to GitHub, available for other Panda3D developers who may find it useful. If you want to take a look, you should find it here:
https://github.com/ArsThaumaturgis/KeyMapper

The GitHub version includes a very, very simple example-game that I put together in the week just past. It shows the use of the module in the context of a game, as well as some of how the module's appearance can be customised. The game itself is a simple Lander-ish thing, in which the player flies a little craft around an arena, collecting gems while avoiding the walls.



I also included a dummy saving- and loading- script in the repository, so that programs, and especially the test/example programs, may be used without showing error-messages at every attempted control-binding.

I believe that in last week's post I mentioned a short game that I had made in the hopes of getting feedback on the key-mapper. Well, with the key-mapper done, I uploaded that test-game to itch.io. If you're interested in trying it (whether for feedback or just for fun), you should find it here:
https://thaumaturge-art.itch.io/the-gauntlet-of-the-controlled-crystal

And with all of that done, I moved back to work on A Door to the Mists itself. Specifically, and as shown above, I updated its key-mapper to reflect the changes that I've made: in particular, the "reset to default" button has been removed, replaced by the appropriate profile-related UI-elements.

Furthermore, I set to work on integrating the key-mapper's new functionality into the game itself. This actually went pretty smoothly, I believe! Indeed, for the first time I got to play A Door to the Mists with a controller. ^_^

(I still much prefer keyboard-and-mouse, but I like that the option is there, and that it works.)

This did incur the addition of a few extra controls to the game--specifically, one each for the four axial-directions involved in looking. (That is, up, down, left, and right.) On the plus side, adding these means that if someone decides that they want to look around via keyboard, they should be able to do that.

The only real stumbling-block is that I have a very cheap gamepad, which confuses Panda3D a little; in particular for this game, the right thumb-stick doesn't seem to report itself as Panda3D expects. However, I think that the engine-developers may have recently added some fixes for this--we'll hopefully see when the next version of the engine is released!

I will confess that I do fear that my current gamepad controls feel rather awkward in the combat mechanic. (Although it's possible that some of this is due to my inexperience with gamepads.) It's something that may call for further thought...

And over the course of the week a number of other changes and fixes were made that don't seem worth mentioning here!

Finally, I've started in on a new side-project in my off-hours. I'm currently calling it a "wandering visual novel": visual-novel mechanics embedded in a tile-based, free-roaming 3D environment, such as was used in a number of old RPGs.

I posted a short video showing my prototype, which you should find here:




And a few screenshots:



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

[Cosmocat Games]

I believe that in last week's post I mentioned a short game that I had made in the hopes of getting feedback on the key-mapper. Well, with the key-mapper done, I uploaded that test-game to itch.io. If you're interested in trying it (whether for feedback or just for fun), you should find it here:
https://thaumaturge-art.itch.io/the-gauntlet-of-the-controlled-crystal

Interesting approach to testing, I like it. I will check this over the weekend and share my thoughts

[Thaumaturge]

Thank you, I really appreciate that! (Both the comment on the approach and the intent to give it a try.) If you do try it, whether you give feedback or not I hope that you have fun! ^_^

[Cosmocat Games]

Thank you, I really appreciate that! (Both the comment on the approach and the intent to give it a try.) If you do try it, whether you give feedback or not I hope that you have fun! ^_^

No problem, it's the least I can do! You've been very supportive and I appreciate it. If there's ever anything specific you want feedback on, feel free to hit me up directly (I'm on here somewhat sporadically).

Re: key-mapper:

• I switched to the gamepad profile as soon as I realized I could. The initial mapping didn't make sense to me (not sure if it was supposed to be dual analog, but it wasn't on my Xbox 360 controller). I remapped as needed and saved a profile without issue.
• I would consider offering multiple bindings so that you can have default bindings for both keyboard and gamepad. As a player, I appreciate when I can switch between the two in a pinch.

The mechanic of shrinking/growing is neat, but a few thoughts:

• I would offer an explanation. Initially, I didn't know why it was happening (or that I could grow/regain strength).
• I would put a lower limit on the size of the player, otherwise you can end up almost invisible, which makes it even more challenging when you're low on health! (this, perhaps coupled with a traditional health bar?)
• Instantly restoring all health, or giving the player something to do, at the end of a level would be appreciated. As it is now, you just need to wait.

Other thoughts:

• I like that the levels are randomized, I wasn't expecting this a first!
• Gripe: "Menu" key immediately ends the game (vs pauses). As a player, I find this quite frustrating.

I have lots of thoughts on possible polish/refinement, but just thought I'd check to see if you plan on developing this further before writing about it?

[Thaumaturge]

Thank you very much for the feedback--I really appreciate it! ^_^

And I'm glad if I've been of service. ^_^

I switched to the gamepad profile as soon as I realized I could. The initial mapping didn't make sense to me (not sure if it was supposed to be dual analog, but it wasn't on my Xbox 360 controller). I remapped as needed and saved a profile without issue.

The weird initial mapping is perhaps due to it having been generated with my cheap-knockoff controller--these apparently don't always report their controls as more-expensive controllers do. I believe that it's something that the Panda3D devs are working on, or perhaps have fixed for the next version.

Sorry about that!

(I think that it was mapped to either dual-analogue or left-stick + face-buttons on my gamepad--I forget which.)

However, I'm glad to read that mapping and saving went well! ^_^

One thing that's perhaps not clear in the key-mapping module is that you don't have to save a new profile if you make changes from the default: there's a transparent "current bindings" file that's autosaved.

I would consider offering multiple bindings so that you can have default bindings for both keyboard and gamepad. As a player, I appreciate when I can switch between the two in a pinch.

Hmm... That's a good thought. I think that it wouldn't be difficult to offer, although it might complicate the GUI setup a little. I'll consider it at the least, I intend! Thank you. ^_^

I would offer an explanation. Initially, I didn't know why it was happening (or that I could grow/regain strength).

Ah, you're quite right! I think that I had explanations on the various pages/thread-postings for the game, but not in the actual game itself. That's a mistake on my part indeed! ^^;

I would put a lower limit on the size of the player, otherwise you can end up almost invisible, which makes it even more challenging when you're low on health! (this, perhaps coupled with a traditional health bar?)

Hmm... I'm loath to set a lower bound or to use a traditional health-bar, because I quite like the whole "your size is your health" idea. However, one possibility that occurred to me during development, and which might have served as a compromise on this, was to have a "starburst" cover the player at low health/size. Think of the end of "Team Rocket Blasting Off Again"/"Star Trek going to warp". That would at least provide a position-indicator to the player, and perhaps also connote that the player has dangerously little health...

Instantly restoring all health, or giving the player something to do, at the end of a level would be appreciated. As it is now, you just need to wait.

Funnily enough, this actually does happen--but it restores the player to half-health, rather than full. That it's half-health is essentially an artefact of the development of the player's initial and final health, I suppose, and I agree that it might have been better to restore the player to full-health.

I like that the levels are randomized, I wasn't expecting this a first!

Thank you! I feel that it helps to provide a bit of replayability, making each run a little different. ^_^

Gripe: "Menu" key immediately ends the game (vs pauses). As a player, I find this quite frustrating.

Hahah, that's fair, I think! I usually would have the "menu" button pause the game, I think (A Door to the Mists even has a full in-game pause-menu), but in this case I suppose that I wanted to keep things really simple, and to put weight on the key-mapper. ^^;

I have lots of thoughts on possible polish/refinement, but just thought I'd check to see if you plan on developing this further before writing about it?

I don't currently intend to take it further, I'm afraid--it was intended to be just something small and fun, a test-bed for key-mapping and something to encourage people to pick it up, I believe.

[Thaumaturge]

Blog post (20th of May, 2019)
Menus Without a Mouse

Summary: In which the main menu is tweaked; and menus start to be operable without a mouse.

Greetings and salutations!

This week's screenshot shows work towards being able to operate the menus of A Door to the Mists without a mouse:



The week just past was, for the most part, a menu-focussed week:

Perhaps the first salient change of the week just past was an adjustment to the main menu, with thanks to critique given via Twitter.

Specifically, it was pointed out to me that as I had it, the title, menu-buttons, and backdrop created a sort of visual loop, and that this might be a little disorienting for some players. One suggestion for dealing with this was to move the title to a position above the menu-buttons--which is what I did.

And concomitantly, I adjusted the mist behind the title (and the buttons, while I was at it) to now flow from left to right, which I feel better fits this layout.

These changes are somewhat visible in the gif above, but as that animation quickly goes to other menus, let me post a gif showing just the main menu:



With that done, as well as a variety of smaller changes that don't seem worth detailing here, I moved on to another major task, one that I've had in mind for some time now:

Controlling the game's menus without mouse-input.

As you may recall, A Door to the Mists now supports input methods other than keyboard-and-mouse. But when using such a method, it might be inconvenient (or even infeasible) to switch over to a mouse in order to control the game's various menus and minigames.

Hence this task: implementing support for control of the various menu-elements via inputs other than the mouse.

It's a task that I'll confess had somewhat intimidated me. And yet, while there have been and remain some challenges in implementing it, the process has actually gone fairly smoothly thus far, thankfully! ^_^

(And my thanks to rdb of the Panda3D forum (who is one of the developers of the engine) for aid in figuring out a tricky problem regarding the operation of popup-menu buttons! ^_^)

That said, this feature is still very much a work-in-progress--there's much yet to be done, I think.

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

[Thaumaturge]

Blog post (27th of May, 2019)
The Question of Tab-Buttons

Summary: In which non-mouse menu-operation sees much work; the mouse can prove an impediment in this; and there is an uncertainty regarding tab-switching.

Greetings and salutations!

This week's screenshot shows further progress on operating menus without a mouse:



The work of the week just past was once again focussed almost entirely on non-mouse operation of the game's menu-systems:

In general, the system has been significantly expanded and refined (and in places reworked). It's a bit clunky, I'll confess, but it seems to work, and to work rather better than it did last week. It's not quite done, but I think that it's getting there.

Indeed, a great number of changes and fixes were made during the week just past, primarily on non-mouse menu-operation, but also on one or two other things. Some proved challenging, if not really troublesome (such as handling the navigation of dialogues), while others proved quite easy, as I recall. In total there are rather too many for me to want to list them all, so let me just mention two that proved troublesome:

One thing that's proven tricky is the mouse. Simply put, the mouse-cursor remains active even when using input from another device. Thus when navigation brings a UI-element beneath the mouse, the mouse may be seen as having "entered" that UI-element, potentially firing off events and so interfering with navigation. I have some fixes in place via a "mouse-mode" variable, but it's imperfect, and even given that it is so, there's more to be done, I think.

Another problem has been the question of convenient operation of tabs: I have a few menus that contain multiple tabbed pages, and it would be nice to be able to switch back and forth at a button-press, regardless of the currently-selected item.

The underlying functionality of this is fairly straightforward, I think, and was implemented without any real trouble in the week just past, as I recall.

The question, however, is that of what buttons to use. I gather that many games use the gamepad's left- and right- shoulder-buttons for this purpose. But what of players using other devices? And how does this interact with control-mapping? Furthermore, I currently have the "examine" action on one of those shoulder-buttons, and that action has its own use in certain menus.

For now, I have an idea that I'll likely explore--but it does mean adding two more controls to the key-mapper list...

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

[Thaumaturge]

Blog post (3rd of June, 2019)
Navigating Minigames

Summary: In which navigation-work continues; the navigation-system should now be more responsive; navigation-speed can be set via the options-menu; disabled UI-controls are simply skipped over; minigame navigation is attended to; the minigame for which it seems easiest to build navigation proves difficult; and a minigame is dropped from the game.

Greetings and salutations!

This week's screenshot shows further progress in non-mouse navigation: on from the menus to the minigames!



The week just past was another busy one, I feel! Once again, most of the work went into non-mouse navigation, with a few tangents and digressions along the way:

The navigation system itself saw a number of tweaks and upgrades in the week just past:

When a movement-control is held down, the related navigation-action is repeated. That is, holding the "up" button results in the selection of the UI-element above the current one, and a moment later the one above that, and so on.

However, the system should now also respond pretty much immediately to an initial press of the relevant button, regardless of the repetition delay. Thus a series of key-presses results in navigation at the rate of those presses, while a held key navigates at a steady speed. This should, I hope, result in navigation feeling responsive and flexible, while nevertheless not moving too quickly.

Speaking of which, the speed of that held-key repetition can now be altered via the options menu.

When navigating a menu-screen, the system will now skip over disabled UI-elements (unless it has been instructed to navigate specific UI-elements anyway), moving to the next enabled control (if any). This means that disabled controls no longer stop navigation.

There is an argument against this behaviour, I'll confess: if a control is initially disabled, skipping over it might imply to players that the control is never available for navigation. Hopefully, however, the visual change in a control becoming enabled will be enough to make it unsurprising that said control also becomes navigable!

As to menu-specific implementations, the navigation-logic of the game-menus themselves is pretty much done, I believe. With that so, I moved on to the navigation of the various minigames found in A Door to the Mists.

If I recall correctly, I decided to start with the jigsaw-puzzle minigame, reasoning that it was likely to be the simplest of the lot.

It wasn't.

Conceptually, it's straightforward: the player selects a puzzle-piece, moves it around, rotates it, and puts it down. Repeat until the pieces are correctly arranged, or the player gives up.

But there are some complications, as it turns out:

To start with, how does one select a given piece? They're initially arranged somewhat arbitrarily, and the player can drop them more or less freely. Thus they don't have static positions relative to each other.

I considered implementing automatic layout-generation. However, I fear that there are cases in which navigation would be unintuitive, or in which multiple pieces would be candidates for a single navigation-direction.

In the end, I settled on just cycling through the pieces, using either the "forward" movement-button, or the "next-" and "previous-" tab-selection buttons.

Next is the issue of how one rotates the pieces.

With a gamepad (or keyboard-only play), this is easy enough: the movement controls move the current piece, and the "looking" controls rotate it.

But as I had it, with a keyboard-and-mouse layout the mouse controlled the movement of the current piece--and the movement controls rotated it. I could have used the "looking" controls in this case, too--but they aren't necessarily assigned in this case.

Here the decision was somewhat tricky. I didn't see a set of controls that I could presume to be set in a keyboard-and-mouse layout that also made for intuitive rotation controls. I eventually settled on using the "jump" and "crouch" keys. Not wonderfully intuitive, perhaps, but workable, I think.

I'm not happy with making the default control-scheme worse, but I don't see a better solution here, I fear. :/

With that done, the next minigame attended to, as I recall, was lockpicking. This actually went relatively smoothly--a workaround was employed at one point, but otherwise this proved rather easier than the jigsaw minigame, I believe!

(I'll confess that it doesn't work very well when playing with keyboard alone--four keys lack the nuance of either a thumbstick or a mouse. :/)

Last dealt with, and still a work-in-progress as I write this, was the translation minigame.

The layout of this is particularly complex: it has a grid of buttons near the bottom, and above that another grid. Each cell of the latter contains a vertical column of buttons below a horizontal row. Worse, I recall that at least one of these grids turned out to be ordered in an inconvenient manner.

Still, progress has been made--indeed, I think that it's near-done! ^_^

On a game-design note, I've made the decision to remove the ideogram minigame. A few points brought me to this decision: For one, I'm seeing little space for it between its first use in the prologue and its uses much later in the game. For another, it quite closely resembles the translation minigame. And for a third, I'm not confident that it works all that well as a puzzle.

It is a pity: the ideogram minigame is a little unusual, and I do quite like it. But so it goes.

And along the way I made a number of changes and fixes that don't seem worth mentioning here!

Finally, I think that I've mentioned that I'm working on a little side-game, a "wandering visual novel". That too, has made progress, both on the game itself and on related tools. Here's a brief look at a new character-action--to start with, a depiction of one of the hazards of being incautious with scaling; after that, the corrected version, now with a bit of "stretch-and-squish":




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

[Thaumaturge]

Blog post (10th of June, 2019)
Navigation Complete!

Summary: In which translation navigation is completed; non-mouse navigation is overall completed; translation navigation is made less of a chore; and the ideogram minigame is removed.

Greetings and salutations!

This week's screenshot shows non-mouse navigation of the third and (for now) final minigame:



The week just past was another busy one, I feel, and another one focussed largely on navigation, if not entirely:

To start with, as shown above, I believe that I've completed non-mouse navigation in the translation minigame! Indeed, I believe that I've now completed the task of non-menu navigation! ^_^ (Barring any undiscovered issues that turn up later, of course.)

I believe that I mentioned previously that this minigame had proven particularly complex to implement navigation for.

Worse than that, however, was that I had noticed that it was somewhat of a chore to navigate. There were two main reasons for this, I think:

First, the word-tiles that compose the upper section of the minigame each have two parts: a row of letters, and a column of prospective word-roots. One could move from word-to-word via the letter-rows, but as there was one navigation-node per letter, that could be tedious. It was much quicker and more convenient to navigate via the columns, as there was only one per word-tile--but when no roots had yet been added to a word, the columns were unavailable...

Second, the lexicon that composes the lower section of the minigame connected to the upper part, as one might expect. However, the navigation-system was somewhat rigid in how it connected nodes, allowing a given node to connect to only one other in a given direction. What's more, the lexicon could scroll, meaning that there was no static relationship between a given lexicon-button and the word-tile above it. As a result, all lexicon-buttons navigated up to the bottom-leftmost word-tile--which was not always convenient, or intuitive, I fear.

The first of those problems was fairly easy to solve: I simply allowed the player to quickly cycle through word-tiles--more specifically, through the first letters of each--via the "next tab" and "previous tab" buttons, much as with the jigsaw minigame. It even uses a very similar implementation to that used in the jigsaw minigame, as I recall.

The second took a bit more work. In short, what I did was this: I modified the navigation system to optionally accept a list of navigation-nodes for a given direction. Then, when it encountered such a list during navigation, I had it find the list-entry that was nearest on the axis perpendicular to the direction of navigation--the x-axis when moving upwards, for example--and then navigate to that. Thus I was able to have the lexicon-buttons navigate up to whichever word-button was closest on the x-axis, even when scrolled!

Moving away from navigation, but remaining with the minigames, I believe that I mentioned last week that I intended to remove the ideogram minigame. In the week just past I enacted that intention.

This was a surprisingly involved process! There were a number of elements to remove, whether part of the minigame or simply references to it. Still, as I recall it didn't prove too hard, and the minigame is now gone. (Albeit with the code retained in a dumping-ground folder that I sometimes use for such things.)

The prologue level was, I believe, the only one that had an ideogram minigame. That minigame has now been replaced by four simple panels, which, when examined, provide the clues originally given by the minigame.

And aside from the above, I also made a number of changes and bug-fixes 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 June, 2019)
Troubles with Threading

Summary: In which threaded level-loading is attempted; additional UI rollover sounds are added; attacks may have individual sound-effects; the mystery of the half-working "options" shortcut; and progress on a tile-editor for a side-project.

Greetings and salutations!

Much of the work of the week just past was one or more of technical, audio-related, or bug-fixing, so I don't have any particularly interesting new visuals to show. So instead, this week's screenshot comes from my side-project; more specifically, from a work-in-progress editor for it:



The week just past saw bug-fixes, sound-work, and work on one major technical matter...

That technical matter was threaded level-loading. In short, this would allow the game to perform the process of level-loading (or some part thereof) in the background, thus leaving it free to animate the loading screen. This animation in turn might reassure the player that the game hasn't stopped working.

I had previously done something similar for saving. That, as I recall, turned out to be fairly simple.

This did not.

For one thing, it seems that the process of loading a level has become a little convoluted. Not all of it necessarily happens within the bounds of a single update, and the process seems to vary a little bit depending on the source of the load (starting a new game, loading a save, etc.). And at this point, I honestly don't remember why it ended up this way.

I considered re-engineering the process of level-loading to be more friendly to threading. But what I have right now works, and I fear that re-engineering it seems all too likely to produce new bugs and issues, or to re-introduce ones that I'd already dealt with.

Now, on the Panda3D forum it was suggested to me that, instead of attempting to put the whole process into a thread, I might put only the loading of the level's 3D model into a thread--that being the part of the process that seems to take by far the longest.

This seemed more feasible. It involved interrupting the reconstruction of the level-object at a certain point, but that was soluble. And indeed, this approach seemed to work!

But between the convoluted level-loading process and my own lack of expertise with threading, I'm not convinced that it's wise for me to go with this. Without extensive testing, it's hard for me to be confident that everything is working as expected, and there remains the risk of issues arising due to some unanticipated set of actions occurring during threaded loading.

For now, I'm still considering whether or not to go with the threaded approach, or to stick with my current static-but-reliable approach.

I also attended to some sound-work in the week just past.

For one, I added support for attacks to optionally have individual sound-effects for their impacts. This is now used to give the mummy-enemies a separate sound to play on landing their "push" attacks.

For another, I had realised that my menus lacked rollover-sounds--that is, sounds that are played when the mouse passes over UI-controls.

Rectifying this was fairly simple and straightforward, I'm glad to say! ^_^

I was a little concerned that having these play too often might become annoying, but it doesn't seem to me to be so, and advice from the TIGSource forum supports this feeling.

One issue that does arise from this, however, is that moving the mouse rapidly across several UI-controls now produces an unpleasant electric "burr". I'm uncertain of the source of the problem, and am seeking help on the TIGSource forum at time of writing.

Over the course of the week just past I also fixed a variety of bugs. Most of these don't seem worth detailing here, but one was a little odd:

During gameplay, one can press the "o"-key to open the "options" menu. During the week just past, I discovered that it wasn't working.

Specifically, it didn't work at first, but would work as expected if I opened the key-mapper and re-bound it, even if I simply renewed its binding to "o".

This was a little disconcerting, I think. After all, not only was this a long-standing feature, but it prompted the worry that something was wrong in my key-mapping module.

I hunted for its cause. I traced through the steps of loading and binding keys. I even checked partway into Panda3D's source to see whether the relevant event was being properly added, as I recall. But I found no apparent cause for the problem.

Eventually--and I don't recall how I came upon this--I discovered the source of it:

As it turns out, in the main-menu class I had added some debugging key-events--one of which was bound to "o". In short, my key-mapping was (presumably) working as intended--but the main menu was then overriding its key-event with this debugging code!

Thankfully, once found this was easy enough to fix, I do believe; the debugging key-events were no longer called for, and so have simply been removed.

And finally, I've mentioned a side-project of mine, I believe, a "wandering visual novel". Progress has been made there, slow but continuing. Of late I've primarily been working on (or towards) a tile-editor for it. The screenshot at the start of this post shows a glimpse of its current (very work-in-progress) state.

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

[Thaumaturge]

Blog post (24th of June, 2019)
A Bit of Carpentry

Summary: In which a rollover-sound issue is fixed; an opening sound is added to minigames; level two sees some fixes; a new scene is added to level two, and some interaction along with it; a demo is in the works--but has hit a stumbling block; and the side-game editor continues to progress.

Greetings and salutations!

This week's screenshot shows some new props (and one new inventory item) intended for use in a new scene within level two. (Albeit that the colour of the wooden elements has not yet been adjusted.)



The week just past saw bug-fixes, level-cleanup, and the addition of a new puzzle to level two:

I mentioned last week, I believe, that I had a problem with the rollover sounds that I was using for my UI. Specifically, I found that in certain menus swift mouse-movements could result in an unpleasant electric "burr" appearing in the sound.

With aid from both the TIGSource and Panda3D forums, I believe that I found the problem:

As it turns out, there was one type of control in which I was inadvertently providing only a single sound-object for all of a list of (sub-)controls: the drop-down menus. These automatically construct buttons to fill their menu-lists, with the styling of said buttons is uniformly applied from a set of keyword-parameters passed in to the construction of the class. As such, only one sound-object is loaded, and all menu-buttons share that object! And indeed, on examination it does seem that it was only in the drop-downs that the "burr" appeared.

At first this looked tricky to deal with, as I recall. After all, the item-buttons are constructed by the drop-down menu class, not by me.

But then I realised that I was already sub-classing the "drop-down menu" class--and indeed, even overriding the method in which the item-list is set! As a result, I could simply iterate over the new item-buttons in that method, and give each of them a separate sound-object.

This seems to have worked, with no more unpleasant "burr"-sound detected! ^_^

Sticking with audio, I had realised that I didn't have a sound to play when starting a minigame. So, in the week just past I set about fixing that.

The approach that I've taken is fairly simple: I've made a two-beat drum sound-effect, which is now played at the start of all minigames.

I'm not yet sure that I'm happy with the sound itself, as I have yet to test the most-recent iteration in-game.

Level two also saw a bit of work in the week just past:

To start with, I'd discovered an oversight: a certain (important) building had some missing collision-geometry, and seemed to have been passed-by when I attended to fixing certain texture-alignments. These were fairly quickly fixed, I'm glad to say!

Perhaps more interestingly, however, I decided to add something new to the level: a new scene to discover, and a new bit of interaction associated with it.

Near the end of the level was a place where a small wooden ramp allowed the player to progress.

That ramp has now been broken, with only a piece left lying on the ground for the player to find. The player is tasked with extending that piece, and so constructing the ramp. Doing so is enabled via the new scene: a nearby carpenter's workshop, providing wood and tools.

The workshop itself is only partly done; the tools shown above (and likely some clutter) have yet to be added to the level. Similarly, the relevant inventory items and at least some of their interactions have yet to be implemented.

Some time ago, I mentioned a desire to put out a demo, I believe. I've begun work towards, I hope, completing that demo. I've cleaned up the list of collectibles. I've removed superfluous print-statements. I've made some changes in how I handle output-logging.

Unfortunately, I've hit a stumbling-block: the most-recent distributable version of Panda3D has a crashing-bug in the above-mentioned "drop-down menu" class.

I could use a pre-release build (and may well do that for a small test that I have in mind)--but that build is unoptimised, I'm told, which doesn't seem like a good idea for the game's first demo. I could also perhaps drop back to a previous version of the engine--but then I'd lose some potentially-useful bug-fixes made in the new version.

Right now I'm somewhat waiting-and-seeing, as well as being active on the Panda3D forum. After all, I do still have the new scene and interactions to finish first, as well as the above-mentioned small test to run. So we'll see what happens...

And along the way a few other things were dealt with that don't seem worth mentioning here!

As to my side-project, that continues to make slow progress. The tile-editor can now apply ceiling-textures, has a grid overlay, allows one to set some area-specific data, and has the start of support for placing characters. (And perhaps other changes that I'm forgetting offhand!)

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

[Thaumaturge]

Blog post (1st of July, 2019)
How to Pick a Lock

Summary: In which the woodworker's workshop is just about complete; the associated puzzle is done; "grouping" items are improved; lockpicking gains an example; the minigame introductory-sound proves troublesome; progress towards the demo is, I think, made; and the side-game's editor continues to slowly develop.

Greetings and salutations!

This week's screenshot shows the woodworking workshop that I described last week, now implemented in the level:



The week just past saw puzzle-implementation, level-work, bug-fixing, and polishing:

To start with, work continued on the scene shown above, and on the logic for it. Props were edited; the contents of the workshop were laid out and adjusted; the inventory items found therein were placed; the logic for the associated puzzle was developed; and a sound effect was made to depict the action performed on succeeding at said puzzle.

Furthermore, a nearby building which is also involved in that puzzle (as well as its immediate surrounds) saw some minor adjustments, such that the player should no longer be able to simply jump up onto the wall that is the puzzle's goal.

As it stands, the whole thing works, I do believe! The player can find the various items involved in the puzzle, and use them to construct a ramp in that nearby building. ^_^

That said, there are a few touch-ups that I yet want to make, including the moving of objects that turned out to overlap windowsills, and adjustments to certain props.

In doing so, I found that there was a bit of a problem with my "grouping" inventory items--that is, items that group together in a single inventory-slot. When the items being grouped together differed significantly in their sizes, the overall scaling could result in smaller items being a little hard to make out. In addition, the presence of large items could result in the set overlapping a bit too much for my liking.

So I spent some time improving the presentation of these "grouping" items. They now better-adjust to various sizes of grouped item, including rescaling smaller items to be more visible alongside larger ones, I do believe.

My lockpicking minigame is, I think, a little unusual. It involves having the player blindly probe at the contours of a lock, seeking the narrowest inset within.

I felt a little uncertain that my introductory-text for it would adequately convey the concept to new players. So, in the week just past, I decided to add an example to that introductory text: when the text is opened, with it comes a little diagram showing visible contours, and an arrow pointing to the narrowest inset. Hopefully this will help to explain the minigame!



Speaking of minigames, I've been having some trouble coming up with a sound to play when they start. I think that I mentioned last week that I had a prospective sound-effect for this; as it turns out, I wasn't happy with that effect when tried in-game.

I think that the problem, in essence, is this:

I don't want something connected to the physical actions taking place, as I want a sound that works for all minigames, regardless of what objects might have prompted them. That leaves me wanting something less representational.

Elsewhere in the game I've been using gongs, bells, and drums for various purposes, and these seem like they could make for nice introductory sounds. But, alongside the sudden switch to the minigame view, one or two chimes or beats can feel a bit too abrupt and unwelcoming, I fear.

I have another idea in mind, sticking with the idea of drums, but have yet to try it out...

As to progress towards the demo, I think that I'm getting there, bit by bit. I still don't yet know when it might be released--but soon, I hope!

And along the way, I performed a variety of fixes and touch-ups that don't seem worth mentioning here!

And finally, as to my little side-game, the tile-editor that I'm building for it is making progress, I do think, as I slowly build out its features and figure out how I want it to work.

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

[Thaumaturge]

Blog post (8th of July, 2019)
Demo Drawing Near?

Summary: In which the demo seems very nigh; some accessibility is added to minigames; a minigame-begun sound is made; various elements of polish are added; the first "jigsaw" puzzle is polished a bit; and the side-project makes a little bit of progress.

Greetings and salutations!

This week's screenshot shows some touch-ups to the "jigsaw"-puzzle encountered in level one:



The week just past saw a lot of work on a variety of elements!

But perhaps most excitingly, it brought the demo very close to completion, I believe...

While the demo isn't quite done, it's very nearly there, I think: I have just a few things that I want to add to the game itself. Then there are tests to run; screenshots to take; videos to record, edit, and score; websites to update; and announcements/press releases to make and post.

Demo-release feels frighteningly, excitingly close! o_o

I still don't have a release-date in mind; I intend to post a special blog-entry (alongside a tweet or tweets) announcing the date when I have it, so keep an eye out! ^_^

As to changes made in the week just past, let me start with a bit of accessibility:

The combat mechanic already has some consideration towards accessibility, I think: it has four difficulty settings, one of which is an "explorer" mode that has the computer handle combat.

The minigames, however, had no such options before the week just past. I had given thought to how I might approach improving their accessibility, but never come up with something that I was content with, as I recall.

In the week just past inspiration came to me, and I found an approach that, while perhaps not perfect, at least provides some form of accessibility:

In short, each of the three minigames now has an optional "simplified" or "aided" mode. In the case of lockpicking, this has it employ only simple locks. In the case of translation, only word-roots used in the solution are shown. And in the case of "jigsaws", guide-points show how pieces might connect.



This does leave navigation and the in-level puzzles without accessibility options. I'm not at all sure of how to handle the latter, at the moment. For the former, I have ideas--but I fear that they might call for a bit more development-time than is entirely wise as things stand.

I believe that I mentioned in last week's post that I was having trouble coming up with a sound to be played when a minigame is begun. I have an effect for that now; it's perhaps not great, but I think that it works, at least.

The week just past also saw a number of bits of polish applied. For a few examples: various bits of text were adjusted or touched-up (and two missing text-strings added); level two saw some fixes, including the opening of an exit from an otherwise near-inescapable alley; and the vertical positioning of the player's light has been adjusted to (hopefully) improve the visibility of things like table-tops.

(With thanks to BreakfastBat for the comments that prompted my changes to the lockpicking help-text. ^_^)

One of those bits of polish is shown in this week's screenshot, at the start of this blog-entry. Shown there is the "jigsaw" puzzle found in level one. I've somewhat feared that the correct alignment of two particular pieces in that puzzle might be a little ambiguous--especially for the first such puzzle that the player encounters.

So in the week just past I went back and added some extra guidance to it, in the form of short lines on the largest piece that correspond to lines on the smaller pieces.

And while I was at it, I slightly reworked the overall texture of that largest piece, bringing it more in line with the overall aesthetic that I'm going for. What's more, it no looks rather better, to my eye!

And along the way, I made a variety of bug-fixes and minor changes that don't seem worth detailing here!

As to my "wandering visual novel" side-project, that went on a brief hiatus while a personal matter took its usual time. However, with said matter done I've returned to work on it, and have made further progress on the tile-editor. Indeed, I think that I may slowly be drawing near to completion of that! ^_^

(At some stage I may start a separate dev-log for the side-project; perhaps once the tile-editor is done!)

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

[Thaumaturge]

Blog post (15th of July, 2019)
The Hiding of Text

Summary: In which the game's text is hidden; some lore is added; the target-points of conversation-tails are made more reliable; the demo may be a few weeks away; and the side-game's tile-editor continues progressing.

Greetings and salutations!

This week's screenshot shows a conversation-tail now pointing more-closely towards the character's mouth--and some slightly-broken text... ^^;



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

As you may be aware, A Door to the Mists contains a fair bit of text.

With the thought of perhaps seeing localisation at some stage, that text isn't wrapped up into the game's executable when the latter is built. Instead, it remains unchanged in its folder, copied to sit alongside that executable. Thus a localisation can simply be dropped in beside the English-text, and should be automatically detected.

However, this means that a user, casually browsing through the game's directory, might encounter the full text of the game laid out in plain sight. This is especially a concern with regards to lore-entries, which are intended to be uncovered during play.

I would thus prefer that the game's text were hidden. But I also take the view that if users really want to get to the text, then they likely will do so eventually. And indeed, if they want such spoilers, I'm not hugely opposed to their finding them. Thus I don't require that the text be kept terribly secure--just removed from obvious view.

The solution that I've chosen, then--with thanks to Panda-dev rdb for the suggestion--is to employ Panda3D's "multifile" system.

In short, a "multifile" is a little like a zip-archive--or more accurately, a Linux-style "tarball": it's a single file in which can be bundled up multiple files--and indeed, a whole directory hierarchy. Panda can then "mount" such a file in its "virtual file system", which allows the contents of the multifile to be accessed as though they were ordinary files and directories in the file-system. It even allows one to dynamically-import Python-files from multifiles!

I have the basics of using this implemented--it's actually pretty straightforward, as it turns out. As you can see above, it's not yet working in all cases, but I suspect that it will prove fairly uncomplicated when I start looking into those.

Sticking with text, in the week just past I also added a new bit of lore to be discovered in level two. Where the other two entries found there are short stories, this is instead a brief piece of world-building and atmosphere.

This new lore is currently attached to a pre-existing skeletal hand, located in a large, rubble-filled area. That hand, however, was previously rather out of the way--even I sometimes had to hunt around a bit to find it. So I've moved it to a (hopefully) more-visible position.

While the lore-entry itself is written, I believe, the page-image for it is a work-in-progress, and its icon has yet to be made.

(I also spent some time on another lore-entry, but decided that I wasn't happy with it.)

Still somewhat text-related is the matter shown in the screenshot above. As it turned out, the tails of my conversation text-boxes were rather inconsistent in the location to which they pointed.

In short, it seems that their implementation hadn't taken into account the possibility that different character-models might have different origin-points. And as it happens, the models of at least two of my speaking-characters did so differ.

The solution that I enacted was fairly straightforward, I think. In short, I now vertically offset the target-point by the top-value of the character-model's bounding-box, minus a little bit. It's not perfect, but it seems to work well enough! ^_^

And along the way, I implemented a variety of other little changes and fixes that don't seem worth detailing here.

As to the demo, I believe that a new bug-fix version of Panda3D is expected to be released at some point within the next few weeks, so I'm tempted to wait for that before building and releasing the demo. It has a few things that might be handy to have, I think! I haven't yet settled firmly on so waiting, however.

And finally, my little "wandering visual novel" side-project continues; bit by bit work on the tile-editor is progressing. For two things, it now has a layout-viewer, showing a project's Locations and Areas (the former (containing the latter) being collapsible), and work is underway on saving and loading.

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

[Thaumaturge]

Blog post (22nd of July, 2019)
Images of Lore

Summary: In which the language-text is (I think) finished; lore-art is added; a new lore-entry is written; level two sees some minor additions; my build-script is updated; and the side-project tile-editor gains some neat features.

Greetings and salutations!

For this week's screenshot, an icon for a new piece of lore:



The week just past saw a few fixes, additions, and bits of polish:

To start with, I continued to work on the language-text system that I believe that I mentioned last week--there were a few things left undone, and a few bugs found to fix.

For one, I moved the files that hold a given language's name and font-set out of the language-multifiles, to instead sit beside them in the relevant folder. This clutters the folder a little, but it also means that language -names and -fonts can be used (such as in the language-selection UI) without mounting all of the language-multifiles.

And overall, I believe that I have the system working properly now!

On the art-side, you may recall that I mentioned last week that I had added a new lore-entry. In the week just past, then, I added art for it, both a lore-icon and a page-image. I'm quite happy with the page-image in particular! ^_^




The lore-icon was at one point a little more saturated than shown here, and as a result, it "popped" quite nicely. Unfortunately, I found that it "popped" rather more than the other lore-icons, and I thus felt that it commanded a bit too much attention! Hence the slightly paler version now in use, and shown above, and which I feel fits in alongside the other icons rather better.

Still on the topic of lore, I added one more lore-entry to be found in level two. Like the one reported last week, this is a brief piece of world-building, rather than a short-story.

In this case, it's history; specifically, the relationship between the city of Tenereth and brass. Why, after all, are all the tools found in the under-city brass? Why not tougher steel? And is it still so in contemporary Tenereth above?

The page-image for that is still very much a work-in-progress, but as shown in this week's main screenshot, the icon for it has been painted.

Related to this, I made a few (minor) additions to level two itself: The various brass tools found in the woodworker's workshop are now examinable, and have logic connecting them to that new lore. And while I was at it, I also added a stone of a sort mentioned in the lore-entry, used by workers to straighten their tools.

Moving towards the demo, I updated my build-script a little, reflecting some of the recent changes.

And finally, the tile-editor for my side-project has picked up some neat features: One can now add rectangular groups of walls by dragging, and have tiles coloured to indicate which scripts apply where, for two examples.

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