An arena fighter inspired by Super Smash Bros. and Rock, Paper, Scissors.
The game is to be a 2D, competitive, multiplayer, brawler. The game will feature 3-character types with different play styles. Each character will have the same standard type of attacks but will play differently according to their respective style. Primary gameplay will involve players fighting each other in attempt to knock each other out and/or for a higher objective(s). Features a unique set of abilities and a surreal use of real photographs for the environments and game objects.
Inspiration and Initial Design
Inspiration for this game was solely based on the mechanics; I've had a desire for some time to create a game similar to Super Smash Bros. that would include an array of custom characters designed and illustrated by myself. However, with this being my first project I didn't want to get too involved with asset creation and the extensive amount balancing that would be required for more than a handful of characters. It would simply be too ambitious of a first project. Instead, my plan was to create a 'lite' version of the game, featuring only 3 characters, each with distinct play-styles. This would also provide me with a solid framework for the more comprehensive version of the game I'd like to eventually make.
Some initial ideas for the mechanics and theme of the game.
Getting My Feet Wet
Before I did anything involving, I wanted to simply throw something together. It didn't have to resemble anything concrete; I just wanted to get a box moving around on a platform and think about where I should go from there.
Quite literally a box moving on a platform.
As I tried to expand the behavior of the character however, I realized very quickly that the number of if-statements I used would explode. Switch statements and enums representing state were my quick fix, but even then I could tell that this wasn't the right move. It was then that I remembered an article I stumbled on a while ago (before I was ready for anything like this) that covers the exact issue I was having.
State Machines
The answer to my behavior problem was the state machine. The idea is simple: behaviours are consolidated into state objects that can be processed by a single entity (the state machine). If a player wants to jump, the input is evaluated and the state is changed. This allowed for a very encapsulated and scalable model for handling behavior. While the concept sounds simple, it took quite a bit of time before I had this translated into code and even longer for me to critique it and develop a flow for implementing each new behavior.
The state machine class (left) allows for changing states, excuting the state's update method, and switching to the previous state. Each state inherits from an IState interface (right) that possesses basic functionality like enter/exiting and executing the state logic.
Research
When I wasn't developing I was doing research. At times, this literally meant playing Super Smash Bros. Although, 'playing' is not necessarily what I was doing. I would spend time going through each character and understanding how combos are registered and input is handled. During this time, I actually began to pick up on subtleties I hadn't noticed before. For instance, a slow acceleration of the character would gradually move them to a 'full speed' running state. A quick horizontal snap of the analog stick however, would instantly bring the character to a faster-than-full-speed running state.
The player can be seen moving back and forth at a regular speed and then quickly moving to a very fast speed.
I also found out that other people had done similar research in order to find out the different properties of each character. For the most part though, most of my research has been less on game design and more with understanding more technical challenges like how advanced input systems work or when asynchronous programming needs to be considered.
Input Handling
One thing I really took for granted when beginning this project, was how essential input management was. This was particularly difficult when I was trying to evaluate multiple inputs at once. While checking for multiple at the same time is possible, a player must enter all inputs at the same exact time. It also didn't allow for checking the same input twice or chaining.
Not a robust solution for checking input.
Early versions of an input manager involved checking a custom Combo object that contained 2 types of input, inspecting this object to determine how it should be evaluted and then processing the secondary input using coroutines. This was, as it sounds, slow, buggy, and only allowed for checking two inputs.
The overcomplicated ComboMonitor class that utilized coroutines. Notice the variety of different input handlers that had to be created and the many fields that need to be accessed to decide how the input is processed.
Eventually, I found a tip online that suggested removing a dedicated input manager and instead rewriting my custom Combo object to have a CheckInput method that it could run on itself. A combo would be represented as a series of strings that would be evaluated one by one: first button pressed? Move up the chain. Second button matches combo? Move up the chain. Third button not pressed in time. Combo unsuccessful, return false. This model was simple, allowed any sized combos, and reused the same logic for each evaluation.
The much simpler and robust JoyCombo class featuring its own evaluation (Check) method. A large if statement does a thorough check of the possible inputs.
Next Steps
The first phase of developing this game has been a lot of research and trying new things. With a functioning state machine and proper combo class together, development has sped up very quickly and I can now focus on fleshing out each character's movement & fighting profile. At the moment, the look of the game has not really evolved passed the block on a platform state as functionality has obviously been the main focus. Animating characters is right around the corner however, and I plan on doing a preliminary photoshoot for one of the characters to see how animating real images will look.