About Lonely HAL

My first game at The Guildhall taught me a lot about Agile Game Development. While developing Lonely HAL, I learned to make a product backlog, how to use Unity, the usefulness of Scrum, how to iteratively release features across milestones, and most importantly, how hard puzzle design and document updates can be.

To provide a little more context, my first game was Lonely HAL, a 2D puzzle game about a robot who uses gravity beams to move around factory floors, collecting gears along the way to open exit chutes to reach lower floors, and eventually, the outside world.

The game development team consisted of 2 level designers (1 game designer and myself), 1 programmer, and 2 artists. Overall, we had a rich experience. We achieved our goal of completing a puzzle game in Unity and learned about how to work in teams effectively. We had a blast along the way too.

To be blunt though, our post-mortem revealed some significant room for improvement in production areas that are relevant to many other teams.

Postmortem: What Went Wrong

Each of these points deserves a conversation. In truth, these points boil down to the larger areas of communication, unavoidable team challenges, and technical difficulties. Some of these are bound to happen in a student team’s first project.

However, some of these issues also mirror relevant philosophical differences in the game industry. These are questions that many people want answers to – the usefulness of design documentation, how to organize puzzle design, and why to integrate a new team member.

Design Documentation

How much documentation is enough? When is documentation a burden?

At The Guildhall, we learn that a Game Design Document is a central component of facilitating a game vision, and with good reason. Teams with 10+ people cannot coordinate and execute a game vision without a solid reference. Otherwise, decisions are lost or constantly re-visited.

Within our 5-person team, we had a difficult time justifying the maintenance of a 50-page document for other reasons than our grade in the class. An honest discussion revealed that this was more of a learning exercise. It genuinely felt like the GDD took time away from our development because our vision for the game changed as we got more and more player feedback between milestones.

Interestingly, The Game Outcomes Project found that use of design documentation in the beginning of development has an 0.23 correlation with project delays, 0.12 correlation with internal goals, and a statistically insignificant correlation with ROI and MetaCritic.

(See http://www.gamasutra.com/blogs/PaulTozour/20150113/233922/
The_Game_Outcomes_Project_Part_3_Game_Development_Factors.php (Links to an external site.))

Author Paul Tozour said, “This seems to suggest that while design documents may make a positive contribution to the schedule, anyone who believes that they will contribute much to product success from a critical or ROI standpoint by themselves is quite mistaken.”

In irony, the biggest stressor in game development at The Guildhall is schedule. This data is right. I firmly believe that consistent GDD updates would have helped the team communicate better and make decisions faster. Constant reference to the doc would have pointed out ambiguous game mechanics earlier in the development process and saved the team some heartache down the road. For example, the team did not plan tutorial sessions or document them during pre-production. Once our puzzles and game mechanics were implemented, we had to spend time on extra game design hours during late stage sprints to give players more feedback. During production, new design decisions take significant energy away from implementation tasks and often drag on because of disagreements.

Puzzle Design

However, the one thing the act of documentation could not solve the fundamental problem of designing a good puzzle. When developing Lonely HAL, we had to determine the role of the game designer -- Does he facilitate a game vision or mandate one? What is the workflow for designing puzzles? Furthermore, how do you design a puzzle that is friendly to new players and engaging to hard-core puzzle gamers?

We started development with the assumption that our game designer should be the main puzzle designer. His vision for the puzzles should drive the team. This undoubtedly put a lot of pressure on him and caused some frustration when we learned that our first puzzles were not “fun” from stakeholders and our infrequent play testers. It is hard to define fun sometimes, and we realized (perhaps later than recommended) that the best solution is to have multiple people design puzzles and have multiple gamer types play our builds. 

Because of this feedback, we realized that we needed to open puzzle design to the entire team and that the game designer should mostly faciliate and polish the game vision and help interpret playtesting feedback into action items. We took time to isolate the mechanics (in this case magnets and exploding boxes -- *not* dying) that are most enjoyable to players and  focus on those mechanics in our design. We ended up totally scrapping mechanics like conveyor belts and trampolines, which were simply vehicles to move the character around without player control. We eventually decided that our puzzles were too open ended -- we made one of our collectible items a key to unlock future levels. This focused our efforts on the puzzle space players wanted to enjoy. 

Because the game designer facilitated puzzle design and gathered feedback out of the "design vacuum", we ended up with much better puzzle designs and game reviews.

Acquiring a New Team Member

After some rough milestones, amidst the shift in puzzle design strategy, we gained a 2^nd artist. He added a fresh perspective and positive attitude to our game. It can be frightening to expose your game to an “outsider”, especially when so much change is underway, but it is thrilling to see a new team member fall in love with your game and work hard to make it better. His art amplified our game in ways we had not anticipated. If you have a project in the trenches, I highly recommend bringing a few fresh eyes to the table. The addition of a new team member brought more objective criticism to our playtesting sessions and helped us remember the fun elements of the game. 

Conclusion

Yes, puzzle game design is hard. Yes, documentation is tedious sometimes. Yes, acquiring new team members can be scary. However, these production challenges are also opportunities -- use documentation, design discussions, and hiring as tools to heighten your game vision. Challenging the status quo can be very rewarding and improve your development experience!