Game Prototype
I wanted an environment to quickly make game prototypes. Eventually, I found ebiten, which is excellent for this. Everything on the screen gets redrawn every frame, but you can treat any image as a screen and render to it.
It is also very well suited for graphical debugging, which I used a lot and loved for this project.
For game development, I recommend the following approach:
- Try to follow your initial ideas to quickly make an MVP prototype that is fun to play,
- Keep the code clean, but terse and refactor only where needed
- No fancy graphics programming allowed, keep your artists out of the loop for now
- Do use graphical debugging where it makes sense. Draw lines and boxes to see what is going on.
- Don’t use complicated parallelism, but make sure to keep the game running at 60 frames per second
Performance side note: Even with modern computers, game programming requires various interesting optimizations. I think they are an excellent exercise for any programmer and can highly recommended the process of making some sort of basic game perform well. For example, you could try spawning 10000 enemies in your game. If your code contains an algorithm that runs in O(n^2), this will make your game crawl. Fixing this problem is fun, and there is really good resources available.
Physics without an engine
For this project, in order to achieve a playable demo, I wanted a basic box-to-box, actor-to-obstacle collision, known from any platformer game.
I also wanted it to support high movement speed to avoid constant bugs from actors getting stuck inside walls because they moved too fast.
This was surprisingly challenging. My initial approaches were both slow and buggy. I fixed the performance and ended up closely referring to this excellent tutorial on the topic to work out all the intricate little bugs.
The fun part
I wanted to have NPC characters move around in the level. The level is a fine-grained tilemap that I created as a pixel image. I built the following:
- For every block in the level, run a heuristic to determine if it can be reached by our NPC character by walking or jumping.
TODO: Current version does not take sideways jumps into account, so we are just going X blocks up from any standable surface. - Depth first search, traverses blocks that are reachable by the NPC’s jump height in a connected fashion.
Technical note: Since this happens in a loop, with a queue, I did not feel like storing thousands of copies of the path taken so far on that queue. Instead, it keeps a linked tree which it will use to backtrack the path upon reaching the destination successfully. - Upon finding a path to the target, set down some nav nodes on the floor.
TODO: Needs to stop dropping them into small holes - Have the NPC try to follow those.
TODO: Find a more robust approach for nav point following – current retrying mechanics are not great
TL;DR: Result does not work perfectly but should be good enough to test various gameplay ideas that rely on moving NPC characters.