DeltaBlade 2700 is a local multiplayer ninja with jetpacks action arena game. I was one of the original five people that created the game. We loved the game so much that 2 years later, we came back and rewrote it. We wrote an entirely new engine from scratch and recreated the original game to bring the game to the Nintendo Switch. There were nine programmers in the team.
This game was featured in PAX West 2019 and is available on Steam.
CPU-Based Particle System
Before the rewrite of the engine and the game, I wrote a lot of prototype code that is meant to explore how fun the game can be. I wrote this particle system in C with two aims
Modifiable init, update, and exit behavior
Resue particles when they expire
It was a simple task writing function pointers that each particle would use. An emitter is responsible for holding all its particles and firing them. As for reusing particles, I separated the dead/alive flag for each particle in a separate array for cache reasons.
After writing the system, I have used it significantly, as shown below.
Rain and Mist Effects
Body parts particles and animated smoke particles
Sparks when swords collide
The Input System was my main focus on this project. As we developed the game for multiple platforms, we needed our cross-platform solution. Moreover, we needed the input system to be compatible with a range of devices and all the features an Input System may expect. Below are the elements that I designed and coded for my Input System.
Linux, Windows, Nintendo Switch
Keyboard, Xbox Game Controller, Nintendo Switch Jon-Con
Input Context Switching
Allows different input mappings to be active so that the main menu can have a different mapping than the deathmatch.
I dictated a format and wrote a parser to serialize the Input System data
Abstracted Input handling
The game dev side only handles abstracted input, defined by the Input Context.
Retrospective Paper PDF
The Input Manager was a large part of my contribution to the project, and it was worthy of writing a retrospective paper reflecting on it. The report starts from my research and moves into my initial designs. After each milestone, I have had to modify my plans to suit the engine better; this report documents that too. It also documents what I think could be good ways to move forward and improve my designs.
As the engine supported the Nintendo Switch's HID system (which code is under NDA), I knew I could not rely on third-party libraries. In order to handle all the different systems and devices, I abstracted a Raw Input layer. Each OS would then write its own translation code that converts its own system inputs into my abstracted Raw Input.
For Windows and Linux, I wrote an SDL Input Manager that translates SDL input into the Raw Input. I wrote a similar module for the Nintendo Switch. Both mappings exist in a text file I serialize and can be modified on the run.
Cross-Device Cross-Platform Work
With the cross-device and cross-platform handled, I still needed a way to translate a Raw Input into an Abstracted Input. So, I designed the Input Context to fulfill this role.
I wrote the input contexts to transform a Raw Input type to an Abstracted Input. Thus an axis can map into a button, etc.
The Input Context exists on a stack associated with an input device. This is designed so that each device can have its own mapping.
Finally, I also serialized each Input Context so they can be read in and modified at run time.
Sample Code Snippet
Below is a simplified header file meant to show the interface from which game developers would interact with the Input Manager
To specify an InputContext, game developers have to write into a custom ".txt" file which I parse. Below is an example of all scenes that are UI-based.
Developers can use a MappedInput to query if the Abstracted Input is pressed.
Scene Transition GUI Tool
I wrote the scene module in the original engine. Its a very simple system using C, as shown below.
I wrote code that reflected what scenes were written and used WinAPI to write this model. With this, developers can swap Scenes on the fly and even test their Scenes repeatedly.
I also used this tool to automate the testing of the game. For example, I sequenced a looping series of scenes using this tool and had the game run overnight on 30 machines with debuggers to test for bugs.
Automated testing on 30+ machines
Outside of the coding, I kept track of bugs and issues via Airtable. I kept the tasks updated and tracked everyone's progress.
I also conducted monthly Test Sessions. Below is an example of a report I hosted and wrote at the end of the month.