Project: Haste
dive in.
project overview.
-
For those who don't want to know the details...
-
Everything is better with friends!
-
Solid state or hard disk???
-
Let the game begin!!
-
Running? Jumping?! Wall-Running??!!
-
Because regular physics isn't physics-y enough
-
Shotguns and snipers and everything in-between!
summary.
Intent
Throughout this project, I have always wanted to design and implement systems for other designers. My goal was to create entry points for designers to interact with the back end of the game without having to code, such as providing in-editor tunability for every movement mechanic or providing a modular weapons system other designers could use to iterate on different gun types rapidly.
The Project
Project: Haste is a four-player AFPS, where players duke it out in the DSA Play Place utilizing their parkour movement abilities like wall-running, power-sliding, and double-jumping to zip their way around their opponents. With their high-speed maneuvers, players use three weapons each fit for different encounter ranges, giving them the tools to triumph at any distance or speed.
multiplayer.
Multiplayer was the leading hurdle in this project, but once I understood the tools, I began architecting the project around it.
Due to the automatic complexity added to a project by having multiple game instances running and affecting each other simultaneously, I decided to segregate everything in the project into Data, Controllers/Managers, and Front End. Doing this allowed me to easily remove unneeded functionality as the game was synced over the network.
A great example of this is the overall structure of the player character. Because we want to be minimizing the amount of data sent over the network, the player is split into four parts, only two of which are required for non-local players: the data, the controller, the state machine, and the front end. Over the network, the Controller keeps players synchronous, while allowing for the removal of reference to the players data and removal of its reference to the state machine if a player is not the local player.
state management.
The State
The state’s functionality has always remained the same, as it simply acts like a Game Object being instanced, as outlined above. Despite this, it has actually undergone the most evolution since it was first created.
The original version of the state was a regular mono-behavior which sat as a component on a game object with the state machine attached. The state machine would then try and get the component every time it was being transitioned into. This worked, but was quite annoying to set up as it required in engine setup for states.
In order to remedy the in engine setup, I first tried just instancing in the Mono Behavior based states, which was rough on a performance side with the constant changing of states within our player.
So ultimately, abstraction came to the rescue! Keeping states out of the engine itself saved time and made interaction between states, state machines, and controllers much easier, as states are simply fed reference to what they need by the state machine they are built for.
The State Machine
Although state machines are a very common practice within game development, they are often used to manage player states or enemy AI states, but I wanted to be able to use them for anything, so I built the state machine as a base class to be inherited from for use wherever needed. For this project it was ultimately leveraged into our Player State Machine for all player specific state management, and our Round Manager for gameplay state management.
There are four main parts of the state machine: Update, Fixed Update, Transition To, and Setup State. Update within the state machine simply calls the state’s equivalent to Update every frame, and the same applies to Fixed Update, which calls the state’s equivalent to Fixed Update. More importantly, we have the Transition To function, which is overridable for child state machine classes. This calls the exit function of the current state, as well as allows for someone to pass an exit message to send to the next state, which is then setup via Setup State, then it’s entry function is called.
This allows for each state to be treated like its own Game Object with a Start, Update, Fixed Update, and On Destroy function. This is important as our states are actual an abstract class not a Mono Behavior.
game states.
Game states are incredibly important for the health and extensibility of a project. In the case of project haste, it allowed us to easily set up and manage game flow for the project, especially as the overhead of developing state machines had already been done, so it was a no brainer to use them for our game flow.
Project: Haste has a very simple game flow, moving from the main menu to the lobby, then the actual gameplay arena, and finally the podium (visualized in blue to the right). With this in mind it may have been overkill to actually create and manage game-states for the project, but it ultimately helped us by giving us a place to store and interact with game data separate from gameplay scenes.
This was managed by extending from the base state machine, adding the singleton pattern to the mix as well as storing logic related to rounds in both game-states and in the round-manager itself, depending on if they were state-specific, or needed to be used in multiple gameplay states.
A good example of this is our Lobby vs Arena states, which both had logic centered around the games timer. In the lobby map, it is used to keep track of seconds to the hundredth decimal place, ultimately being used in our global leaderboards. This logic takes place in the lobby gameplay state, but uses shared functionality found in the round-manager itself for network synchronization. In the arena state, the timer keeps track of minutes and seconds, and has many in-game events tied to time that are all managed through the arena state, while utilizing that shared functionality.
The setup of using a state machine for game state management has meant that we can easily add game modes just through adding new game-states (possibility for alternate game flow shown in pink to the left)
Ultimately if I were to create the round-management system again for this project, I would take what I currently have and create a better designer interface so game-states could be managed both in and out of editor.
player states.
The States
The player’s states work as a way to further segregate code and talk with the player controller. The player has eight main states that can chain with each other, not including our cut movement abilities. Players can run, jump, crouch, slide, fall, wall run, and wall jump. Utilizing state management diagrams was crucial in the project for understanding state functionality pre-implementation.
Each player state acts as a separate wrapper for custom physics as a closed system, that then gets placed upon the previous velocity determined by previous states. For example the wall run holds all of the logic for determining which wall is being run on, which direction the player is running in, managing their horizontal and vertical velocities, etc. This is all held within the state, and this logic does not interact with other states, only maintaining the player’s velocity after a new state is transitioned into.
custom physics.
In Project: Haste, movement is the most important factor. Early in development, we began to run playtests on our movement system, and quickly found it to be the “secret sauce” of the game, at which point we knew we needed to chase the fun of our movement system.
Every player state previously mention contains logic for completely custom player physics, utilizing a Player Data scriptable object that contains all the tunable fields for the other designers on the team to utilize for balancing and tuning.
Why custom physics? For me it came from multiple viewpoints. The first reason was increased predictability, next it was easier for network synchronization, and finally it allowed for ultimate tunability.
One of the biggest downfalls I have with purely physics based systems (ie. Unity Rigidbodies) is that it can become incredibly unpredictable when you are relying on forces to move your player. Adding too many forces together can create problems like inconsistent jump heights, variability in control when changing directions, etc. Of course these can all be worked around, but we really wanted to create something great.
Another upside of this is it fit easily into my custom data serialization for the player, with no need to rely on NGO’s Rigidbody synchronization components, which I had found to behave strangely during prototyping. This allowed me to easily synchronize players positions, rotations, and animation states, as well as interpolate their positions based on their serialized velocity.
Finally we have tunability. I knew iterating on our movement was going to be pivotal to the success of the game, so I wanted top give the designers access to everything they needed to customize the movement to what players expected prior to the creation of our map. Doing this allowed for our movement to go through many iterations incredibly quickly, even being iterated on during playtests based on echoed user feedback.
Doing all the physics myself most definitely contributed to the fantastic feeling of flow present in Project: Haste, but it was definitely not easy. Even though it was my favourite part of the project, it also led to many interesting problems with differences between functional vector math in theory needing to be modified to work properly in an in-engine environment. States such as the slide gave me trouble due to interesting collision calculations, and the difference between a downward or sideways collision often being mixed up on sloped surfaces. It was problems like these that caused me the most headaches, but the most excitement when they were overcome.
modular weapons.
The Components
Second to the movement being the secret sauce of our game, we also had to design and iterate on three different weapons. Rather than taking an approach where I hard-coded the weapons functionality and then had the designers tune them individually, I instead decided to build a modular weapon system that allowed the designers to create whatever form of hitscan weapon they wanted.
To achieve this, I created a couple of core components: The weapon component, which controls any Weapon Behaviour, such as Aim Down Sights , Shoot, Hitscan Shoot, and Overheat Shoot (all shoot components extend from the Shoot component, allowing for easy creation of new shooting types).
Ultimately in Project: Haste we ended up with three weapons that all used the Aim Down Sights component as the secondary fire feature - but all weapons include the capability to use Weapon Behaviour components as Primary, Secondary and even Tertiary fire abilities, even though we ultimately just used primary and secondary for our gun balancing.
The main Weapon script, as stated above, is a controller for the other behaviours. What it does is identifies first and foremost whether a behaviour is discrete or continuous, meaning “Can I click, or click and hold”. Once this is checked, it simply calls the abilities “use” function which comes from a common interface shared by all weapon behaviours. This allows the designer to then configure whichever weapon behaviours they want.
This became both a strength and a weakness for us, as we went through a very ambitious faze of slightly increasing (tripling) our weapon scope because of the fast iteration available to our designers… needless to say, they got a little bit haste-y