Interstellar Racing League
Basic Info –
-
Engine - Unreal Engine 4
-
Development Time - 8 weeks (80 man hours)
-
Team Size - 56 People
-
Genre - Local Multiplayer Racing
-
Design Goals - Create a fun, short term racing game experience that can be played at 60 fps with local multiplayer
Game Overview -
In Interstellar Racing League players can choose from one of 4 unique racers battling it out for the belt in the IRL Championship; the fastest and most dangerous race in the galaxy. Players must use boost pads, shields, and torque pads to gain an edge against their opponents and take first place, and eventually, the belt.
The Cast -
Players can choose from one of four characters, each fitting into their own archetype:
-
The Skylark, driven by Wilson
-
Wilson is characterized by being overall good, but not the best in any stat. He can handle most turns at a good speed, and can move along at a relatively solid clip. He's intended to be unpunishing for players who don't know much about IRL or racing games yet.
-
-
Ursa Major, driven by Lumina
-
Lumina drives a faster, heavier vehicle, but she struggles with cornering. Her acceleration is pretty good, but players will find that she doesn't quite have the highest speed. Although the extra control she provides can be very valuable in the IRL.
-
-
Stellene, driven by Amadea
-
Amadea can shoot off like a rocket. She accelerates fast, and drives even faster, but her handling leaves something to be desired. She's been known to hit the walls on corners more than the other racers, but hey, losing a little bit of speed doesn't matter if you can get it back right?
-
-
Junker, driven by Bertha
-
Bertha is the fastest, and the heaviest racer. She doesn't accelerate very well, and she can't steer very well (it's difficult to reach the wheel with those tiny arms) but she just pushes everyone out of her way and barrels through them at speeds the other racers just can't match.
-
Personal Responsibilities –
My title on the project was Game Designer. I was part of a small team of 3 Game Designers. Collectively, we were responsible for communicating the vision of the game to the team and keeping them on track towards the vision of the game. I was also personally very involved in the balancing of the vehicles and the systems within the game to make the experience fun for players and ensure that each vehicle stayed within the game’s overall vision while being iterated on.
It was my responsibility to take the feedback we received from playtesting sessions and first decide if it was actionable and useful, and then distribute it out to the respective teams as well as go over the feedback with teams to ensure we all stayed on the same page. I was also largely responsible for keeping our GDD up to date and continually creating documentation to keep our team members updated and ensuring that everyone had the information they needed to complete their tasks.
Some examples of the documentation I created and kept current with our design are available in a google drive. The link is provided at the bottom of the page.
Postmortems are also available there if you are interested in seeing them.
All this documentation was either written by me or together with the other Game Designers. We had to do so very early as were brought onto a project that had already been prototyped but we were not a part of its prototyping process. The project was hard locked to take place over the course of 3 months, so this documentation needed to be written and sent out to them over the span of a few days to ensure that everyone had something to work on and everyone was working on the same overall vision. For us, this meant things like determining the theme of the game or determining what the mechanics of the game would be as the original prototype had little to no documentation and was working off of one pillar: Customization through Gameplay. The original prototype had also not clearly defined this idea so part of our job early was to make a clear definition of this through gameplay and through visual aesthetic.
Data Tables –
The above image is an example of the data tables we set up to drive our game design. This data table was set up for the camera controls on every vehicle. As part of our process we originally did not plan for this level of control. We originally just had one camera type setup and used on every vehicle. However, a single camera became a serious issue for our game. We wanted to focus on multi axis tracks in our game, which means a lot of loops and curves. These loops and curves were preventing players from seeing what was coming in front of them, and at a high speed being able to see 4 or 5 seconds ahead is critical. The original camera caused players to hate playing our game because they couldn't see anything and felt like they were being unjustly punished.
The table was set up so that we could control the camera in whatever way was necessary to improve the player's experience. This ended up being a far greater task than we originally had planned. I had to organize between every discipline, and even most of the teams to get this up and running the way we needed, and then also ensure that each teams needs were met with it. First, I worked with some programmers to expose the variables to us so we could change them as needed. Which got us to step one, of having it working. After that each team wanted to get involved the camera process to ensure that their work was being represented the way it needed to be. Our track design team needed to ensure that player's weren't being given too much information, and shortcuts were still hidden and available paths were still clearly visible. The art teams wanted to make sure that everything was still being viewed from the intended angle, and looked good from that angle.
This ballooned out into a far larger cross discipline undertaking than we had first anticipated. Part of my responsibilities on this table were to ensure that each team's needs were heard and met accordingly. I had to orchestrate between multiple disciplines to ensure everyone got what they needed.
Car Stats and Balancing –
This another one of the data tables used to drive our game's design. Each car's individual stats were placed here, with the general stats for all vehicles being placed into a separate table. Both the individual table and universal table are here. (The red box on the universal table is surrounding the relevant stats. There were old camera values placed there that just ended up not being removed when we switched over to the individual camera system.)
I worked with our physics and car programmers to expose as much of the data relating to our vehicles as possible, so we had as many things as possible to tweak for our game's feel. We wanted to put a big emphasis on our game's feel over balance. As long as our cars could feel good to drive, players could enjoy our game. Which is why some of the exposed variables relate to things like hover height on the cars.
We set up our data tables to work so that we could define value ranges for the vehicles to work from, and then define how 'effective' we wanted a given vehicle to be at that stat (the individual vehicle stats are based out of 1000). So for example, Bertha's top speed is 900, corresponding to 90% of the universal vehicle range. This allowed us to shift a vehicle's feel not only by changing the singular vehicle itself, but also by changing all vehicles.
We spread out all the vehicle stats enough to make them feel unique but also to keep each vehicle in a range of 'usefulness'. Through testing we identified that anything less than about 180 handling was effectively unplayable for players, and through that same testing we discovered that even very small changes in handling were noticeable for players. We tested that phenomenon more and found that layers didn't really think of handling as a unique stat because they only ever really interacted with handling at speed (meaning while at or close to their max speed) so we tuned all the vehicles handling around that idea.
Our process for tuning and designing these vehicles used a lot of design by halves. We would usually pump something up extremely high, or set something extremely low to begin with and then reduce the value by about half to tune it to a level that felt good. This new value was set as a starting point for our balancing and playtesting.
These stats, similarly to the camera stats changed a lot throughout the production process. After receiving playtest feedback from players, and watching some live playtesters I identified a need for the ability to negatively affect players for hitting walls. A strategy playtesters found was to simply ignore walls and hold the accelerator down. Since at the time walls did not affect a player's speed this caused anyone playing as Bertha to win outright, every time. I worked with our physics team to add in this feature towards the end of development as quickly as possible. Which unfortunately introduced a new problem: walls weren't easy to avoid and were now too punishing. Players were having trouble getting off walls after hitting them. So I had to work with our programmers to add in a new feature to bounce players off of them (WallCollision_AngularImpulseDamping). These are just a few examples of what our process was like throughout development with these tables.