DeltaBlade 2700

Project Type:

Technology:

Platform(s):

Role(s):

Status:

Development Period:

Academic / Group

C++, CMake, GitLab, Vulkan

Nintendo Switch, Linux, Windows, Mac OSX ARM64

Engine Dev, Platform Dev

Released on Steam; Complete on Nintendo Switch

1/2019 - 7/2019; 08/2021 - 12/2021

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

Input System

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.

Cross-Platform
- Linux, Windows, Nintendo Switch
Cross-Device
- 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.
Serialization
- 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

Input Contexts

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.