Hex Rally Racers
// Click here to download on Steam!
Project Summary
Role: Level Designer, Mechanics and Quality Assurance Team
Genre: 3D Kart Racer
Editor: Unreal 4
Platform: PC
Process: Iteration, Scrum, Prototyping, Testing, Strike Teams
Tools: Jira, Monday, Slack, Zoom, Perforce, Miro
Development Time: 3.5 months (15hr/week)
The Game:
"Hex Rally Racers is a 3D arcade racing game for PC where players race on flying brooms through wild twisting and turning tracks, combining ingredients to craft potions to be used against other players. Race through six stunning tracks in a chaotic race against seven other witches, or against three friends at the same time in multiplayer split-screen!"
Contribution Summary
Level Design Contributions
- Researched and developed proxy materials for proxy assets
-
Designed and implemented functional proxy pickups with blueprints
- Playtested levels, UI screens, and UX, and reported bugs to Jira
- Created umaps and sublevels for teammates
- Co-Implemented and modified spline tracks in "Shroom Shire" track
- Placed art props and blueprint assets into multiple tracks
- Modified terrain in "Shroom Shire" track
- Collaborated with software developers to address performance concerns
- Implemented blocking volumes into several tracks to create robust gameplay
Special Assignments:
-
Served on a strike team of 5 to research other games and game elements to assist in the game design process
-
Served on a strike team of 4 to research media capture and camera controls
Main Contribution Areas
Prototyping
Mechanics & Game
Features & Tools
Track Design, Spline
Track Implementation, & Terrain Modification
Bulletproofing
Levels
Prototyping Mechanics, Features, & Tools
During the first half of the project, I was placed on a team responsible for researching and prototyping game mechanics such as projectiles, traps, ramps, etc. I spent the most time working the web throw mechanic and ramps.
For the web throw trap (and ground goo trap), I created a static mesh in a bubbly shape because this was originally going to only be one spilled potion that operated as a road hazard to slow the enemy down. I created animated proxy materials for both the web goo and the web versions to resemble the type of trap it was for early prototype testing. I created blueprint assets for each trap and scripted the initial programming. I included nodes for audio SFX and VFX and I gave each element proxy audio and VFX for feedback testing.
Stage 1: Projectile throw to set trap
Stage 1: Projectile throw to set trap
Ground Goo Proxy mesh and material
Stage 1: Projectile throw to set trap
// This code describes what should happen when the thrown web hits the ground
// This code shows how the proxy ground material was created
// This code creates the effects the ground trap executes when spawned and overlapped
I initially placed two ramps here that contoured with the terrain, but these were later replaced by a newer larger ramp with new physics
Doubling 2 smaller ramps instead of grouping four together in a line. These were later eliminated due to collision issues and narrow pathway concerns.
Ramps were changed during multiple phases of the project. I prototyped a few different types of ramps in Unreal's blueprint system and added appropriate meshes onto them for each type of track that we had; some had wooden elements while others had stone elements.
It was critical that we exposed the variables for the ramps so that designers could tweak the values based on their track designs. In the end, the base physics changed several times over the course of the project from the software development side. In each case, designers would alter these values (velocity, speed, etc.). I was responsible for swapping out ramps as they changed, and adjusting their values in the "Shroom Shire" track.
Additionally, I helped research and prototype other game features and tools such as:
-
Tunnel systems that prevented the player from descending to the terrain below the sky track jumps
-
Terrain-based tunnels in an effort to minimize the burden on our art teams
-
Cinematic rails that could be used to play fly throughs before the player begins each map
-
Because I had prior experience using spline systems for our tracks on Snowpainters, I assisted the leads in order to get them acclimated to the spline tool, what it could be used for, and the pros and cons of using splines for our project.
Using a proxy cylinder I created, a semi-translucent material that I modified, and a spline, I was able to create a spline bridge over the track below. The goal was to make the player feel like they were jumping over a gap, while still being confined to a tunnel sized area.
I created this proxy mesh to be used in a spline with a semi translucent material
This test failed, but we learned how terrain works upside down.
Using a proxy cylinder I created, a semi-translucent material that I modified, and a spline, I was able to create a spline bridge over the track below. The goal was to make the player feel like they were jumping over a gap, while still being confined to a tunnel sized area.
Map Design and Implementation
In the early stages of the project, I assisted in the design of the "Shroom Shire" map. We planned our design on a whiteboard and then whiteboxed a track in inside of Unreal.
I placed some of the spline track and modified several ramps while my team mates placed other parts of the track and sculpted the terrain. I placed the initial trees and mushrooms in the scene to differentiate spaces and begin to block sightlines. I was also responsible for placing the initial art cards surrounding the level.
"Shroom Shire"
whiteboxing "Shroom Shire"
"Shroom Shire"
Seamless fence pieces within the spline and outside of the spline.
Hot pink are spline meshes. Blue are hand placed meshes (and other meshes). Light pink are blocking volumes to eliminate weird collision for the player.
Seamless fence pieces within the spline and outside of the spline.
Fences were 95% part of a spline system; I initially suggested using this spline system while working with the Snowpainters team, and suggested it again on this project; I shared a complete wiki that I built for the Snowpainters team with the Hex Rally Racers team, and gave them the same risk analysis sheet I created for the former team. In some cases where the fences did not look correct in size, shape, or angle with the spline tool (which sometimes can happen with rails, banking curves, and tighter corners), I removed the mesh from the spline segment and hand placed and resized a fence mesh in its place that looked more natural.
Once the landscape was in a semi-final form, I went around the entire "Shroom Shire" map and made sure that the bottom of every fence was perfectly lying on the terrain in a natural way. Sometimes this involved lowering a spline point and other times this involved resculpting tiny parts of the terrain -- a task I became skilled at while working on the track for Snowpainters.
Later in the project, I assisted the team by modifying landscape to look more natural while solving concerns related to performance and gating the player.
-
Near the final stretch of the track, the landscape was entirely flat; I modified the pathway to create a more realistic landscape for outdoor terrain while also sinking the track into the ground slightly; these changes also made the gameplay more interesting.
-
At the start of the map, we faced two problems in the alpha version of our game. First, the player could fly off the track and into later parts of the track. Secondly, the player could see out across the entire map which tanked performance. I created a raised edge on the terrain which blocked the player's sightlines and kept the player to the right of the track during this area. If the player jumped over the raised edge on accident, a kill volume respawned them into the track via a checkpoint system we implemented.
Modified landscape for realism and gameplay
flat and samey landscape before modification
raised edge to keep the player in the playable space
Modified landscape for realism and gameplay
Bulletproofing Levels
The player could easily get trapped between the mushroom and rock.
Blocking volumes were added in a natural manner; we made sure that the player could easily navigate around the obstacle to continue racing.
Blocking volumes (light pink) were added in the mountain sides to prevent the player from climbing up the mountain sides. These were implemented where rails were not implemented. For a more natural feel, we moved them into the mountain slightly so that the player could go up the edges a little but soon it would feel too "steep" of a slope and they could not ascend higher; this felt natural to our playtesters.
The player could easily get trapped between the mushroom and rock.
In some cases, the player could ramp onto a mountain top or exploit a pickup to get on top of mountains or climb up mountains. In some parts of the map, we implemented kill volumes, which respawned the player on the track via checkpoints.
I noted floating objects like this grass foliage.
Sometimes art assets would have visual bugs that would need to be reported to Jira.
In some cases, the player could ramp onto a mountain top or exploit a pickup to get on top of mountains or climb up mountains. In some parts of the map, we implemented kill volumes, which respawned the player on the track via checkpoints.
In the last stretch of production, I was asked to be on the quality assurance team. It was a good role for me given my experience as Lead QA on The Mysterious Misadventures of Molly and Mordecai team. Since I had spent most of my map implementation time in "Shroom Shire," I was fairly confident about that map's quality (at least as a starting point) and decided to focus most of my time on other maps; regardless, by the end of the project, I had checked all 6 maps thoroughly for bugs and feedback.
Simply put, I have a knack for catching the smallest of bugs. I can break out of maps, will notice small visual bugs, and I seem to always find invisible collision or places to get the character stuck; I always give the UI adequate attention as well.
This attention to detail has made me a great quality assurance tester. In many cases, I was able to identify and fix many of these issues; in particular, I would often add or modify blocking volumes or kill volumes. Sometimes I would rotate or nudge floating assets into the terrain or pull the terrain up slightly to meet the assets. Sometimes, that involved repainting with the foliage tool. In rarer cases, I'd add collision to an asset or report the bug to Jira for the art, programming, or track implementation teams to address. In all of my reports, I always tried to include annotated images or video clips.
On several occasions, I would watch others playtest the game, and I'd create Jira reports as I saw things or I'd take notes and put those reports in after their playtest. On other occasions, I'd playtest the game and call out issues as I was playing and have several other folks in the room report the bugs in Jira. I worked closely with one of the producers in order to have an effective quality assurance team with results.
What I Learned
When there are a lot of people on a team, it is not always easy to see where all team members can be most effective at all times. This project was a chance for me to dive into tasks that are a little outside of my immediate comfort zone. In the process, I was able to learn some new skills while also benefitting the project in the long run. I was also able to bring in prior quality assurance experience and really help the team make the game more robust. Finally, I was able to exemplify what it means to be a quality team member by following the leads' requests, letting leads lead their team, and also empower or uplift others to be the best leaders and developers they could be.
