RUNLIKE

Run-Like Postmortem

Run-Like was a timed test of my ability to learn a new game engine and push my game development and programming skills. This project marked my first time working in Godot. While I found that the engine has several advantages over others, particularly in how easy it is to build tile-based environments, create sprites, and animate characters, I was less drawn to its node-based workflow, which at times felt somewhat arbitrary and more geared toward beginner developers.

For this project, I set out to create a roguelike platformer, a genre combination I had rarely seen before and one I believed Godot would be well suited for. With only about a month to complete the game as a solo developer, I had to stay aware of my scope and focus on implementing the core mechanics necessary to make the experience functional and enjoyable.

My biggest achievement was on the technical side: I designed a camera system that allowed the camera to follow rooms dynamically. The system determined how the camera should adjust its vertical position based on checkpoints placed at the start and end of each room. In simple terms, I created logic that compared the endpoint of the current room to the starting point of the next room to determine whether the transition required an upward or downward movement, then adjusted the camera accordingly. I also added extra parameters to account for edge cases and fix issues in the system’s logic.

The biggest roadblock I encountered was my early decision to lock all rooms to a fixed size. Because I hardcoded many values, such as the camera viewport and movement script, this made room design much more restrictive later in development. When it came time to create levels, many of which were designed under rushed conditions, it became difficult to build rooms that felt balanced rather than too easy or too difficult. This limitation ultimately led me to implement a level difficulty system, allowing more challenging rooms to appear as the player progressed through the game.

Looking back, one of the main things I would do differently is prototype multiple room sizes before committing to a single standard. More broadly, I learned the importance of recognizing when a technical solution intersects with a game design decision. When a choice affects both systems and overall player experience and may be difficult to reverse later, it is worth taking the time to evaluate it carefully from both perspectives before moving forward.

P.S. I wrote everything above before fully testing the exported build. I had originally planned to spend more time creating additional levels, but I decided to stop where the project was, build it, and upload it. That ended up being a very lucky decision. On the final day, I discovered that the way I was handling level transitions using res:// paths behaved differently in Godot exports than it did in the editor. Because of that, I had to quickly rework my level redirection system so that the levels were preloaded into variables before being called. Had I pushed off exporting until later, I likely would not have had enough time to troubleshoot the issue and still meet the deadline. It was a good reminder that exporting can introduce entirely new problems, so it is always worth giving yourself at least a full day to catch and fix build-specific errors.