Haberdashers
Game Summary:
​
HaberDashers is a console-style arcade (kart) racer for the PC in which players control miniature humanoid inhabitants of an everyday home, racing past outsized household items and through rooms as they compete against human and AI opponents with both driving skills and item pick-ups.
​
​
Key Features:
​
-
Single-player and couch multiplayer with split screens for up to 4 players
-
Remote multiplayer using Steam's Remote Play Together feature
-
8 racers in each race (humans as well as AI)
-
Modular car design featuring at least 4 car bodies, 4 car wheel types, and various paint jobs and decals
-
4 original characters that fit in the world
-
3-lap races lasting roughly 5 minutes each
-
Surface types with varying drag
-
Players have the ability to use a drifting mechanic to execute tighter turns
-
One-time use weapons and abilities in the form of on-track pickups
Development Methodology:
​
Haberdashers was developed using an Agile development model with Scrum. The team planned milestones for the development of the game and implemented features according to milestone requirements.
Throughout development, the Game Design Document was updated and served as a living document consisting of feature details and projected outcomes from the development team.
​
What did I Do?
​
-
I was part of the team that was in charge of creating the architecture of the game from which data can be easily transferred to other systems, levels and blueprints.
-
Created the Game Mode and Game Instance Blueprints which is core of blueprint of our game from which data about various systems can be accessed and modified.
-
Created blueprints for loading screen, pause menu, Grand pix system, Point system and various other helper blueprints for integrating UI system, Item pick up system, and Position tracking system with the game.
-
Did Unit testing and QA testing and reported, solved bugs and helped other colleagues in solving them.
Some of the Blueprints I wrote:
Description:
​
Whenever the kart loses coins, we had to display a -3 image on the kart, so i wrote a simple timeline to animate this display it for a few seconds and then disable the display
Description:
​
This blueprint checks for race completion and when all players have finished the race the points are updated for each kart based on the current game mode which can be accessed by the UI components to display the race complete screen.
Description:
​
Loads the relevant level whenever the user selects the level from the UI menu
Sets a random loading tip on the loading screen
Description:
​
Simple pause functionality which pauses the game and displays the pause menu UI screen and reduces the background music of the game if the game is paused
Description:
​
Dynamically set the size of the text based on the size of the text
Description:
​
Sets the appropriate information about the type of race for the game instance based on what the user has selected
Description:
​
Calculate and set the points for each kart in the race based on the current active race mode
Some screenshots Of Game:
PostMortem :
​
-
What went well
-
I felt I did very well on my discipline and had clear communication from the start about the tasks each of us are responsible for and made sure the blueprints I wrote is easy to understand and maintained a proper pipeline which made the debugging and testing process easier.
-
I felt I did a pretty good job at integrating my blueprints and reviewing blueprints made by others and made sure all the blueprints had the intended behavior and didn’t hinder our development progress.
-
I felt I had a good insight about the future sprints and wrote blueprints accordingly.
-
Although I had some communication issues early on, through the course of future sprints I felt that I improved my communication significantly and did not create any blockers for my team.
-
I felt that I was very flexible at implementing certain features and had a lot of alternative ideas to do the same thing differently.
-
-
What went wrong​
-
I had a lot of communication issues early on, was shy and was most of the time hesitant to talk about ideas and any issues the team had. Many problems that I could have solved weren’t even told to me because of my communication issues.
-
I felt that my participation towards documentation was poor and focused most of my time on maintaining the blueprints which made it hard for other disciplines to understand my work.
-
-
What I learned
-
This was a very good experience working with a large team and get the game to a shippable quality .
-
Working with version control is much more complicated than I imagined, and we had a lot of issues, dealing with these issues and fixing them was a great leaning experience.
-
Working on data integration was a great experience as the architecture we implemented by various other departments and disciplines of our team.
-
I feel I am a lot better at planning and communicating which was the biggest positive learning experience for me.
-
​​​