next »

[MegaTiny]

I'm still so intrigued by this game.  Looking forward to the final release (however far away it is).

[Thaumaturge]

Thank you! That's really encouraging to read! :D

While the full game isn't yet nigh, I'm hoping to post a revised version of the demo in the near future; it's intended to cover the same portion of the game as the previous demo, but with a lot of revisions and several additions in response to feedback that I've had.

[Thaumaturge]

Blog post (28th of October, 2019)
The Week of the Wooden Figurine

Summary: In which a wooden figurine is detailed--a process that proves difficult; more pottery is added to level two; an editor-bug is fixed; a "dripping water" effect is work-in-progress; and the "general text" font is replaced.

Greetings and salutations!

This week's screenshot shows an update to a recently-added collectible, found in level two:



That collectible took up most of the week, as I recall! Even so, a few other things did get done, too:

To start with, the collectible. I mentioned this item in a previous blog-post, I believe: a small wooden figurine that previously was just examinable, now promoted to becoming a collectible. In the week just past, then, I reworked it for close-range viewing.

The geometry had only minor changes: a few more vertices here, adjustments there, and so on. Likewise, the texture-map was fairly straightforward--albeit with the unusual fact of my painting it in the Blender (my choice of 3D modelling software), rather than in GIMP (my choice of image-editor).

It was the normal-map that really caused trouble.

My usual process for creating normal-maps involves painting a greyscale height-map in GIMP, converting that to a normal-map via a plugin, and then going over the result with the smudge tool. And I did make headway in doing so for this model.

But I found that the feathers that line the figurine's body, in particular their slope from end to base, proved tricky to capture in a height-map.

So instead, I turned to 3D sculpting in Blender: I modelled the feathers in a high-poly mesh, then baked that as a normal map that could be incorporated into the previously-painted normal-map image.

I'm not terribly familiar with 3D sculpting; I've experimented with it before, but only a little. Thus there was a fair bit of fumbling and a number of false-starts and mistakes. But I persisted, and found in the end that it seemed worked rather better for this model than the height-map approach.

On the image-editor side, I also discovered the rather neat "Warp Transform" tool in GIMP. This allowed me to "nudge" bits of texture around, and thus to make adjustments on the image-side.

And between sculpting and "warp transforming", I achieved results that, if not perfect, proved satisfactory at least, I believe!

(That painted height-map didn't go entirely to waste, by the way: I used it to displace the high-poly mesh before sculpting, giving me a base to work from.)

As I said, a few things other than the figurine did get done in the week just past: I added more bits of pottery around level two; fixed a bug in my particle editor; and started work on a "water-drip" to include in level two.

But perhaps more salient than those is that I've changed the "general text" font that I'm using in the game.

A Door to the Mists employs three fonts: a "monospace" font for the translation minigame; a "fancy" font for titles, labels, and the like; and the aforementioned "general text" font, for pretty much everything else.

"Everything else" here includes a lot: descriptions, thoughts, conversations, lore-entries, and so on. Thus, with the "general text" font serving so much reading, it seems important to me that it be easily-legible at its intended size.

And alas, for a while now I've been unsatisfied with the legibility of the font that I had been using. While not terrible, perhaps, there were some aspects of it that I felt didn't read well.

So, in the week just past I searched for and selected a new font. (And funnily enough, it turned out to come from the same font-author as the previous one.)

Here is a comparison of the old font with the new; the former is marked with an hourglass-icon, and the latter with a clock-icon.




I think that it's rather better! ^_^

(If you're interested in the font, it's "Seshat", by Sora Sagano. (http://dotcolon.net))

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

[Thaumaturge]

Blog post (4th of November, 2019)
Drip... Splash

Summary: In which new scenes are added to level two; work continues on a water-drip effect; doing so involves a minor addition to Panda3D; and the "Wandering Visual Novel" has a devlog of its own.

Greetings and salutations!

This week's screenshot shows another new scene to be found in the undercity of Tenereth:



As with preceding weeks, the week just past was primarily focussed on adding to level two, with a few other things besides:

To start with, the scene shown above. It's a simple thing, found if the player explores a particular staircase: a brass knife, its tip bloodied, and dried blood nearby.

But that wasn't the only such work done in the week just past.

For one, I added a similarly-simple scene elsewhere, this one perhaps more pacific: a set of (ruined) chairs in an isolated "back-yard" of sorts, suggesting a time when people--perhaps a family--gathered together there.

And on the less-pacific side, graffiti is underway that indicates the once-presence of gangs in this part of the city.

In last week's blog-post, I believe that I briefly mentioned work on a "water drip" effect; in the week just past, I continued with that.

I had already discovered that there was a complication to this endeavour, I believe: There seemed to be no way to reliably offset the moment of a particle effect's first emission. This meant that it was quite difficult to have two effects with the same emission-interval, but with one staggered by a set time relative to the other--as in the case of a droplet falling, followed by a splash as it hits ground.

I tried using Panda-provided mechanisms to enable the "splash" effect after a given period, but of those only one seemed reliable--and that one appeared to give the effect a finite duration.

A simple solution, it seemed to me, was just to offset the particle-effect's internal timer. That way it would naturally start after the desired time had passed, and in a way that should keep its timing consistent with that of the "drip" effect.

But Panda seemed to offer no way of actually doing that.

So, with the go-ahead of a Panda dev, I set about implementing such functionality. It took a few iterations to get everything both working and acceptable for submission (especially given that I wanted it included in an upcoming minor release), but save for unit-tests I believe that it's done! ^_^

And having that functionality, I believe that I now have the dripping-water effect done, ready for minor adjustment when next I export the level. Indeed, I've also added a (possibly work-in-progress) sound effect to go with it.

And other than the above, a few things were done that don't seem worth detailing (such as an optimisation to the setting of the in-level "object of interest" text).

And finally: You may recall that in previous dev-logs I mentioned a "Wandering Visual Novel" side-project. Well, today I posted my first dev-log specific to that project! For now it's only being posted on TIGSource and my own website; I have it in mind to start posting it on IndieDB when the project is further along.

As to the game itself, it's currently going under the simple working title of "Temple VN", and is a story of exploration and the rediscovery of a salient religious document.

You should find the new dev-logs here:
TIGSource
My Website

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

[Thaumaturge]

Blog post (11th of November, 2019)
Graffiti

Summary: In which graffiti is added to level two; the water-drip in the same level is completed; the traversal in the prologue/tutorial level is made easier; and a new game-page tile is worked on.

Greetings and salutations!

In this week's screenshots, a bit of graffiti added to Tenereth-below:




Once again the work of the week just past was largely given to decorating level two, with a few other things done besides:

To start with, the graffiti above. These show what may once have been signs belonging to gangs that were active in that part of Tenereth of old. While largely made in the week before, these were incorporated into level two in the week just past, and their descriptions added.

There's even a little bit of logic connected to some of them, which provides an extra line of description at one such graffiti-place if another has been found.

I believe that in last week's blog-post I mentioned a "water drip" that may be encountered in level two. This is now complete, I believe, with touch-ups to various little parts of it made in the week just past!



On the level-design side, I made further changes to the traversal found in the prologue/tutorial level. I'm hoping that it'll now be easy enough that players will in general find it untroublesome! In particular, I expanded a few of the blocks, and added an additional one near the top to serve as a step.



With these elements coming along, I'm looking ahead towards the intended release of a new version of the demo. To that end, I've begun painting a new tile to be used on itch.io and IndieDB. It's still a work-in-progress, but I think that it's coming along. ^_^

(I also updated the banner that I use on my itch.io and Twitter pages. Now both include my new logo, and the latter uses the header from my website, rather than my YouTube page.)

Otherwise, I made a variety of minor changes in the week just past: moving this object a little; adding more stains there; filling in a description for that; and so on.

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

[Thaumaturge]

Blog post (18th of November, 2019)
Colour Variation

Summary: In which colour-variation is added to buildings and streets; this incurs some additional work; but also leads to possible improvements; and preparations are made towards a new version of the demo

Greetings and salutations!

This week's screenshot shows the revised combat mechanic; while nothing here is new to the week just past, the screenshot itself is: it was taken as a replacement for the now-out-of-date screenshot being used in press-kits and on IndieDB.



The week just past had two main thrusts, I believe: further work on level two, and preparation for the next version of the demo:

As to the level, while a variety of minor changes were made--moving a piece of graffiti, closing a hole that I discovered in the world, and so on--one change was perhaps more salient than most, and led to further changes still:

I had noticed to my dissatisfaction, and had demo-feedback to support this impression, that level two felt a little over-uniform. Part of this was perhaps the lack of things to find, something that has hopefully been ameliorated by various changes made previously. But another part, I felt, was that there was little variety in the colouring of the level: each building was the same colour as the next, and the streets ran similarly unvarying.

As I recall, I had previously experimented with methods of fixing the issue in the buildings, but had found nothing terribly satisfying.

In the week just past, however, an idea came to me that should allow me to apply a flat variation to each building, at little cost in performance, I think.

In short, I apply a colour-scale to each building, which is then interpreted by my shaders as variations in saturation and lightness.

I've tested the method, and it seems to me to be an improvement!

But there is a catch: such colour-scales propagate to child-objects, meaning that anything attached to such a building would likewise be varied. And since not all of my shaders include those same saturation and lightness features, this sometimes resulted in certain elements being unaffected, and so no longer fitting their environments.

The solution that I've come up with, then, is to rework the parentage of the level. Most objects, instead of being children of the building-walls, are now children of the building-floors, which in turn are simply children of the relevant culling-cells.

But this is a lot of work--even with scripts to aid me--and tricky at times. I believe that I'm well into the process, but it's not yet done!

It did, however, lead me to perform some additional cleaning-up of superfluous elements in the level--things like floors inside inaccessible buildings. Hopefully this will provide a slight performance boost!

As to the streets, those on the other hand seem to be easier: with their sparse and generally-simple geometry, I can easily enough just hand-paint some variation into their vertex-colours, to be similarly interpreted by the relevant shader. Once again, I've tried this and been happy with the results. ^_^

As to preparations for the next version of the demo, I made a variety of such changes: I completed a new game-tile for use on Itch and IndieDB (although use on one site or the other may call for some cropping); I painted a new backdrop for the Itch page; I made section-headers for the game-pages; I updated the version-number applied to the game; I added a new in-game splash screen presenting my own logo; and more besides!

Here below are the backdrop and one of the section-headers:




And beyond that, a few other things were done that don't seem worth detailing here!

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

[Thaumaturge]

Blog post (25th of November, 2019)
Troublesome Transparency

Summary: In which I back-pedal on my level colour-variation approach; a new way of doing it may be available; a new key-binding profile is added for certain keyboards; the key-binding profile menu is moved; a new trailer is underway; and an odd transparency issue slows work on that video.

Greetings and salutations!

This week's screenshot shows two minor changes in the game's key-bindings: first, that the menu is now (more or less) centred above its button, and second, that a new key-binding profile has been added.



The week just past was another one of level-work alongside other things--the latter including a start on a new trailer-video:

You may recall that in last week's post I mentioned efforts to apply colour-variation to level two. I continued with that in the week just past; indeed, I completed the work, and tested it.

Unfortunately, while it functioned as intended, some part of it seems to have incurred a terribly variable frame-rate: some views ran at more than a hundred frames per second; while others ran at only around sixty frames per second--or even fifty-odd in one case!

This was... rather unsatisfying.

So, I've back-pedalled a bit.

I've undone the merging of the building-walls and the reparenting of objects to building-floors--those being my best guesses right now as to the source of the frame-rate variations.

I've thus also undone the colour-scaling of the buildings.

Instead, I now have it in mind to apply limited vertex-colouring to certain buildings. This calls for some care, as the geometry of the buildings wasn't designed for this and can easily cause unsightly artefacts in the shading between vertex-colours. Still, I think that it should work.

On the UI side, and as shown in the screenshot above, I've made some changes related to key-bindings.

To start with, I've added a new out-of-the-box key-binding profile:

Based on feedback that I was given regarding the demo, and supported by information from the Panda forum, it seems that some keyboards don't support the user holding down at the same time both one of the WASD keys and the space-bar. This interferes with jumping, and thus traversal, and may be a serious obstacle to playing the game, I fear.

In the week just past, however, I realised that I might be able to work around the issue by placing the "jump" command on the mouse instead of the keyboard. To that end, I've added a key-binding profile that swaps jumping and examination. This may have implications for some of the minigames, but I'm hoping that they'll be minor, and that the swap will allow more people to play the game.

That new key-binding profile, however, has a rather long name. Indeed, it's long enough it resulted in the profile-selection menu overrunning the right-hand side of the options-menu, and being cropped as a result. To solve this, I've now moved the menu to sit atop its button, and more or less centred. (I noticed just today that it wasn't properly centred; I may fix that! ^^; )

I also did some video-work in the week just past, specifically in building a new trailer for the redux-demo. Progress has been somewhat slow thus far, in part because of a lack of footage from the new version of level two--that being not yet ready--but also because of a nuisance issue regarding transparency in Blender:

The text that I'm overlaying on the video is prepared in a standard 3D scene, with a mist-effect used to dissolve it on cue. (And I discovered happily in the week just past that Blender's procedural "clouds" texture is, in fact, three-dimensional! :D) When rendered from the scene, this looked just as expected.

However, when rendered in the video via the "alpha over" mode, there was an odd problem: it was as though areas of full-transparency were being treated as fully-opaque, and furthermore being additively blended!

With some help from the Blender Stack Exchange, a solution was found: in short, I had to apply transparency in a particular way for it to work. It looks as though Blender expects transparency in the "alpha over" mode to be pre-multiplied, and takes non-pre-multiplied values to be emissive. Although why this only seems to be a problem with full transparency remains a mystery!

With all that said, I have a working set of Blender shader-nodes now, and I'm fairly happy with the resulting mist-dissolve! ^_^



And along the way I implemented various changes and fixes that don't seem worth detailing here!

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

[Thaumaturge]

Blog post (2nd of December, 2019)
A Little Variation

Summary: In which the colours of level two gain some variety; and the new trailer sees progress.

Greetings and salutations!

This week's screenshots show level two, now with some additional variation in its colours:




The week just past was largely divided between the above and video-making:

As shown above, progress has been made on varying the colours of the buildings in level two! There are a few changes and fixes that I yet want to make, but I think that it helps already to make the place less uniform. ^_^

(And better yet, while the frame-rate does vary, it seems to not drop as low and as often as in the version that troubled me on that point.)

There was one obstacle to this (other than the process being a bit of a tedious one): it involved applying vertex-colours with values greater than one. And while I had a way of exporting such values, it turned out that Panda was clamping them to one!

So, based on advice from the Panda3D forum, I've instead placed the relevant data into a second "layer" of vertex-colours--or more accurately, into a per-vertex auxiliary field. (Something that I already had exporter-support for.) My shaders then combine the data from this "layer" of colour with that stored in the standard vertex-colours, allowing me to thus produce the inputs that I want!

Exporting the level takes some time, so while not attending to the level I primarily worked on the trailer that I intend to make for the new version of the demo. I'm fairly happy with its progress, thus far--although I imagine that I'm soon going to want in-game footage to include, some of which may depend on getting level two done and settled!

For now, let me share a look at the (likely work-in-progress) end-slate for the trailer:


(To be clear, the redux demo isn't available yet--but I intend for it to be so by the time that this trailer goes live!)

And while I was at it, I did a few other things that don't seem worth detailing, in particular tweaks to the desaturation of level two's streets, and an adjustment to the position of the popup-menu for keybinding-profiles.

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

[Thaumaturge]

Blog post (9th of December, 2019)
Videos In Progress

Summary: In which the trailer video makes progress; a new combat video is underway; level two may be done; popup-menu items no longer look like buttons; scroll-bars can be operated by mouse-wheel; and the game-window is now "decorated".

Greetings and salutations!

This week's screenshot shows a still from the work-in-progress trailer:



And indeed, that video was perhaps the greatest part of the work done in the week just past, with a few other things done besides:

To start with, the video. As shown above, the text now has a painterly backing--and, not shown there but shown in the gifs below, is now introduced with a slightly-painterly wipe. Beyond that, various transitions have been polished (I hope!), wording has been reworked, music and sound has been set in place, and the end-screen updated (now including a Panda3D engine-credit).

And overall, I think that it may well be ready for gameplay footage to be inserted!

Which is decent timing, I think, as I believe that I have level two ready at last, having given it a few more minor touch-ups in the week just past!

The first two parts of the trailer, in scaled-down gif form:





The new trailer wasn't the only video that saw work, however: I've also started in on a short video intended to give a look at the reworked combat mechanic. As with the trailer, this is still a work-in-progress--although it does at least have its gameplay footage already!

The choice of enemy for that footage is perhaps not ideal, I'll confess: Right now, I have only three enemies implemented. All of those are early-game enemies, and so fairly easy to fight. Only one of them has full defensive capabilities--and that one is of a size unusual for enemies in this game, and furthermore is the simplest of them!

I've settled on showing one of the mummy-enemies. It's not ideal, as the mummies lack proper defences, but hopefully it will at least serve. (And I did at least mitigate the fact that it's an early-game enemy by turning up the combat difficulty.)

On the UI side, I made three changes in response to demo feedback:

First, the items in various popup-menus (such as the resolution selection) no longer look like buttons, and thus take up less space per item.



Second, it's now possible to move various scroll-bars via the mouse-wheel. Alas, due to complications in implementing such a feature in Panda3D's GUI toolkit, I haven't yet implemented support for scrolling a frame with the mouse simply hovering within that frame; the user is instead required to move the mouse to the frame's scroll-bar first. Not ideal, perhaps, but better than no mouse-wheel scrolling at all, I hope!

And finally, I've switched to using a "decorated" window--that is, one with a title-bar. This should mean that the user can simply drag the window around, where before such an action was not available.

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

[Thaumaturge]

Blog post (16th of December, 2019)
Touch-ups and Video Work

Summary: In which a combat video is available; the combat AI sees tweaks; level two has some touch-ups; the new trailer progresses; mouse-capture may be toggled via check-box; the standard check-box image is polished a bit; and level-skipping is disallowed for the demo.

Greetings and salutations!

In place of a screenshot this week, we have a new video! Specifically, the final version of that "updated combat" video that I believe that I mentioned in last week's post:





As the title may suggest, the week just past was one of both touch-ups and video-work:

To start with, and as shown above, the new combat video is up!

I mentioned last week, I believe, that I already had footage for the combat video. Well, in the week just past I ended up re-recording that footage, as I discovered that I hadn't recorded the in-game music along with it!

On the plus side, re-recording the footage also meant that it incorporated a few minor changes that I made to the combat AI in the week just past:

For one, I patched over the mummy's tendency under certain circumstances to repeatedly shove the player, over and over and over again. For another, I added some general code to prevent enemies from using multiple "fake attacks" (things like feints or jitters) in a row. And for a third, I removed a now-superfluous print-statement from the mummy's AI.

(I also tried replacing the mummy's current "fake attack", but wasn't happy with the new version; in the end I just made a very minor change to the extant animation, and left it at that.)

Level two also saw a few touch-ups, as minor issues were discovered and fixed during testing or recording.

And I do think that the level looks rather better now; having a bit of variation in its colouring really does make the place feel less monotonously uniform, I think.



And indeed, I've been recording footage of level two for use in the new trailer video. While there's a bit more that I intend to do, I think that I have most of the footage that I want, and have begun work on incorporating it into the video.

It's tricky at times, figuring out what might work for a given part of the video, or coming up with a good sequence of shots. Still, I think that I'm making progress...

A few very-work-in-progress stills:





On the UI side, I've added a check-box, visible along with the main menu, options menu, and in-game menu, that allows the player to specify whether the mouse-cursor is confined to the game-window. This might be useful should the player want to move the window, or use the mouse in a different application, for example.

(And concomitantly, I removed the semi-undisclosed key-command that previously toggled mouse-confinement.)



I felt that the game's standard check-box image didn't quite work in the setting of this new check-box, so I made a new image for it.

However, while I was at it I did also touch up that default check-box image, and I think that it looks a little better now.

And with the demo (hopefully!) coming up soon, I've once again commented out the code that allows one to skip to any (extant) level. Not something that I want to leave in for the demo! ^^;

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

[Thaumaturge]

Blog post (23rd of December, 2019)
Redux Demo Nighing! (Hopefully.)

Summary: In which the new trailer is done (but not yet available); game-pages and press-kits are updated; the redux demo is, I think, near-ready; a significant performance issue delays the demo; that delay gives time for additional changes; various tweaks and fixes are enacted; a week off is declared; there may be a special blog post on 3 January; and a well-wish for the season is given.

Greetings and salutations!

This week's screenshot shows one more still from the new trailer:



The work of the week just past was a blend of fixes and tweaks to the game itself, of trailer-making, and of updates to game- and press- pages ahead of the new demo:

To start with, the new trailer was finished in the week just past! Some elements proved a little tricky (such as the ending to the music-track that comes just before the end-screen), and I'm not entirely happy with everything--but I think that I'm happy with the trailer as a whole.

With the demo having been nighing, I also set about updating various press-kits and webpages, replacing old screenshots and videos, and so on.

One part of this involved extracting some gifs from the trailer-footage, and adding them to game-pages; let me share two of them here:





As to the state of the demo, I had hoped to have it ready today, and indeed I think that it's close to ready. However, I then discovered a significant performance issue: in short, it seems that I'm not cleaning up my levels when I exit from a level into a cutscene. I imagine that this will be fairly easy to solve; but it does still mean that the demo isn't ready--yet.

And on the plus-side, this means that I have some space in which to make a few other small improvements that I now have in mind.

As part of work towards the demo, I attended to a variety of issues in the game itself during the week just past; for the most part these don't seem worth detailing here. (Although it was a bit alarming to discover that the "loose tiles" in level one seemed to have no collision! Thankfully, this seems to have just been a case of incorrect collision bit-masks, perhaps due to past changes in that system, and was easily fixed.)

With Christmas here, I intend to take about a week off, starting tomorrow. As a result, there will likely be no blog-post next Monday.

However, if all goes well, there may be a special blog-post on January 3rd--so keep an eye out of that!

And finally, whatever you may celebrate or observe at this time of year, I hope that it's a happy one for you. And if you neither celebrate nor observe anything at this time, then I hope that you have a happy few weeks nevertheless. ^_^

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

[Thaumaturge]

Blog post (3rd of January, 2020)
REDUX DEMO RELEASED!

Summary: In which the redux demo is released!

Greetings and salutations!

The big news is that the Redux Demo is out!



You can find it here:
https://thaumaturge-art.itch.io/a-door-to-the-mists-demo

(And that itch.io page has been significantly revamped, too!)

Press-kit:
http://thaumaturge-art.com/press/sheet.php?p=a_door_to_the_mists

And with the demo, a new trailer!






This new demo incorporates myriad changes--most documented over the course of these blog-posts--made either in response to feedback or on my own account. And I do think that it's rather better than the previous demo!

Some of the major changes are these:

• Reworked combat!
  
  • An updated approach to controlling the action
  • Reworked AI
  • More-detailed accessibility/difficulty options
• Improved traversal
  
  • Both mechanically and in the layout of the first two levels

• Performance improvements
• More things to see and find in the third level

I hope that you enjoy the redux demo, and I'd be interested to hear feedback on this new version of the game! :D

I won't keep you long, then--stay well, and thank you for reading! ^_^

[Thaumaturge]

Blog post (6th of January, 2020)
A Minor Update

Summary: In which the Redux Demo has been released; a particle-effect causes trouble; the demo sees an update in response to that trouble; and a variety of minor changes are made.

Greetings and salutations!

This week's screenshot shows a leaf from a troublesome particle-effect...



The week just past was dominated by the release of the Redux Demo--not only was that release perhaps the biggest news of the week, but pretty much all of the work of that week was done for or in response to it:

To start with, as mentioned above and as mentioned before, the Redux Demo is out! :D

I'm quite anxious to hear what people think of this new version, so if you're interested, please do try it and let me know!

Now, the introduction to the screenshot above mentions a troublesome particle effect. Specifically, it was discovered that on some systems, simply minimising during the first level (that is, the prologue level) could result in a crash! A crash which was tracked down (thanks in large part to a poster on the Panda3D forums) to the above-mentioned particle effect, which provides "falling leaves" for the trees in the level.

Simply put, it turns out that there's a problem with one of the forces applied to the particles in that effect--at the least as I was using it. It's been reported to the engine developers, and they seem to have located the problem.

For the purposes of the demo, however, I've taken the simple solution of removing the relevant forces and giving the particles an explicit velocity in the appropriate direction.

And indeed, an updated version of the demo has already been uploaded with the revised particle effect. ^_^

The other changes made during the week just past were fairly minor and undramatic, I think: I made my personal logo-splash automatically advance after a few seconds, and fade to black before it does; I commented out the code that allows me to skip to a given level when testing; I updated the copyright year to 2020; and I removed the explicit horizontal positioning of the game-window, instead having the window-manager just centre it.

That then is all for this week--stay well, and thank you for reading! ^_^ (And happy playing, if you do try the demo! )

[TonyManfredonia]

I have to say — it's been ages since I've been on this website due to a number of reasons (*ahem*...way too many deadlines, hahah!).

But, I also want to say that I am absolutely THRILLED this is still alive and well. I've scrolled through pages and pages. Wow. WOW! It's come so, so far.

Keep it up. Seriously. I'm thrilled you're still rolling forward with A Door to the Mists! Looking forward to more

[Thaumaturge]

Ah, that's really heartening to read--thank you very much! :D

And indeed, I do intend to keep going, and hopefully release the full version in due course. ^_^

Welcome back to the site, and I hope that your deadlines are treating you well--neither so few that you're short, nor so many (or so clustered) that you're overwhelmed. ^_^

[Cosmocat Games]

Hmm, I had turned on notifications so I would hear when the new demo was out but I never got anything! I only just now noticed that it's out.

I'm still working my way through the tutorial (most recently, I died during the combat part), but just dropping some initial thoughts here:

• Pretty minor, but there's no option to choose which monitor to play on, so I can only play on my second monitor in windowed mode.
• I see that the resolution list was tightened up!
• Gripe: dying during the tutorial completely restarts the game (vs restarting the tutorial area).
• There are some visual artifacts in the tutorial (shadow map, I believe). (I can screenshot or video if it's not something you're seeing on your end)
• I was able to get to the top of the pyramid this time, but still had lots of issues with climbing (below).
• I like the concept for the combat, it has a kind of classic RPG feel to it. It could use with some more "oomph" overall (particles, screen shake, faster anims, heftier SFX, etc.), but it's a great start for sure!

Re: climbing:

• The most obvious cause of confusion is that you're supposed to climb the sides of the stones, yet you can simply walk up the front faces of some early on, kind of giving the wrong impression.
• Moreover, there are some cases where space bar needs to be held much longer to climb (the very first stone you come across, for example).
• There are also some sides that seemingly aren't climbable, even though they look like they should be.
• I encountered several glitches with the player just kind of "bouncing" up and down against stones.
• There are also cases where the player is pushed away from the pyramid abruptly (in one case, towards the top of it, sending me to my death).
• Last but not least, I found a minor bug where the footstep SFX remain stuck in a loop despite the player not actually moving.

Sorry to harp on the climbing stuff but it's the first impression and I could really see it deterring some players. An easy (partial) fix to some of these would be to subtly colorize the climbable stones so players don't end up going too far off course and running into the bugs/quirks. (If it helps, I can record a video showing these issues.)

I'll give the tutorial another go in a bit and then hopefully get to the actual game, heh.

[Cosmocat Games]

K back again. I finally passed the tutorial section In my second attempt I ended up in a state where my attacks were doing no damage to the enemy, nor was he attacking me. It eventually passed though. Does this sound familiar?

I'm now in the first main area. A few initial thoughts:

• At this stage it's unclear what the book actually does ("updated lexicon"). There was no indication in the inventory at all.
• Maybe I'm impatient but I'd really love to be able to move faster I've had to make the rounds a few times, and I still haven't found <something>. (Feel free to DM me a hint, heh; I've found the key, cup and ceramic shard)
• IMO the items might blend into the environment a tad too much. I missed several of them on my first round. Maybe some interaction hint? A subtle illumination or something?
• The colour values of the vegetation are quite dark compared to the actual lighting conditions. See below for a recommendation.

Proposed colour values for vegetation based on reference with similar lighting conditions:



Unrelated feedback regarding the "Keep mouse in window" setting, I would suggest automatically unlocking the mouse when paused regardless of this setting; would make life easier for anyone running in windowed mode.

(edit: added recommendation regarding vegetation colour values)

[Thaumaturge]

Thank you very much for the feedback! I really appreciate it! :D

(I don't know why the notification didn't reach you; a platform bug, perhaps! :/)

Warning for long reply-post! ^^;;

Pretty minor, but there's no option to choose which monitor to play on, so I can only play on my second monitor in windowed mode.

That's a good point. I should perhaps look into how to specify the desired monitor!

Gripe: dying during the tutorial completely restarts the game (vs restarting the tutorial area).

Did you not get the option on the death-menu to reload a save? There should, I think, be an autosave just before entering the lower part of the pyramid...

There are some visual artifacts in the tutorial (shadow map, I believe). (I can screenshot or video if it's not something you're seeing on your end)

Yeah, that's something that's on my list to potentially attend to. It's difficult: as a solo developer, I'm not sure of whether I should be putting too much time into something like that--something that will likely only be a problem in a few cases. On the other hand, it is unsightly, and has been pointed out before... :/

I like the concept for the combat, it has a kind of classic RPG feel to it. It could use with some more "oomph" overall (particles, screen shake, faster anims, heftier SFX, etc.), but it's a great start for sure!

I'm really glad that you so enjoy it! :D

As to "oomph"... I really, really don't want to over-egg it. I really don't like the very-flashy effects used in some games (especially "stylish action" games), and I want this a little more grounded, at least.

The most obvious cause of confusion is that you're supposed to climb the sides of the stones, yet you can simply walk up the front faces of some early on, kind of giving the wrong impression.

Hmm... I'm not quite sure of what you mean. Do you mean that having low stones that one can simply step up onto gives the impression that one isn't expected to climb higher stones?

Perhaps I should place a "climb-height only" stone right at the start of the traversal?

Moreover, there are some cases where space bar needs to be held much longer to climb (the very first stone you come across, for example).

You should have only to be holding the space-bar when you come into proximity to the stone (or other ledge); the duration of holding space should be irrelevant. (Theoretically, if you had good timing you should be able to press the space-bar just as you reach range with the stone, then release it as the character climbs. It's just easier, I find, to hold the space-bar throughout the jump)

There are also some sides that seemingly aren't climbable, even though they look like they should be.

Could you point these out to me, please? It might help if I can see what a player feels should be climbable, but which isn't.

I encountered several glitches with the player just kind of "bouncing" up and down against stones.

Hmm... Were you perhaps approaching a steep slope? That can create that effect, as you go up a little, slide back down, then move forward again.

Or are there perhaps regions with iffy collision, that one can get stuck in?

There are also cases where the player is pushed away from the pyramid abruptly (in one case, towards the top of it, sending me to my death).

Hmm... Did this happen in response to jumping? This might happen if you jump while sliding down a slope, I think. Or were you pushed away with no apparent input?

Last but not least, I found a minor bug where the footstep SFX remain stuck in a loop despite the player not actually moving.

Oof, that's not good! I've not seen that happen on my end--I don't suppose that you know how it might be repeated? If not, I can try to keep my ears open for it happening!

Sorry to harp on the climbing stuff but it's the first impression and I could really see it deterring some players.

It's not a problem at all! Indeed, I appreciate it! As you say, this is a player's first impression of the game's mechanics; I want it to teach them well, and to convey itself well.

An easy (partial) fix to some of these would be to subtly colorize the climbable stones so players don't end up going too far off course and running into the bugs/quirks.

That's something that I'm very hesitant to do: a big part of what I'm going for here is that the player should be able to judge by sight what they can and can't climb. Roughly speaking: "Is it in reach? Is it something that I could stand on? Is there space on it? If so, I should be able to climb it."

It might be worth doing some of this for the tutorial, to better teach the player--but I worry about players coming to rely on it, or expecting it in later levels and so becoming stuck for lack of such guides.

(If it helps, I can record a video showing these issues.)

That might help indeed, if you wouldn't mind, please! :D

I have actually made some revisions to the prologue's traversal challenges based on feedback from another player and my own experience--see the upcoming blog-post for a bit more detail! That said, based on your feedback, I might well end up making more!

K back again. I finally passed the tutorial section

Excellent news! :D

In my second attempt I ended up in a state where my attacks were doing no damage to the enemy, nor was he attacking me. It eventually passed though. Does this sound familiar?

Were you perhaps low on stamina? When stamina is very low, you do no damage; as your stamina recovers, you should start doing damage again.

At this stage it's unclear what the book actually does ("updated lexicon"). There was no indication in the inventory at all.

Hmm, yeah--I should perhaps give that a better label. Another player did correctly infer what it did--but then they'd interacted with the relevant puzzle in the prologue and thus had a basis on which to infer. And it's perhaps not ideal to ask so much inference when there's little on hand to confirm it, especially when the puzzle in the prologue that might give a basis for inference is optional...

Perhaps if I instead labelled it "Translation lexicon updated"? Does that make its purpose clearer, do you think?

Maybe I'm impatient but I'd really love to be able to move faster

You're not the first to want that! And indeed, as mentioned in the next blog post, I've actually added a "run" button. It doesn't make you Doom-Marine fast, but a little bit faster, at least!

I've had to make the rounds a few times, and I still haven't found <something>. (Feel free to DM me a hint, heh; I've found the key, cup and ceramic shard)

I've actually added a bit more player-direction for this just recently, as it seems that players aren't considering the intended direction to progress here.

As a quick hint: Look for something to climb.

IMO the items might blend into the environment a tad too much. I missed several of them on my first round. Maybe some interaction hint? A subtle illumination or something?

Hmm... Again, that's something that I'm wary of. I don't want too artificial a feeling for such things... :/

I want... I suppose that I want players to have that feeling of spotting something, of discovering things for themselves; of searching, exploring, finding. Too much hand-holding undermines that, I think; it becomes less "I discovered something" and more "the game indicates to do this to progress", I fear.

The colour values of the vegetation are quite dark compared to the actual lighting conditions. See below for a recommendation.
...

Honestly, that second picture looks horribly neon to my eye. ^^;

And your screenshot is looking at the shadowed side of the mound...

See the shadowed side of this mound, for example (just drawn from a quick image-search):


Still, I can perhaps brighten the lighting of the grass a little bit.

Unrelated feedback regarding the "Keep mouse in window" setting, I would suggest automatically unlocking the mouse when paused regardless of this setting; would make life easier for anyone running in windowed mode.

Hmm... That's worth considering, thank you! ^_^

[Thaumaturge]

Blog post (13th of January, 2020)
Traversal Changes

Summary: In which the prologue traversal changes further; the "carriable object" feature is reworked; and the player can now run.

Greetings and salutations!

This week's screenshot shows yet more alteration to the traversal in the prologue level:



Due to a three-day holiday that I took, the week just past was a slightly short one for me. However, several things did get done:

To start with, and as shown in the main screenshot at the start of this post, I've further revised the prologue level's traversal.

Feedback on the Redux Demo--and indeed, my own experience--showed that this was still problematic, especially in certain narrow, sloped ledges.

The revised traversal tries to reduce or remove those ledges, instead providing a bit of a jump, a large platform, and some "stairs" of fallen stones.

Hopefully this will prove easier for new players; testing will show, I daresay!



Something else highlighted in demo-feedback was that carriable objects were a little problematic: a video of the demo included such objects quite reliably slipping through the floor, which is... a little alarming!

Now, I could have tried to tweak the physics of these objects. But quite frankly, A Door to the Mists isn't a physics game. The physics engine isn't used to solve puzzles or create obstacles. Carriable objects employed physics, but not for game-feature reasons--rather, physics was just a means of making them function. Thus it didn't make much sense for me to spend time fiddling with something as temperamental as game-physics.

So, instead I opted to rework how carriable objects function. Instead of using physics to drop such objects down to the nearest surface, I would just place them in the position to which the player pointed.

As I recall, I was a little hesitant at first: it seemed to me that there was the potential for this change to be quite tricky, and furthermore to end up breaking things.

But I'm glad to say that it proved rather easier than expected! There were a few tricky bits, like ensuring that, given the lack of physics making things fall, the player couldn't place one object atop another, remove the bottom one, place it atop the now-floating former top-object, and so build upwards indefinitely.

But I think that I have pretty much everything working. Indeed, see the following gif for an illustration of how the feature now works:



Demo feedback also prompted a change in the mechanics of traversal: There is now a "run" button. Holding this makes the player-character move a bit faster, enabling greater leaps; concomitantly, the default walking speed has been slowed a little.

Every so often during testing, I've felt the desire to be able to sprint--often, I think, when taking on a particularly long jump. But I was hesitant to include running in the game: it meant adding an extra button to a game that already had quite a few, and it could potentially complicate the design of traversal challenges.

So I tried to take a middle road: I set the player's movement speed somewhere between a "walking" speed and a "running" speed; not so fast that the player sped by the various sights of the levels, but fast enough that one could jump reasonably far and move reasonably quickly.

But still... there were times when I wanted to "run".

I held off, however, until a piece of feedback on the Redux Demo echoed that sentiment: the player in question expressed (multiple times, I think) a desire to be able to run.

So, in the end I relented: the player can now run. The new running speed is a little faster than the old singular speed, while the new walking speed is a little bit slower.

And finally, I made a number of tweaks, fixes, and changes that don't seem worth detailing here! Things like a bit of extra player-direction towards the tree in level one; implementing the provision of default names for manual saves; disabling the prologue's lift when the enemy is active; and so on.

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

[Cosmocat Games]

Thank you very much for the feedback! I really appreciate it! :D

(I don't know why the notification didn't reach you; a platform bug, perhaps! :/)

NP! And oddly, I received a notification around the time you posted this, but nothing before or after.

Gripe: dying during the tutorial completely restarts the game (vs restarting the tutorial area).

Did you not get the option on the death-menu to reload a save? There should, I think, be an autosave just before entering the lower part of the pyramid...

Hmm, not that I recall, but I'll check again.

There are some visual artifacts in the tutorial (shadow map, I believe). (I can screenshot or video if it's not something you're seeing on your end)

Yeah, that's something that's on my list to potentially attend to. It's difficult: as a solo developer, I'm not sure of whether I should be putting too much time into something like that--something that will likely only be a problem in a few cases. On the other hand, it is unsightly, and has been pointed out before... :/

Yeah I can totally relate. If it's something that requires considerable dev effort then probably not worth it. In my case, this kind of stuff is usually just a matter of tuning some engine settings, but obviously not the case for everyone.

I like the concept for the combat, it has a kind of classic RPG feel to it. It could use with some more "oomph" overall (particles, screen shake, faster anims, heftier SFX, etc.), but it's a great start for sure!

I'm really glad that you so enjoy it! :D

As to "oomph"... I really, really don't want to over-egg it. I really don't like the very-flashy effects used in some games (especially "stylish action" games), and I want this a little more grounded, at least.

That's fair but I can honestly say that my first impression was one of "fighting a cardboard robot with a wooden sword". I also think there's risk in underestimating the importance of "game feel"; it's often one of the primary ways in which players connect with your game.

Side note: there's a great talk from one of the Vlambeer guys about this. While it won't entirely apply to your game, it really drove the point home for me.

I have actually made some revisions to the prologue's traversal challenges based on feedback from another player and my own experience--see the upcoming blog-post for a bit more detail! That said, based on your feedback, I might well end up making more!

Will cover all the climbing stuff in a subsequent post, possibly with video. I may wait until the next version as it sounds like the revisions may address some of my feedback.

In my second attempt I ended up in a state where my attacks were doing no damage to the enemy, nor was he attacking me. It eventually passed though. Does this sound familiar?

Were you perhaps low on stamina? When stamina is very low, you do no damage; as your stamina recovers, you should start doing damage again.

Hmm, could be, I'll keep an eye on this and let you know if it happens again. Does the enemy not attack when you're out of stamina, then?

At this stage it's unclear what the book actually does ("updated lexicon"). There was no indication in the inventory at all.

Hmm, yeah--I should perhaps give that a better label. Another player did correctly infer what it did--but then they'd interacted with the relevant puzzle in the prologue and thus had a basis on which to infer. And it's perhaps not ideal to ask so much inference when there's little on hand to confirm it, especially when the puzzle in the prologue that might give a basis for inference is optional...

Perhaps if I instead labelled it "Translation lexicon updated"? Does that make its purpose clearer, do you think?

Not really, but it might once I've gotten a bit further? For my benefit: is this what allows me to read the text above the doors? If so, then I would suggest having an occurrence of such text prior to finding the book, so there's a clear before/after.

Maybe I'm impatient but I'd really love to be able to move faster

You're not the first to want that! And indeed, as mentioned in the next blog post, I've actually added a "run" button. It doesn't make you Doom-Marine fast, but a little bit faster, at least!

Good to hear, and yeah, doesn't need to be anything crazy, just enough to avoid the traversal feeling tedious.

I've had to make the rounds a few times, and I still haven't found <something>. (Feel free to DM me a hint, heh; I've found the key, cup and ceramic shard)

I've actually added a bit more player-direction for this just recently, as it seems that players aren't considering the intended direction to progress here.

As a quick hint: Look for something to climb.

I found one thing to climb and it doesn't seem to go anywhere? I'll keep looking

IMO the items might blend into the environment a tad too much. I missed several of them on my first round. Maybe some interaction hint? A subtle illumination or something?

Hmm... Again, that's something that I'm wary of. I don't want too artificial a feeling for such things... :/

I want... I suppose that I want players to have that feeling of spotting something, of discovering things for themselves; of searching, exploring, finding. Too much hand-holding undermines that, I think; it becomes less "I discovered something" and more "the game indicates to do this to progress", I fear.

I hear that, but if the items are blended into the environment so much that they just look like props, it could lead to some frustrating moments. And there's a pretty strong precedent of having such "quality of life" thing in games these days--in fact, I can't think of any that don't?

The colour values of the vegetation are quite dark compared to the actual lighting conditions. See below for a recommendation.
...

Honestly, that second picture looks horribly neon to my eye. ^^;

And your screenshot is looking at the shadowed side of the mound...

See the shadowed side of this mound, for example (just drawn from a quick image-search):


Still, I can perhaps brighten the lighting of the grass a little bit.

When's the last time you went outside? The lighting conditions in that scene, as well as my reference pic, are basically mid-day sun, which is quite harsh. And everything to the left of the mound is in direct sunlight, so it should be horrible neon.

Judging by the sky, your reference has different lighting conditions; the sun looks lower in the sky, which is generally much warmer and agreeable to the eyes.