Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
March 26, 2019
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Good, But Not Great: The Grove Postmortem

by justin gibbs on 05/19/17 09:33:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


The Grove: Postmortem

The Grove is a two-dimensional side-scrolling puzzle adventure game for the android tablet.  It was developed as a student game by a five-person team, One Eye Productions.  The game was developed using Unity over the course of a semester.  On this project, I held the roles of Assistant Lead and Programmer.  The information below was collected from a 360 postmortem at the Guildhall.


What went well

For Individuals:

  • Sharing art assets between artists and combining efforts on the same artwork
  • As the project went along, our team became better at estimating how long our tasks would take
  • We became more familiar with other disciplines as we helped with our teammates’ tasks
  • Sharing feedback amongst the team, both positive and negative, in a healthy way
  • Not afraid to refactor code when necessary

For the team:

  • Team culture based on trust was cultivated early in the development process
  • Held each other accountable
  • Good idea for our game’s direction from the outset
  • Open and honest communication
  • Conflicts that arose were addressed very quickly as a group
  • Last minute asset requests were accommodated due to the flexibility of our developers
  • Learned some skills from other disciplines
  • Met our individual and team goals


“The Five Dysfunctions of a Team” dictates that trust is the founding principle for all healthy and successful teams.  From the beginning of the project I challenged our team to give feedback honestly and in-person.  In addition to peer evaluation assignments at the end of each sprint, our team would sit in a circle and give one another important feedback.  This came in the form of high praise or constructive criticism.  Ideas flowed freely and criticism was expressed and accepted.  This simple addition to our process allowed our team to navigate personal issues that arose swiftly and efficiently.  We developed a culture that revolved around candid communication and that radical candor served us well throughout our development cycle.


What went wrong

For Individuals:

  • Learning how to use Perforce was tricky at first, and we lost assets due to poor Perforce skills
  • Did not keep up with our asset database as it appeared to slow down our workflow
  • Underestimated hours on some tasks to not disappoint the team, causing delays to the project
  • Lackluster updating of the Game Design Document as other items were seen as more important

For the team:

  • We shared a knack for forgetting small details
  • The deliverables of each sprint were not explicitly communicated which lead to over-scoping
  • Over-planned for several sprints, and adding in forgotten tasks later made crunch time worse
  • Did not cut features early enough, so there was wasted effort
  • Overall lack of accuracy in time estimations for tasks due to inexperience
  • Feedback from faculty was addressed at face value without investigating the why
  • Had no code or art lock


Every sprint our team received user feedback from a different faculty member.  We took their suggestions as law and designed our game for the most recent tester.  The important details about our game were forgotten. Development moved away from some of our initial ideas and into a different realm.  For example, one of the ideas in our pitch was to give the player no direct control over the characters.  Similar to Lemmings or Mario vs Donkey Kong, the characters would move on their own. It was to be the player’s job to keep them safe and guide them to the end of the level.  However, due to the unusual initial concept, we received feedback from a single tester that perhaps controlling the characters would be a better idea.  Instead of sticking up for our design, we simply followed what we thought were instructions.  The final product ended up being representative of many wandering alleyways that lead away from the main street that was our game concept.


What we learned

As Individuals:

  • How to use Unity to make a tablet game
  • To stay in constant contact with stakeholders to ensure the game stays on track
  • Perforce can be used correctly, and it is a powerful tool
  • How to challenge teammates to give more effort to their tasks without hurting morale
  • Working with code that is not your own is not as difficult as it first seems
  • How to install a game from Unity onto a tablet

As a team:

  • As the project went along we learned to rely on teammates more to deliver quality work
  • Making up for each other’s weaknesses by using the rest of the team’s strengths
  • Harnessing each person’s skills to achieve the greatest result for the team
  • Cut things early to not waste time
  • Good conflict management skills across departments
  • How to “Hash out” solutions as part of our design process
  • Changes are unpredictable
  • Skills outside of our chosen disciplines
  • How to make a 2D game in Unity


Communication cannot be understated.  One Eye spent a lot of time giving one another feedback.  We modified design, quality expectations, and interpersonal relationships over the course of development.  There were bumps that came up during development that we navigated using the high level of communication we exhibited.  For instance, early in the project the artists had a disagreement over expectations in the art department.  Being new to the development world we were unsure how to approach and solve this issue.  Our willingness to sit down and speak openly about our feelings and desires for the game guided us back to safe ground.  A solution was found and agreed upon and we went back about our business.  Any coach would say that there is often more to be learned from a loss than from a win.  While there is value in wins, extracting the gold from a loss is ultimately more valuable to a team.  When we did have losses throughout development, our communication skills helped find that gold and turn the tides back in our favor.  The one common lesson that was learned throughout the team is that communicating clearly, early, and often can turn around the course of development and result in a team victory.


Related Jobs

Skybox Labs
Skybox Labs — Vancouver, British Columbia, Canada

Software Engineer — Baltimore, Maryland, United States

Server Engineer
LeFort Talent Group
LeFort Talent Group — Toronto, Ontario, Canada

UE 4 Lead Developer
Pixel Pool
Pixel Pool — Portland, Oregon, United States

Software Developer (Unreal Engine 4, Blueprint, C++)

Loading Comments

loader image