Design Blog - Postmortem

Development on Stumblebumps Unite has, finally, wrapped.  This blog will identify things that went right and why, as well as things that went wrong and what could have been done differently. In terms of what went right, asset lists, playtest feedback, and iteration will be discussed. Level workflows, playtest demographics, and level length did not go so well, but methods to address these issues are also identified. Game development is like learning how to build a house in the middle of construction while the client is requesting changes to the floorplan, but Stumblebumps Unite taught where a designer can plan ahead and how to adapt when specifications do change.

What Went Wrong?

What went wrong? Repeatedly asked level designers to change their workflow.

What could have been done differently?

From the start of development, I could have created full sample levels. These levels would have informed scope, organization, and lighting. Building of these samples, I could have designed a solid pipeline at the get go. Furthermore, I should have asked programmers for a stable method to playtest levels from the start. Early one we went through a few different methods for spawning characters into the levels for testing in editor. This was resolved fairly early, but it would have been better if I made sure it never became an issue.

What went wrong? Not enough playtesters from the target audience.

What could have been done differently?

Many of the playtesters were other game developers from within the game development major. These individuals provided valuable feedback, but considering Stumblebumps Unite is a casual game they don't accurately reflect the target audience. My primary method of acquiring playtesters outside the major was to sit in the library and ask passerbys to play the game. Towards the end of the semester, I started bringing more of my outgoing friends to help with this process, which is something I could have done more of. Additionally, I could have leveraged more of my online connections to help find playtesters. The feedback forms already included questions about the player's experience with competing titles, so simply casting a wider net would have allowed me to analyze feedback in the context of what the player enjoys. 

What went wrong?  Long levels led to fewer interactions between players.

What could have been done differently?

This problem was solved but costed us considerable time. Solutions I considered included redesigning levels with more chokepoints, shifting focus to platforming over interaction, and shortening levels. Ultimately it was decided to shorten the levels. We already designed modules that were assembled into the longer levels. Level designers converted each module into a standalone level, and a new round-based party mode was implemented in which players compete to accumulate points. These changes had the effect of frequently resetting the playing field, allowing more chance for players interact. 

What Went Right?

What went right? Asset master lists kept the backlog full, artists informed, and the project moving forward.

Why did it work?

I easily filled and updated our spreadsheet lists with asset names, descriptions, and requirements. The producer pulled all the necessary information for creating and verifying Jira cards from these lists, keeping the production process rolling without my intervention. Furthermore, we linked tasks to a range of relevant asset list rows giving artists easy access to reference, descriptions, and specs for each asset. Originally these lists did not take full advantage of Google Sheets' features, but were quickly revised to include priority dropdowns, status checkboxes, colored formatting, and reference images. The flashiness of the features made the spreadsheets fun to work with, leading artists to frequently take advantage of the resource.

What went right? Putting player responses in the context of observable behaviors informed more efficient changes.

Why did it work?

I quickly found that what players tried and how they responded to the game was more valuable than the feedback form responses. Moreover, the forms were more helpful in the context of observable behaviors. For example, some player reported the dive going too far and some not far enough. But from watching gameplay I saw that players often slide off platforms after diving. The issue? Diving lost momentum quickly in the air but slide too far on the ground. The problem was solved by implementing separate drag values when diving in the air vs. diving on the ground. 

What went right? Focus on iteration.

Why did it work?

At the start of development, I wrote “developers will prioritize iteration on existing designs over creating new designs” as one of four design pillars. Often level designers were eager to create new levels, but this pillar served as a reminder to iterate on existing content. In the end, levels saw the most dramatic leap in quality between the start and end of the semester. Other content saw improvement as well, with all artists being happy to ask questions and make changes to their work. Remembering to focus on refining our content allowed for the creation of the kind of small details which make gameplay memorable.

What Would You Do Differently?

As already touched on, Stumblebumps Unite would have benefitted from revised approach to external playtesting. First, I would have done smaller, more frequent playtests. Often playtests would be large day long affairs that I put a lot of planning into, which just was not necessary. Additionally, with the help of friends, the dev team, and online connections I would have strived to reach more external players. 

What Would You Do Again?

As a designer, I would definitely implement open documentation again. For Stumblebumps Unite, that took the form of a Google Drive game design "wiki." The important part was not the platform, but that the entire team had edit access, various types of documents could be created, and it was organized in a hierarchal structure. Allowing the entire team to edit documentation sped up workflows, kept documentation up to date, and improved engagement with the development process. Being able to create types of documents improved usability and readability. Lastly, hierarchal structure made it super easy to keep everything organized and accessible. 

Conclusion

Stumblebumps Unite taught me more of the types of issues a designer can encounter. While I struggled in finding my target audience, and especially in providing appropriate expectations for level design, the experience taught me to plan solutions for such problems from the outset. Moreover, I learned techniques for organizing assets, conducting playtests, and promoting iteration that I will carry forward into future. These are only some of the biggest lessons learned; covering everything would take far too long. Instead, I aspire to show the true breadth of my learnings in whatever project comes next.