My Role
My role in the game was as a Technical Designer. My job was to script and maintain the kart racer powerups, most notably the "Invincibility" and "Web Throw" powerups. Additionally, I also designed some UI elements and integrated them, helped discover and document optimization issues, and logged and resolved bugs.
Role: Technical Designer
Engine: Unreal Engine 4
Team Size: 60 Developers
Platform: PC
Development Time: 4 Months
Game Summary
High Concept: Hex Rally Racers is a magical multiplayer arcade racing game for PC. Race as witches on flying brooms through spellbinding worlds to become the fastest witch in the land. Play with up to three friends at once in four-player split-screen, or race against up to seven AI racers for non-stop spell-slinging action! During the race, players can pick up ingredients on the track to craft unique spells that can be used as traps, boosts, or projectiles to leave other witches in the dust.
Two examples of script used for Web Throw
Example of how invulnerability can be used defensively.
Example of how players can use Confusion Hex to throw off your opponents
Gif of effect that happens when a player lands on Web Throw
Example of how invulnerability can be used defensively.
GIFs of powerups being used in final product
Pickup Blueprinting
My role throughout the development of the game was iterating on gameplay mechanics such as a web bomb, invincibility, and confusion hex. Each of these required a different set of scripting to be handled which resulted in numerous iteration cycles to get them working nicely in the game.
As time progressed I also needed to shift to a role of communication as other team members needed to be informed of specific requirements to be met. For instance, the web throw spell needed to be generating overlap events for the script to notice it had landed on the ground. To ensure the spell worked across each level I would need to check anytime there were mesh changes and communicate to the level design team whenever I found problems.
UI Design and Implementation
Around the middle of development the UI team was needing assistance due to a large workload and a lack of manpower, so I shifted gears for a bit to assist them.
During this time I designed and implemented the Grand Prix selection screen. I was later then asked to continue assisting with UI tasks after I'd learned how to handle the Unreal tools for UI creation. This was how I became involved with creating the navigation for controller and PC controls for the main menu and the tutorial menu. These tasks were undertaken alongside my other tasks of continuing to iterate on my blueprints based on lead and stakeholder feedback.
Initial UI Design mockups for Grand Prix and Tutorial navigation
In-Engine Examples
Images portray some examples I discovered of assets or portions of the level which showed examples of overdraw, shader complexity, and texture complexity. Each of these issues caused significant drops in track optimization and were fixed shortly after.
Track Optimization
Eventually as development went on our team discovered there were some pretty significant dips in performance throughout the game that was disrupting our target of a stable 60 fps. I worked alongside designers and programmers to identify and catalogue instances of significant issue.
During this time I also drew up documentation to share with the design and art teams about specifics to be avoided to ensure that after the issues had all been found and resolved there would not be repeats. Throughout the process I learned a lot about level optimization and the importance of sightlines and conservative asset creation.
Postmortem
What Went Well
What Went Wrong
Even Better If (EBI)
Strong Art Direction
The art direction from the start through launch was consistent and given time for refinement leading to a good looking game.
Steam Launch
The game launched on Steam and has a "Very Positive" review rating as of this writing.
Technology working early
From the end of POCT most essential systems were working and had time to iterate over the remainder of development
Cross-discipline team composition
Teams were composed of multiple members of each discipline keeping people from isolating themselves in discipline.
No place for internal feedback
Throughout development there was no place where developer feedback could be tabulated for consideration
EBIs not implemented
Retro feedback solutions would never go further than the retro they were brought up in.
Pipeline never established
Pipelines were partially constructed but never reinforced and were eventually each discipline created their own pseudo-pipelines
Sprint Plan was given not discussed
Leads created tasks for each discipline and then asked devs to not create any additional tasks, not allowing for flexibility in fulfilling conditions of satisfaction
Create space for feedback
A dedicated period of time where feedback from the team working on the game on potential improvements would help empower devs
Team EBIs given power
Instituting EBIs given by the team would help each member of the team feel like they have a level of control over their team experience
Reinforce and empower pipeline
Ensure pipelines are established and communicated early and often to prevent confusion when developing assets.
More individual power to plan
Providing epics and allowing individuals to plan out their tasks for a sprint so as to allow for additional work if its required.