The Walking Dead: Outbreak


The Challenge - This title was built off of the tech and design base developed in our previous release, Pacific Rim: Breach Wars. While this gave us a solid foundation to build off of, there were plenty of challenges to overcome. What seemed like minor client preferences caused significant changes to some key game systems. And, of course, the team wanted to iterate on the design, taking into account lessons that were learned from previous projects.



Redesigning the Battle


This game builds off of the match-3 style core battle mechanic we had already built for previous projects. However, a few goals were introduced that significantly altered the design of the system. Those goals were:


As I set out prototyping layouts for the battle scene, it quickly became apparent that the existing L/R oriented side view layout that we already had going was not going to work out. I redesigned it so the player characters were arrayed across the screen as portraits, with the enemies vertically opposed at the top of the screen, much like you see in many other match-3 battlers. This was met with disappointment from the client, who felt that this reduced the possibility for impressive character art. However, after the fact, the team felt confident that it was the right call to make the best overall game experience possible.

In order to make the gameplay snappier, the design team removed one of the gem colors and reduced the height of the gem board, meaning the gems would cascade more often and be easier to match. This, in combination with the removal of the domination meter, left significantly more room on the screen, which I was able to use to good effect to emphasize the characters and their UI and ability effects.



Onboarding


Studio leadership, as well as I personally, had felt to this point that onbaording was a weakness of the studio. When it came time to consider the onboarding for this project I took it upon myself to jump in with both feet and try to wrangle this system into shape. I wanted to fundamentally shift how we thought about onbaording as a studio, and at that I believe I was successful. With the help of the design and product teams, I set several goals for this process:


I started by creating a high level study of the psychology of onboarding and a breakdown of how existing or potential systems play to these strengths and weaknesses. This sort of academic treatise is an unusual step to take, especially during the fast paced months of an actual production schedule, but I felt it was necessary in order to shift the culture around this topic. This study covered the following topics:
Based on this work, I then designed out a number of conceptual systems that could be used to accomplish certain goals, or to address specific problems. Below are examples of a few of those systems:
Once the systems were in place, we used several rounds of user testing to validate and refine our onboarding design and execution. This consisted of outsourced playtests of individuals within targeted demographics, which were recorded and annotated. We also used analytics to measure engagement and to determine our progress against our target KPI's.

As a result of this robust process, we were able to increase our D1 retention by about 8% over our previous title, which used the same engine and similar systems.



Testing Analysis


As discussed under the onboarding topic, we used multiple rounds of user playtests to gather feedback on our systems. I took it upon myself to build a review template, which I filled out after carefully watching and annotating all the recorded tests. By compiling the feedback and breaking it down into an easily digestible format that highlighted the key takeaways, production and design teams were much more empowered to make use of the results effectively, and to schedule the appropriate responses into the release cadence. The template broke down issues by




Prototyping and Wireframing


As usual, prototyping and wireframing system designs was the largest part of my involvement on the project. This process would start with a review of the design spec incorporating my feedback from the UX point of view. Then I would create a clickthrough prototype which would be evaluated by design and other stakeholders. Usually there would be several rounds of iteration before I had enough buy-in to consider the design ready. Then I would make a detailed wireframe spec. This spec was used by our visual designer to mock up the screens and produce assets, a process in which I was closely involved, giving frequent feedback. The mockups and wireframes were then delivered for implementation, another process which I watched closely to make sure the implementation hit the intended target. Finally, there would be a team wide review before deciding the feature was ready. If so, it would then be sent to QA in preperation for release.



Conclusion

This project iterated on many systems that existed from earlier projects, allowing us to hone in ever tighter on the game experience we were after. The extra focus on the onboarding system was a big win, which will be carried forward into future projects. The result was a game that performed well in soft launch, meeting or exceeding its target KPI's and giving us great confidence that it will succeed upon release.







Top