Pushing and Falling
As shown above, a new feature has been added: pushable objects.
You may recall that I described in a previous post my first attempt at this feature, and my decision to drop it in favour of carriable objects. The latter haven't been removed, but I've given pushable objects a second attempt.
My first approach was to keep things fairly simple--no true physics, just ray-casts, a plane to move on, and some maths. This worked, but I realised that relying on ray-casts meant either having large gaps between rays, allowing small objects to slip into places that they should not reach, or using an awful lot of rays.
And it seemed a little silly, as I recall, to have a physics engine underneath so physical a feature (I'm using Panda3D's integration of the Bullet physics engine, I believe), but to then implement it in a non-physical manner.
On top of this, there was the matter of carriable objects: as I think that I mentioned previously, the ray-casting solution that I used there, while reliable, had issues with objects falling through each other by virtue of the rays accounting for only a small overlap.
So I decided to rework the underlying code, and use dynamic physics for both falling objects (including carriable ones) and pushable objects.
I've constrained the dynamics a fair bit--there's no rotation, for example. This keeps things simple and stable, but also introduces a few oddities, such as carriable objects not moving with pushable objects when placed upon them.
And it works! There were a number of challenges along the way, but I believe that I solved all or most of them. Pushable objects slide along when pushed, and falling objects drop and stack pretty much as expected.
It Just Bugs Me
That said, doing this introduced some bugs, it seems.
So very many bugs.
Indeed, dealing with these (and other bugs) was a recurring task of the week: Enemies hung in mid-air, and the bodies left after their defeat were misplaced; carriable objects appeared in the wrong places after loading a level; physics-driven objects--sometimes including the player, I think--would at times drift upwards; the player-camera was placed too high up; and more besides.
The recurring experience of encountering new bugs was a little unpleasant, as I recall--but all that I discovered have been fixed, I believe.
Levelling Out
As to the state of the first level's critical path, work continued, and I believe that I have only two or three elements to be done. (Indeed, the inclusion of pushable objects was done with one of those elements in mind.)
Indeed, I made a timed run of the level; my route was probably not perfect, but I think that it was fairly efficient. As it stood at that point, the level took me about seven minutes to complete; less time than I would have liked, I'll confess. (I had been hoping for about fifteen minutes.)
I'm a little tempted to add another layer to the tomb, but also hesitant: it's a fairly simple environment, and I don't want it to become tiresome.
Picking at It
One of the elements that remains to be done is deciding on a new lockpicking minigame. I've been thinking about this a fair bit, I feel, and while I have some seeds that may grown into a new minigame, they remain inchoate.
One problem that I'm hitting is that I don't want the minigame to be easily solvable by brute-force; that is, I don't want players to be able to easily try every combination in a given lock and pass through that way.
More thought is called for, I feel.
A Side of Games
I've been watching some Let's Plays of Resident Evil VII, and one thing that struck me was the collection of little side-games included (as DLC, I think). They each provide a short experience somewhat different from the main game--things like a room-escape puzzle, a wave-combat game, and a variant on Blackjack.
I've been toying with the idea of adding something similar to A Door to the Mists--little extra games, available from the main menu, that provide some arcade-y fare. Perhaps a mini rogue-like that leans heavily on the combat mechanic, or a simple collect-the-items-and-evade-the-monster game.
Of course, they might be superfluous here: I imagine that one reason to include them in Resident Evil is to provide something to return to after completion, thus retaining interest in the game while one waits for the next major DLC. Since I don't plan any DLC, perhaps arcade-y side-games don't make sense for my game.
(It would also add to the development time of the game, of course--even given my thought to rely heavily on assets taken from the main game.)
Miscellaneous
More was done in the week just past--but this post is already long, I feel. Let mention two more changes, in brief:
- The curtain-shader was adjusted to allow for the presence of a "shelf", (conceptually) pushing it outwards, of adjustable height and depth; normal-mapped folds show to a greater degree below it.
- The inventory has been adjusted to show more slots: it's now initially laid out in a four-by-two grid, rather than a single, short line.
Editing
Finally, as I recall a developer asked on Twitter after the editors created by other devs., and I responded with a some screenshots of my own level- and cutscene- editors. Since these may be of interest to any reading this journal, let me include them here, too:
That's all for this week--stay well, and thank you for reading! ^_^