3v3 Multiplayer Online Car Battle
Designer & Gameplay Programmer
Made in Unity, coded in C#
3 months, 6-man team
DriftKing is a Multiplayer Online Battle Arena game in a 3rd person camera view in which players take control of cars to face off in an enclosed outdoors 3-on-3 arena where they can drive around, and drift to cast spells.
Players square off in a Kill-the-King match, conjuring Fireballs, Thunderstorms, Earth Walls, and Cyclones to outmaneuvre and beat their opponents
I co-designed the game along with 5 other of my colleagues, and also did all of the Gameplay Programming, including:
- Car Handling & Physics
- Control Feel
- Core Mechanics programming
- Spellcasting programming
DriftKing was created on a hazy night out between the Team members. After some weeks of denial, we began thinking about it more seriously as a game. So how did we go from just cooky idea to an actual cohesive and gathered game?
The first step was to understand what exactly got us excited about the game. What is the premise behind it that makes us yell out engine and skidding noises? The answer to this was pretty simple: Drift to cast spells.
The reasons behind keeping this premise and not all the other stuff (it was an RPG game at first) were the following:
- Car Combat games almost always use Twin-stick shooting. One stick controls the car, the other controls the aiming. This means that players doing one or the other successfully, never both. The idea of tying the combat with the actual driving past the dichotomy appealed to us
- Drifting is a powerful action, which is easily repurposed for build-up. The shaking, smoke, skidmarks, all of these elements are extremely potent visual cues as build-up for even more exciting actions
- Since our target market demanded a short, polished experience capable of being developed in a short period of time, an online arena-based combat game gave us that possibility while also enabling a lot of replayability
Resulting Design PIllars
- Everything is Driving -
- Difficulty is Tactical -
- Stopping is Dying -
In the diagram to the right, the red car casts a fire spell at the blue car (1). The red car enters a drift. As the drift progresses, the spell build-up increases. The drift creates a growing damaging area behind the casting car (2). After the drift is done, the red car casts a flamethrower spell directly in front of it, towards the blue car (3).
After we had our pillars down, we just referenced them every time we had to make a decision about the game. How does the game mode enforce them? How should the driving feel? What kind of map should we implement? How do we focus gameplay in the map? should we have pickups? The implications of setting some ground rules for your decisions have far-reaching implications
We asked ourselves all these questions and arrived at our conclusions by referencing our pillars that we would have a strong and cohesive experience at the end.
The Gameplay programming in the game was very closely tied to the Design throughout the project. I took a top-down approach to the controls, thinking of how the game should feel before I thought of how it should play.
After settling on the feeling of the game in broad strokes (we kept our vocabulary vague so as to not lock our Design at the premise), we thought of how this feeling met with our Design Pillars, namely which mechanics the players are using in the game.
The relationship of how often a mechanic is used and how difficult it is to use effectively was kept to an inverse. We wanted the game to have high replayability so we purposed less used mechanics to generate more unpredictable and riskier gameplay with big payoffs so the players could feel progression in a very real manner from the get-go. For instance, jumping can be used very effectively to unlock your car from the predictable paths, and even surprise opponents by going over obstacles and shooting your spells while their trying to drift around those objects
It was then very clear that we did not want a realistic driving simulation, but more of an arcade feel to it. We drew up a benchmark that would help us situate our game and take an edge over competition, taking advantage over the current car combat market gap
Drifting and driving had to be immediate to grasp and do successfully, which meant Camera and Collision handling would be of supreme importance.
However, a driving game implies very specific expectations for the controls from players. Therefore, we decided on starting out with a realistic simulation of actual driving, so as to provide the player with an experience that is relatable at its core. After achieving a faithful simulation, I then began tailoring the physics until each mechanic was perceived and used as intended.
A Realistic Approach
The cars' basic movement is implemented using Unity’s built-in Wheel Colliders Physics. It moves by computing the force generated by the friction between the tires (simulated by the colliders) and the ground. To compute this force, there are several factors that are taken into consideration, of which the most remarkable are:
- Motor Torque, the rotation that the "motor" applies on the wheels, by whose friction with the ground the car moves
- Mass and Downforce, which dictate collision handling as well as influence adherence to the ground
- Steer Helper, a factor that redirects the car's momentum towards its forward-facing direction
- Traction Control, which adjusts the motor's applied torque to optimal slippage limit
- Center of Mass Offset, which when lowered makes the car less likely to flip into a roll
- The Wheel Friction Values
Wheel Friction values can be altered to change the car’s adherence to the floor. We can change the values on forward friction of the tire, and the sideways friction. Friction to force output is optimal at the Extremum, because that is the point when the rubber stretches enough to push the car but not enough to slip
Breaking the realism
After having achieved a faithful physics simulation to which players can relate, I began gamifying the controls:
- We clamp the steering angle while the player is not drifting so they cannot go into a drift accidentally
And while drifting:
- We apply a forward-facing force on the back wheels while drifting that is dependent on the acceleration input (diagram below)
- We apply a Torque directly on the car (bypassing the wheel collider physics) that is dependent on the steering input
- We apply an Impulse Torque for the first steering input, so the car snaps its rotation to a slight sideways trajectory
- We apply a counter-steer amplification factor to the steering Torque, controlling how easy or difficult it is to counter-steer a drift
By applying a forward-facing force on the back wheels that is dependent on throttle, the acceleration input results in a boost to speed as well as a torque on the car due to the front wheel’s Sideways Friction force counteracting the force’s perpendicular contribution.
What is drifting
There are a few constraints the drifting had to oblige to, according to our Design pillars. Remember, stopping is dying, and difficulty is tactical
I want to:
- Quickly be able to drift slightly without changing my trajectory drastically
- Quickly change the curvature of my drift (countersteer my way into a drift going the opposite side)
- Be able to cut corners without crashing into the geometry
- Be in control of my own trajectory (somewhat, I don't want to feel in complete control or drifting loses its power. The car is a beast I have to tame)
- Be in control of my direction when I exit the drift
I don't want to:
- Accidentally go into a drift
- Spin out in tight circles
- Lose too much speed
Ergo, I settled on a tri-state structure for the Drift Controller:
- Not Drifting, has the player simply driving
- Pre-Drifting greatly lowers the friction on the tires, allowing the player to quickly snap to a sideways position in order to cut corners
- Successfully Drifting