Interstellar Racing League
Game Description:
Interstellar Racing League is a high-speed, 4 player racing experience. Players are racing along gravity-defying tracks through alien planets to compete for the title of the Galaxy’s Best Racer.
Development Specification:
- Role: Gameplay/Physics Programmer
- Engine: Unreal Engine 4.17.2
- Development Time: 2.5 Months
- Team Size: 56
- Number of Programmers: 15
Responsibilities
- Created a polished hovercraft physics model that enables a racer to move through multi-axis levels.
- Built a vehicle architecture that enabled the creation of independent modularized components. This enabled fast and easy iteration.
- Implemented a camera system that offers a good perspective while at the same time ensuring that it doesn’t hinder the feel of the game.
- Ensured that collisions with other track objects are working as you would expect when you’re racing high speed.
- Stabilized the hovering of the car and make the bumps feel natural to the vehicle.
- Implemented a re-orientation feature that helped player’s reorient the vehicle with a time penalty if they were knocked into facing the wrong way.
Vehicle Architecture
Collision System
My team was tasked with handling collision responses and dispatching appropriate events based on what the vehicles collided with. We successfully created a collision system that facilitated player-player collision and player-wall collision by generating the necessary collision responses and the appropriate events to notify other systems of the collision events.
- Set up event dispatchers for different collision types, for eg. Wall vs Vehicle.
- Set up impulse responses for player-wall and player-player collisions.
- Created the functionality for speed penalty on collision.
- Communicated the usage of event dispatchers to other teams.
Player-Player Collision
Player-Wall Collision
Note: The Unreal Engine Blueprints below are interactive. Please feel free to zoom into individual aspects by scrolling the mouse. Hold right mouse and pan to move around.
Camera System
I was tasked with developing a camera system that would ensure that the game’s perspective of speed was well conveyed. It also had to be easily tweakable so that the designers could iterate on the camera’s parameters effortlessly and fast.
- Built a camera that follows the player vehicle with lag depending on the speed of the car.
- Built a system that adjusts the pitch and FOV of the camera based on the speed to convey high speed to the player.
- Built a rotation lag into the camera that reveals more of the corners while turning.
- Data drove the camera parameters for designers to iterate fast.
Camera Rotation Lag
Camera FOV and Pitch
Note: The Unreal Engine Blueprints below are interactive. Please feel free to zoom into individual aspects by scrolling the mouse. Hold right mouse and pan to move around.
Reorientation
After a lot of playtesting sessions we noticed that players used the knock power up a lot to spin off other players. This spin off led to players facing the wrong direction most of the time. To make the power up more forgiving, I had to implement a Reorientation mechanic that would rotate the vehicle towards the track’s forward direction.
- Communicated with other programming teams to see how we define moving in the wrong direction.
- Figured out when reorientation is needed and fired the necessary event dispatchers to enable other teams like UI, convey information to the player.
- Figured out the math to solve the problem because the reorientation plane is different for every part of the track.
- Data drove the speed and threshold for reorientation to enable designers to tweak values.
Personal Postmortem
- Task estimations were close to the actual work time.
- I was able to adapt the sprint plans based on the requirement of the teams. Being on the physics team meant we were responsible for all the interactions between the track, environment, and the vehicle. This led to us getting a lot of feature requests over time to enhance the game feel. Not only were we efficient in achieving these requests but we were also able to have a bit of time each sprint to fix bugs when they arise.
- Initially, we relied too much on the pipelines and this led to a very stringent information flow. This led to a lot of assumptions, that would later just end up being bad.
- Feature requests were sometimes vague and miscommunicated to us. Later we find out that the request was a far smaller task than previously conveyed.
- Record common mistakes that were made to help other people solve these kinds of bugs faster. There were instances where a similar bug would arise from a collision setting was overlooked. I learned from experience that if we’d recorded this in some document and given a shout out, it would have saved a lot of time towards the end of the project.
- Constructive feedback goes a long way in helping a team improve and ultimately helps to achieve great team dynamics.
Team Postmortem
- Improved as Developers
- Learned new roles and skills. We understood how the leadership roles help in shaping a team and ensuring efficiency.
- We implemented an asset lock system in two stages: Hard Lock and Soft Lock. This proved to be vital to ensuring smooth integration days and ultimately good milestone deliverables and presentations.
- Having the game designers in close proximity and having them answer quick questions proved better and faster sometimes than plunging through mountains of data on the Game Design Document.
- Initially, we had strict swim lanes and this prevented us from having a two-way communication were it would have saved a lot of dev time.
- There were instances were some of the check-ins to Perforce weren’t tested well and this led to some breaks in the build and thus, slowing down everyone.
- Be more candid with fellow developers and just ask a question when in doubt. It’s better than spending a whole lot of time and then realizing it’s just too much or too less.
- To prevent some of the bugs when checking in content to version control, It is a good practice to first get the latest revision of the project and then testing it one more time before pushing it in.