Berry Glider


Fast Facts




Team Size




Lead Designer

2D Vertical Platformer


5 (2 level designers)

Android Tablet

Agile Scrum

Slack, Discord, Zoom, Perforce, Miro, Excel, Wiki

The Game

"Berry Glider is a tablet game that leads the player downward through a gauntlet of obstacles and hazards which must be navigated via the use of the “glide” mechanic – i.e. the player’s control method. Collecting berries to maintain glide energy and deftly soaring through 3 levels, the player aims to improve their speed, gather fruits to fill a gift basket, and refine their gliding skills."





General Responsibilities:

  • Developed top downs and prototypes
  • Co-designed level 1
  • Designed and implemented level 2
  • Created tile maps and layers

  • Placed enemies and obstacles into level

  • Used pickups to create player flow

  • Researched sound FX and music

  • Implemented audio into all areas of the game

  • Logged assets in Excel database

  • Collaborated with team members

  • Logged tasks on Kanban board

  • Participated in scrum meetings retros

  • Co-edited documentation

  • Pitched the project to stakeholders

  • Co-designed storyboard for cinematic

  • Assisted with particle systems

  • Constructed and formatted credits text block

  • Took live notes while Kleenex testers play-tested the game

  • Contributed to game design

Special Assignments:

  • Accountable for final level and sound design as Lead Designer


Images & Involvement

With a limited set of art, I was able to a create a visually appealing level through use of tile-map layers. I suggested layers to the team, which they were not using in this manner prior, along with other ideas including a health bar with hearts that grayed out at the top when health was lost, conveyance signage depicting arrows when collectible were nearby, berries as a player to create player flow, but-throwing squirrels, and adding evil laughs to the squirrel to make it appear less friendly. 

Branches were carefully placed to create obstacles and recovery zones for the player. Through the use of pickups, I was able to attract the player to specific areas of the level while leaving plenty of room for strategic choice.   

Level 1 was designed to start as a tutorial before becoming a traditional first level. Our team lead and I collaborated on the design of this level to ensure that the player would learn the mechanics of the game, how to score higher through use of pickups, and be ready for the skills needed in level 2.  

Level 1 introduced enemies to the player in the form of evil, pine-cone throwing squirrels and angry looking eagles patrolling on linear paths. I chose music for level 1 that was intended to sound peaceful from the beginning yet become increasingly more complex and climactic as time went on, adding a level of irony to the treacherous path that lie before the player.  

Throughout the project, I stressed the importance of planning before implementation, but also building time into our backlog to account for bugs and unexpected issues with the file-sharing software. I learned from a previous project that this could take many unexpected hours to sort through, and by building it into our backlog, we didn't really run out of time to achieve what we set out to do each sprint. 

Mechanics in level 3 were faster and busier. I chose the audio in this level to create a sense of chaos and excitement for the player. I also suggested we use a third, distinct look for this level instead of flipping back to level 1's light blue, day time style; my suggestion was a bright orangey sunrise. 


Right from the start, I was on board with keeping the mechanics to a minimum and the team was in agreement. By following the KISS principle (Keep It Super Simple), we had lots of room to refine gameplay and add juice later. 

What I Learned

One of the key things that I was reminded of in this project was how important it is to establish clearly defined roles in the beginning of the project, and that everyone knows where the boundaries of those roles exist.


While we did establish loose roles in the beginning of the project (level designer, programmer, artist), and also who among those roles, who was accountable or informed for each kind of major task category, we could have dove deeper and addressed the gray areas in more detail (i.e. UI, Audio, VFX, Trailer, etc.). As most of us were new to working on a game project as a team, there were simply things that did not occur to us until later in the project after misunderstandings arose, and with such a small team, we naively assumed it would all work out.


We later established clearer roles and responsibilities, but in the future, it would be even better if those were mostly parsed out from the beginning and tasks were pre-assigned to the proper individuals or teams in advance of working on those tasks.