The jam has now ended, and so this is the last change-log update. I'm going to do a postmortem in a day or two when I've had time to process the experience.

Day 7

The game really came alive in the last day or so, and it was a real joy to work on for this final day as a result.

I started the day by fixing something inherent to the engine's core design: The engine would only execute one entity's turn during each tick of the update loop, leading to weird inconsistent timing behaviour. Now, the engine processes all the updates until it reaches an entity which requires player input, and then the UI handles all the events which arose as a result. This leads to a much smoother gameplay experience. It will still stutter when there are animations to play, but it's visible when that is the case. I also added filtering so we don't display animations for onscreen entities, to further smooth things out.

Content

After this, I started work on implementing more game content, which primarily boiled down to "cards" and "enemies", each of which had associated graphics. I started with the Thunder card, because I thought it would be interesting to introduce a ranged enemy to the experience. This also meant implementing AI behaviour so that it would move close enough to strike you and then trigger the attack. We reuse the animation for the attack, but the enemy still needed a sprite, as well as the image for its card.

Once this enemy was in, it occurred to me that the thunder enemy is probably immune to thunder, so I figured out the idomatic way within our system to implement that (entities can be passed events to examine and "cancel" or modify as necessary), so the entity now has logic to decide it is immune to the attack or not. This isn't perfect, but for the pressurised rush at the end of a jam, it was clean enough.

I followed up Thunder with the Fire card. This ended up being 1.5-2 times the work because the effect of Fire was to conjure a Fireball, which would move in a straight line until it hit something, in addition to the enemy who will be casting them. This involved changing how the targeting interface works so we can pick "spaces" in the world rather than specific entities, as well as handling the implications of pathfinding around projectiles. It turns out that if you say that squares containing any entity are expensive tile for the sake of pathfinding, all your enemies will dodge every projectile, so instead I treat them like empty tiles, which is less realistic but much more fun. The "fire wizard" who casts fireballs back at the player is able to reuse the ranged logic from the Thunder cloud, although I had to make it more general to allow arbitrary actions.

Finally, I wanted an enemy who doesn't directly harm you, but imposes a status effect which might cause you problems at a critical moment, so I created the "Shadow". I had a partial card implementation for "Dark" already, but it was just for tests. I expanded it to reduce attack and defence on the target and renamed it, before creating the enemy who casts it. This enemy also uses the "ranged" behaviour, but with a different range, to be more interesting.

UI and Polish

At this point, the game became challenging and quite fun, trying to manoeuvre the space and avoid all their effects to succeed, but the game became quite difficult to play without already knowing the mechanics, because there wasn't much communication about what was going on. So with a couple hours left in the jam, I focused on UI improvements to surface the player and enemy statistics, as well as animations for effects. The code for this ended up being a little messy but under time pressure I'm proud of the result. It makes the game much more accessible to players when you can view the current conditions you are experiencing, as well as your stats, and the enemy stats.

I also added the animations for receiving "buffs" and "debuffs" so that it's clear when you are hit by something negative and positive.

Release

One of my anxieties for working in a game jam is running into problems while preparing the distributable for the game.

To combat this, I made sure at the start of the day that all my build tools worked as expected. This involved preparing a pre-release of DOME and making sure my automated tools for publishing to Itch were configured correctly. I published a test build around mid-day as a test, before continuing the main development. As we reached the final hours, I was more mindful of good "safe exit points": Moments where the game was in a complete and low-bug state which could be playable. When I reached these safe points, I'd tag the code and make a release, so that there was always something playable, just in case I broke a core system trying to add the next feature. Fortunately this didn't happen, but the security made the final hours a lot less stressful.

The End

All in all, I'm really proud of what I've produced and released, although there's a couple of systems and behaviours I'd like to change moving forward. I hope everyone enjoyed watching the game develop, either on stream with me, via twitter screenshots or through these devlogs.

Keep an eye out for the postmortem in a few days.

Find Out More

You can follow me on Twitter, subscribing to my twitch stream here, or catching up on my YouTube channel, to keep up to day with future developments, both on this game and my other projects!