Nuclear Voxathrone is a project in progress done in Voxatron mostly driven by my love for the game (as in most of my projects) Nuclear Throne. Voxatron is a particular fantasy console as it’s the first one to be designed with voxel displays in mind instead of screens. I already imagined how Nuclear Throne would run in 3D, had plans for low-poly models but never went through this project at all.
Nuclear Throne is a top-down twin-stick shooter developped by Vlambeer where a bunch of mutants fight through hordes of enemies and many different environments to reach the mysterious Nuclear Throne in hopes of change and rest after surviving in a post-apolyptical barren world. It bears many elements from the roguelike games, being a roguelite like permadeath, random level generation and loot, while sticking to some shoot-em-up inspirations by having situations where bullets can’t be counted by how frantic the situations can become.
Voxatron being the parent project of Pico-8, it also has a limitation on the amount of processing done per frame, limiting greatly the possibilities of having hundreds of enemies or bullets in the game. The first focus of the programming sessions for this project once the basic mechanims were implmented was to make everything fit Voxatron’s limitations while still being able to have Nuclear Throne’s love for bullet hell. This implied quite a lot of testing and reimplementing. Here’s a few items of refactoring or redesign:
- I opted first for a quad tree to cut down on collision detection. It worked quite well but I had two limitations : I couldn’t determine how to dynamically update it and the base CPU cost just outbalanced any improvements agaisnt a scenario without it. Using just a grid with square cells sized by n-pixels implies a slightly base higher memory cost but was almost free and allowed to reduce the amount of collisions down to a few around an entity.
- Collisions cost also a big chunk of the time budget. I first intented to use separating axis theorem to have solid collisions without worrying too much and it was proved it was pretty costly when an entity actually hit a wall. Circle colliders were used for any entity as it felt the most organic for entity-entity collision, but circle-polygon for entity-map was too costly. For the latter, I downgraded the collision system down to AABB (Axis-Aligned Bounding Box)-AABB collision with minkownsky distance inspired by this blog post and again, a big chunk of CPU was freed this way, allowing for more complex levels or more enemies without Voxatron slowing down.