My role: Blueprint Programmer
Team Size: 56
Engine: Unreal Engine 4
Language: UE4 Blueprint
Development time: 4 months, 3 hours a day
HaberDashers is an arcade kart racing game for 1-4 players inspired by The Borrowers by Mary Norton and Studio Ghibli’s The Secret World of Arrietty. The game takes place in a house much like your own – except that in this house, tiny people live in the walls and come out to play whenever the humans have gone. The theme was selected for its ability to highlight each of the student disciplines of programming, art assets, and track/level design.
While the project centered around the creation of an arcade kart racer, providing individuals with experience working in Unreal Engine 4.23 on a racing game, its ultimate goal was to provide an environment in which team members could learn how to cooperate and coordinate with a team of 50+ people. Our move to virtual halfway through the semester also created an opportunity to strengthen communication skills, task planning, and remote working skills.
In the beginning, I was in the kart physics team, together with other three programmers. Our job was to research different approaches to create a kart that feels good. We focus on three approaches: pure UE4 physics, pure custom physics, and a hybrid of both. We finally pick hybrid physics. We use UE4 physics to accelerate and rotate, while we use custom physics to handle special cases including kart orientation in mid-air.
After the kart is basically finished, I joined the backpack team, which is responsible for the game system, performance, camera, and some small features. The backpack team also helps other teams to debug when necessary. I worked on many different jobs in the team: performance, camera effect, lap count, time count, victory screen, help AI team debugging.
In the final stage of the development, I worked as a quality assurance and debugger. Tried to find bugs and fix bugs that I can fix.
In summary, I learned about many different areas of this project during the development, and this experience was really helpful for a gameplay programmer.
When I was in the kart team I implemented part of the physics, the drifting, and a simple position prediction function required by AI team.
Here is how the kart takes input. We first make all the input into variables and use these variables to apply velocity change to kart. That way we can keep physics calculation inside a component, so we can have two members working on kart and physics separately at the same time.
Here is the drifting of the kart. The prototype of drifting was completed early and was simple. But as more detailed requirements are made for drifting, it became much more complicated: Drifting should stop when hitting something; when drifting starts and kart is turning left, it should stay turning left before drifting stops. At end of drifting, there should be a boost. I had to pay much effort to finally make sure the drifting happens, stops, and behaves the way we want it.
This is a simple prediction function required by the AI team to predict the kart location after a certain amount of time. To simulate acceleration, I run a for loop 20 times and apply velocity change in each loop to make the position prediction.
When I was in the backpack team, I kept an eye on performance and mostly focusing on kart scoring including calculating time cost and ranking. I also implemented functions for resolution setting used in-game settings.
This is the session frontend built in UE4 that I used to monitor which functions took too much time to execute. Locating such functions and report to the team responsible for this was part of my job. Luckily, we kept the performance under control most of the time.
This is a function that calculates the finish time of each player in this level, increment the total time of each player. This function is called when all the human player finishes the game, so it also makes fake time for all the AI players based on their current position. In the Single Race, players are ranked by their completion time.
In the Grand Prix mode, players race for a few rounds and are ranked by their total points. Here is the function to rank players by their points.
This is a function to set game resolution. You can see I actually tried two different approaches and the unused command approach is still in place just in case.
Team member communication went well even we have to go virtual in the middle of development.
Inter-team communication was performed through producers.
The performance was kept pretty nice most of the time.
Most of the tasks were delivered in time.
Programmers get used to blueprint very fast while most of us did not have experience with it.
Leads are busy, hard to reach sometimes.
Tasks distribution was not clear enough.
Progress was a little out of control in the final stage.
Everyone assigns the tasks to themselves in time.
Leads are easier to access.
QA pipeline should be more clear.