Position
Level Designer – SMU Guildhall
Development Time
12 Weeks – 150 Hours Per Person
Team size
5 ~ 2 Level Designers
Technology
Unity 2018
synopsis
C.H.I.P. is a 2D twitch platformer focused on guiding an outdated robot through dangerous obstacles using his unique ability slotting interface. Consists of 5 levels challenging the player’s dexterity to quickly slot in and out C.H.I.P’s skills to avoid spikes and saws
Trailer
roles and responsibilities
- Accountable for the overall vision of the game
- Responsible for designing the slotting system
- Designed 2 of the 5 levels within the game.
- Took the tutorial level from conception to completion.
- Designed the 4th level focused on more advanced movement options.
- Responsible for implementing the animations for the character
- Responsible for designing and implementing start menu and level select layout
marketing screenshots
Design goals
Design goal: teaching players a complex mechanic non-verbally
- Unlike in most platformers, in C.H.I.P. players must slot in two single jumps that when activated will play in sequence.
- Ability buttons can be tapped when in their active state
- After tapping an ability, it is added to the queue
- Tap the play button to activate the queue
- Tap the clear button to clear out the queue
- Teaching players to slot in two single jumps into their queue before activating the sequence at the right time was a major challenge when designing this level.
- Conveying this system involved slowly molding the player’s understanding of the core mechanic. At the start of the level players slot in a single jump into their queue to begin progressing.
- When communicating a new rule of the system players are given plenty of down time between required actions keeping difficulty low.
- The end of level one hints at the more frantic pace future levels will operate at. Here for the first time players are required to switch between slotting in single and double jumps to survive a deadly gauntlet of saws.
- The compact layout of level one guaranteed players understand the slotting mechanic of our game. Players who beat this level had all of the tools they needed to beat the game proving the design a success.
design goal: communicating that ability order matters
- Level 4 teaches about the jump dash action sequence.
- The challenge when designing this level was communicating to players that the arrangement of jump and dash in their sequence have different effects. While dash-jumping lets players slide under saws destroying boxes before launching across large gaps, jump-dashing lets players break through walls and floors of boxes.
- Players start this level trapped in a small area by a wall of boxes. The cube of metal to the right of the player’s starting position prevents them from merely dashing through the wall as a dash only destroys wooden boxes.
- By this point players already understand how their dash can destroy boxes and this initial arrangement of objects communicates a new strategy being introduced of jumping before dashing
- After raising the stakes of completing the jump dash technique with increased numbers of saws and tighter timing players hit another wall. Here the boxes are arranged in a backwards L shape.
- Player’s have quickly been taught how to overcome walls of boxes with a dash but using this move here they will also break through the floor of boxes revealing another way to consider the power of the jump dash.
- A majority of playtesters felt that level 4 was the most satisfying level within the game. The mechanics in the level seamlessly build on players’ understanding of ability slotting and the box obstacle to create a fun new interaction within the world.
Post Mortem
what went well
- Succeeded in solving complex UX and design problems instead of pivoting away from them
- Maintained consistent vision for my team
- Taught complex mechanics through level layout rather than text
- Designed levels with a satisfying difficulty progression inducing feelings of competence from players
what went wrong
- Jumped swim lanes, ignoring pipelines to solve problems my self
- Sometimes put my work in front of my teammates causing miscommunication
- Didn’t focus enough of my time on getting my teammates up to speed on tools
- Underestimated the importance of documentation, preferring to produce new work over documenting existing work
- Designed a core that was fun when understood but difficult to learn by designing the game for myself rather than an audience
what I learned
- Document things as they are come up to save time later
- To think more like a new player when designing the functionality of a feature
- Being honest about our own limitations when taking on tasks
Austin Merritt 