• Register

An adventurer with a yearning to explore the inaccessible, misty world of magic hears a tale of a door that opens onto that world, located in a lost city. She embarks on a journey through desolate and dangerous places to discover this city and its door, and enter the mist-world.

Post news Report RSS Traversal Changes

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

Posted by on

Greetings and salutations!

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

Screenshot from 2020 01 11 17 49

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!

Screenshot from 2020 01 11 18 15

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! ^_^

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: