Snowpainters
Genre:
Engine:
Time Span:
Role:
Team Size:
Project Link:
Highlights
Point Person for Track 1: North Pole
Conducted Systems Balance Testing Sessions
Commentary Video
Contents
​
​
​​​​​​
​​​​​
​​​
​​
Quick Summary
My responsibilities encompassed all aspects of Track 1: North Pole's gameplay. As the first of three race tracks, it introduced our motifs of track design: curves, splits, jumps, verticality, conveyance signals, and more. Our strike team of four designers documented and implemented the track. From Alpha onwards, I was solely responsible for bringing the gameplay aspects of the track to a shippable quality.
​
Our core mechanic gave our project a unique set of gameplay considerations. The placement of paint puddles needed balance alongside item drops and pickups that affected our core loop. We examined emergent strategies as we simulated races, and adjusted our level design to optimize color variation. The paint mechanic also affected other systems balance considerations, such as the penguin classes. I conducted sessions to analyze and balance our unique gameplay, and provided suggestions to improve it.
Development Timeline
Weeks 1-2
Weeks 3-4
Weeks 4-5
Weeks 6-7
Weeks 8-9
Week 10
Proof of Concept: Technology
Proof of Concept: Gameplay
First Playable
Alpha Milestone
Beta Milestone
Release to Manufacture
Drew paper prototypes for all three levels.
Refined and iterated maps for design constraints.
Designed and implemented Track 1's first pass in Unreal.
Track 1 became playable for testing and iteration.
Worked toward Alpha version ahead of other tracks.
Put elements put in place - AI splines, minimap, etc.
Worked toward Beta version ahead of other tracks.
Refined track spline, items, paint puddles until confident.
Balanced systems for the entire game.
Made Track 1 airtight and bug free according to QA tests.
Made sure the track was of shippable quality.
QA tested the entire game.
Track Design
Paper Prototyping
We rapidly drew track designs on paper before before starting our real level plans.
This helped us think through our track vocabulary, constraints, and how to integrate the pieces.
Our paper prototypes helped us think through the problems of assembling a track quickly. Our design leads gave us more constraints and considerations for each sequential version of our paper prototypes. The idea was to think through design challenges and get the wheels turning for our actual maps. Our maps eventually demonstrated our ability to think through key track design problems:
​
-
How to build a well-paced sequence of events in a repeatable track.
-
How the paint trails would affect the critical paths through the level.
-
How to incorporate the artistic theme of each level (north pole, ice caves, and glacier).
-
How to deal with technical problems like hiding parts of the track to avoid rendering issues.
-
What design features we personally wished to include in a map.
​
Each version of our maps was given just a few minutes to complete. I was chosen for the Track 1 strike team because of what I was able to accomplish on paper in the condensed time frame.
​
Inspiration from Topology
A sample platter of knots I had constructed from fabric inspired our design team.
Postmortem
What Went Well
-
My track kept its head start through smart planning and diligent work. So I was able to implement robust solutions to problems when other tracks were looking to band aid fixes late in development.
-
Our large team of 40 developers had strong communication channels. I would often liaison between the designers and software developers.
-
Our team members kept each other up to date in daily meetings and supported each other through blockers. We had a clear sense of the other designers' responsibilities and daily progress.
-
Before starting development, we had flash hacks to promote teamwork and get familiar with the tools and technologies. We found the fun and carried successful features from the flash hacks into the main project.
What Went Wrong
-
We had nobody dedicated to systems design throughout the process, so the late-stream balance adjustments had to forgo perfection and find compromises. We should have allocated more effort throughout the process.
-
We lost two of our designers midway through the process. With both of our landscape specialists gone, our design team had to fill in and pick up where they left off, which slowed progress.
What Was Learned
-
Communication is key on a large team, and perhaps the single biggest factor in our success. Especially in interdisciplinary collaboration, I learned not to let the default communication pipeline limit my willingness to speak with the software developers often.
-
Organizational standards for things like level composition and directory structure speed up the entire process, especially when developers onboard to new parts of the project.
-
QA testing and polish took much longer than expected. We were tempted to add more levels to the game midway through, which we would clearly not have had time to refine in hindsight.