5 years after releasing Avoid (2020), we've finally released another game: Dynamismal. In Dynamismal the player controls a yellow square as they traverse challenging single-screen platforming levels with dynamic physics. We'd like to share a bit about how Dynamismal was made and what makes it interesting from a technical standpoint. The source code is publicly available on Codeberg for your benefit under the AGPLv3, we hope you can learn something from it.

We used a wildly different tech stack to Avoid and Mini Tanks, the game is written in C99 using raylib for graphics, input and window handling and Box2D powers the physics and levels are described using Lua. We did this because over the last 5 years we've been trying out different technologies, creating lots of unfinished prototypes for larger games using Monogame/FNA, SFML, Vulkan and flecs, we found that Raylib was really easy to get started with, creating momentum at the start of our 4-month development journey.

We made Dynamismal for two reasons: the need to finish something, but most of all a comment on our 2016 Scratch game The 100 Level Platformer saying "meh". The 100 Level Platformer was a challenging single screen platformer game with mostly static levels but a very basic set of rules. Inspired by this we sought a simple art style for Dynamismal, which conveyed simple rules but had challenging levels which we extended by leveraging Box2D for some very interesting mechanics. This is why the source code has "hlp" all through it, referring to "Hundred Level Platformer".

Looking though the code, you may have noticed that the project is split into 5 subprojects, we split the project like this to support our level system. On the surface, levels are defined by lua scripts, but if you look closely the script is only called once by the game to initialise the level. Infact, these are only descriptions of levels - lua acts as more of a description format than a scripting language. We did this so we wouldn't need to include lua in the web build, the levels are loaded by a processing tool which then packs them into a binary format for ease of loading. But how do we get obstacles to move, following a pattern?

Sequences! Sequences are sort of a custom virtual machine for controlling an obstacle. There is a list of operations "ops" which are run in sequence, with ops to rotate and move obstacles, give obstacles mass, wait for an amount of time and conditional jumps based on "triggers". This system gives us a surprising amount of flexibility to implement interesting levels without the game needing to call lua scripts each frame which could be bad for performance. This also opens the door to making a visual level editor, sometime in the future. This is probably way over-engineered for a game of this scale, but it was fun and interesting to develop.

Our screen system may also be of interest to some raylib developers. Instead of having an array of screens and an enum to switch screens, we implemented a screen "stack" which is similar to how other UI libraries work (I think). The game will always render and interact with the screen at the top of the stack, however previous screens are kept until they are "popped off" the stack. This makes things like pause screens very simple to implement.

Looking back, there's of course a few major changes I would make if I were to start again, but perfect is often the enemy of good.