Sorrow: Post-Mortem

Figure 0. Game Trailer by Justin Hrala

Introduction

Play as a young boy searching for his los teddy bear in the forest of Sorrow. Use the four elemental auras to navigate through environmental puzzles and platforming challenges.

Figure 1. Concept Image by Justin Hrala

Sorrow is a 2D puzzle-platforming demo that was produced by four developers over the course of 480 man-hours. This post-mortem covers what went right, what went wrong and what our development team learned over the course of the project. Creating Sorrow allowed us to see the benefits of managing scope, working with a small trusting team, and regularly playtesting.

What Went Right:

Scope

Scope issues were recognized and handled early in development. When planning our project we had a lot of initial concern regarding overscope, which would have led to a lower-quality end product. To avoid developer gold-plating we aggressively relegated non-essential tasks to our wishlist. This meant that all of our essential tasks were completed early in the sprint, often leaving us with extra time near the end of each sprint that we could then allocate to polish and pulling assets from our wishlist into production.

Figure 2. One section of our product backlog

Experienced Artist

Coming into the project our artists had significantly more experience than the average entry-level artist. Having such an experienced artist allowed us to have a much larger asset count than typical, which made it such that art was less of a restriction on scoping in this project.

Small Team Size

Our small team of one programmer, one level-designer, one artist and one lead/level-designer made communication fluid. Having only four members in our team meant that our social network had an edge count of six; by comparison, other groups with 5 members had 10 edges increasing at a rate of  1/2(n^2-n) where n is the number of members in the network. This meant that our communication was significantly less convoluted than a professional game development team of 80 that would have 622 channels for communication.

Figure 3. Our Team (left to right): Steven Nguyen, Andrew Hedges, Justin Hrala, Ben Weber

What Went Wrong:

New Engine

The in-house GuildEd engine that we were using to develop this game was only in a rough alpha state at the time we starting developing on it. GuildEd 1.2.0 only had intrinsic support for circular and rectangular collisions, and only allowed for objects that moved along the ground to have circular collisions. This meant that our environment had to be composed of objects that had rectangular collisions and our player character had to have a circular collision. Another major difficulty was that changes were continually coming to the engine, some of which fixed significantly problems without causing many others. However, later patches to the engine that were supposed to permit us to publish an installer ended up being incompatible with our game to the point that we were not able to publish with an installer at RTM and instead had to ship with the engine and a readme for setup.

Neglecting Asset Locks

Another difficulty we had involved neglecting an early milestone lock. Locking early did prevent us from going into overtime during integration, but due to the small size of the team and seeming ease of integration, we would often try to integrate assets that had been completed after asset lock. Once or twice, this resulted in us working overtime for 2-3 hours on the night before a milestone review. It could have been worse, but fortunately was not.

Short Preproduction Time

Our preproduction period was shorter than desired. By the end of pre-production, our team had working concepts of all of our mechanics in a playable level with concept art. We wanted time in pre-production to iterate on our core mechanics and refine them to insure fun gameplay. One major change that we could have done in pre-production was to get rectangular collision on our player character. This would have allowed us to have more precise collisions with corner pieces of our platforms. With circle collision, the character slid off corners and collided on the empty space in front of their knees if they knew where the circle was. .

What We Learned

Playtesting

Tester feedback is one of the most valuable things to the development process. Because we had managed scope well we had a lot of time to get feedback from playtesters, and to act on that feedback. A lot of the polish in our level layout and visual conveyance came from playtesting feedback, and many of these changes would not have been made without feedback from our playtesters. Not only did playtesters help us find things we would have missed, but they helped us end debates we could not solve internally. We had one debate with a team member who was insistent on having leaps of faith into pits that could contain either deadly brambles or rewarding pickups. After several playtests, the designer noticed that players were just avoiding the pits altogether and decided to make appropriate changes.

Trust

Trust is important to the success of a team. Because we all trusted each other to give honest feedback and to listen to each other’s criticisms openly, we had no difficulty confronting one another about issues we saw in the game. The end result of this was that we had more refined assets and mechanics that been triple-checked and improved with input from each member of the team.