top of page

Download

Responsibilities

Development Info

  • Design, whitebox, and build out two of the four levels in the game

  • Created and maintained documentation including level design documents and sprint retrospectives

  • Worked with artist and game designer to help standardize asset sizes and screen layout

Robbin’ Robin is a single player, two dimensional, stealth-based puzzle game for the Personal Computer (PC). Players must plan solutions to each puzzle, execute their plans appropriately, and make adjustments when things do not go according to plan. 

 

Robbin’ Robin’s narrative centers around the bedtime story told by an anthropomorphic raccoon named Robin Raccoon. When Prince Peter Pig the third takes the food Robin’s family needs to survive, he must sneak into the prince’s castle in order to get it back. As he progresses through the castle, Robin finds food small food items throughout as well as a large food stash at the end of the game.

Game Summary

Design Goals
  • Game: Robbin' Robin

  • Engine: Unity

  • Genre: Stealth Puzzle Game

  • Team Name: Bad Axes Studios

  • Team Size: 6 Developers

  • Role: Level Designer

  • Development Time: 2 Months

  • Work Schedule: 20 hours / week

Post Mortem

What Went Well
Challenges
What I learned
Summary
  • From the beginning of the project, we focused on planning out the size of the assets and the screen layout. The level designers worked extensively with the team's artist so that during production we were able to create four levels with a consistent visual appearance.

  • As the project progressed, we got better and better at collaborating. The level designers worked together to create a balanced difficulty curve. We introduced the mechanics in ways that players easily understood, and achieved a balanced difficulty curve.

  • Keeping up with documentation was a challenge. It was difficult to balance the design process, other classes, and everyday life and still keep all documentation up to date.

  • We had a hard time adhering to our definition of done. On more than one occassion we lost sight of what was required to reach the milestone. As a result, we ended up putting in overtime on smaller issues instead of focusing on more pressing tasks.

  • The team learned a lot about the iterative design process. By realizing the importance of this early on, we were able to make difficult decisions later in development. The levels went through numerous revisions, but improved with each one.

  • Time managment is crucial. Balancing the team game project with work from our individual classes was very challenging. Learning to devote the proper amount of time became increasingly important as production ramped up.

Post Mortem
bottom of page