top of page
Robellion Poster_edited.jpg

Robellion

Level Designer | 10-Week Period | 5-Person team

Robellion is an unpublished 2D side-scrolling shooter/platformer for Android tablets. I was one of two level designers on a 5-developer team that ran an Agile-Spiral development cycle with daily Scrums. I was primarily responsible for designing the game's introductory levels, selecting and implementing audio assets in Unity, and maintaining the group's production documentation (e.g., Assets database and request pipeline, schedules, Perforce file paths, and Burndown Charts).

Gameplay Trailer
 

Screenshots

Screenshot_20221121-101220_Robellion.jpg
Screenshot_20221121-101024_Robellion.jpg

Among my level design duties were...

Robellion Warhouse Level.png

Layout design for Levels 1 and 2 and game-wide audio design/implementation

Creating and maintaining the asset request pipeline

Robellion Pipeline.png
Robellion_Burndown_Charts._Trimmed.jpg

Calculating and upkeeping the team's burndown charts

Robellion Post-Mortem

What went well?

  • As a team, we followed the pipeline and launched our game with 80% internal satisfaction. Highest priority bugs were addressed and the target play styles were achieved. 

  • We successfully onboarded a new level designer after the proof of concept gameplay (POCG) milestone. The onboard process was efficient and the subsequent team culture well manufactured for the new personality. 

  • We were successful in collaborating across disciplines and leaning into each others;' strengths. When I had C# questions, I was quick to ask for assistance from the software developers. When the artist had design document questions, I was ready and willing to offer further explanation.

  • Over the 400-man hours of production, communication showed continued improvement. As the only native English speaker on the team, I saw personal growth in my ability to have clear technical discussions and design meetings. 

  • We responded well to feedback received in Kleenex playtesting from Vertical Slice through Open Access Beta, primarily iterating on player controls. 

  • We were quick to make cuts to address scope issues while finding and preserving the core fun of the game. 

What went wrong?

  • Prior to Beta, we had far too few playtesting hours to influence broad feedback for features beyond player control.

  • We broke the spirit of hitting a feature complete Alpha. At the time were missing assets, such as an opening cinematic, that the team had previously promised to the stakeholder. 

  • We did not acknowledge discipline inter-dependencies during our daily scrums, leading to some blockers going overlooked.

  • Certain game solutions were discovered too late in the process to be reasonably implemented. 

What was learned? 

  • How to measure scope through sprint planning and how to use condition of satisfaction to level scope and predict remaining man hours. 

  • General 2D game development and design experience

  • How to design for the target audience and not for the developer

  • The importance of daily stand-up meetings

bottom of page