Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: DrinkBox Studios' Guacamelee!
View All     RSS
January 23, 2018
arrowPress Releases
January 23, 2018
Games Press
View All     RSS






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


 

Postmortem: DrinkBox Studios' Guacamelee!


September 23, 2013 Article Start Previous Page 5 of 5
 

3. Testing and Scope

A number of nasty bugs slipped into the final game, chief among them a bug where the player could get locked into a fight arena. There were other problems too, including a blocking issue in our first patch that affected players who had a save game past a certain point in the story -- we were forced to pull the patch within a few hours of its release.

How did this happen? Looking back, we blame these problems on a combination of overconfidence, issues with scope and a lack of internal communication.


The bug counts went down, but what wasn't being caught?

Overconfidence: We had already shipped two games with a small 1-2 person QA team without any major problems. We had put out numerous demos for Guacamelee! using the same QA process. The approach had worked in the past, so we weren't concerned about it working in the future.

Scope: The arena bug was subtle, although the results were not, and was not easy to reproduce. We were dimly aware that the bug existed, but its frequency was unclear. Because of the difficulty in reproducing it, the scope of testing the rest of the game and the small size of the QA team, the bug was not properly identified.

Lack of Communication: The bug that forced us to pull our first patch was obvious and severe. Here we identified a breakdown in communication between tech, QA, and production. The testing implications of changes in the patch hadn't been properly communicated to QA and a formal testing grid wasn't produced.


Some of the bugs of Guacamelee! fixed before release

We've since adjusted our process, but these issues were very difficult and stressful to deal with. In retrospect we would have been well served getting additional QA help, or possibly external QA support late in the project when it became clear our internal testing was overtasked. We've also adjusted our process for building our test-matrices in order to be more thorough. Most importantly, however, we've been humbled by these missteps and become more paranoid about our testing process.

4. Difficulty Spikes

While there are a number of criticisms regarding Guacamelee!'s gameplay, one that is especially frustrating for us is the complaint some people had about difficulty spikes. Parts of the game are challenging and that's intentional, but the difficulty spikes suggest we were not thinking critically enough about ensuring players were prepared for key challenges.

Three painful examples of the failure to properly train or communicate mechanics to all players include:

  • Jump height control: If a player doesn't understand that holding the jump button longer makes them jump higher, then they will find some platforming challenges extremely difficult or tedious.
  • Roll usage: We didn't clearly explain all the ways someone can use roll, including using it to cancel out of any attack move. Additionally, we've seen that some people don't roll often or at all, instead using jump to dodge
  • Players can perform combos by hitting the enemy fast enough to keep them in their stun state. A few enemies, however, can break out of the stun and this is not well communicated


The team's favorite battle could also be the most frustrating

The boss fight with Javier Jaguar near the end of the game is the best example of a major difficulty spike that was overlooked. Jaguar is one of the only characters in the game where the player must fight defensively. This is the favorite fight in the game for many people on the team because it has to be approached with a good understanding of the game's combat system. Our mistake was failing to recognize that the player had not been given enough training in the game's more subtle mechanics up to that point. In retrospect information about the problem was available but we didn't take it seriously enough, and we consequently received a rude awakening through player feedback.

5. Multiple Project Resource Management

During the development of Guacamelee! we released our second game, Tales From Space: Mutant Blobs Attack for the PlayStation Vita. The title was originally planned as a 1.5 version of About a Blob aimed at the Vita's launch, but over time became a follow-up game -- although not officially a sequel. For the first time we had multiple internal projects running simultaneously, and we encountered challenges balancing and planning the two projects with a small team.

We didn't have a formal process for deciding how to balance resources. Personnel allocation was ad-hoc, based on the projects' producers simply saying who was wanted for what, as needed. Over time it started to feel like there was low-key competition between the two game teams, and Guacamelee! felt like the sexier project.

It was in this competitive environment that the Mutant Blobs Attack team got into the habit of accommodating Guacamelee!, and the resources needed to ship a Vita launch-day version of Mutant Blobs Attack to a high level of quality were gradually reassigned.


Development of Tales From Space: Mutant Blobs Attack overlapped Guacamelee!

After the internal Mutant Blobs Attack alpha was playtested the issue came to a head. The game's levels still needed a lot of work, we were concerned about the game's overall quality and weren't sure we'd still be able to be a Day One launch title. In a panic, resources were shifted around between the projects to make sure we completed Mutant Blobs Attack on time.

Ultimately, this worked: the game shipped as a launch title and we were happy with the quality. However, the sudden change in priorities was not planned for and there was a heated debate about what had happened and why. Fundamentally, there was a lack of explicit communication and precise agreement on what was needed for each project. Resource allocation has since become more formalized, with more discussion about needs and consequences.

Conclusion

We're very proud of Guacamelee! and in spite of various challenges its development was generally smooth, resulting in a strong game that required minimal overtime. Especially satisfying is the fact that Guacamelee! is a combination of many different peoples' good ideas, which is exactly what we hoped making a game could be like. It's been a great success for us so far and we continue to look toward additional platforms to release it on.

Data Box

Developer: DrinkBox Studios Inc.

Publisher: DrinkBox Studios Inc.

Release Date: April 9, 2013

Platforms: PlayStation 3 and PlayStation Vita via PlayStation Network

Team Size at the Beginning of the Project: 5

Team Size at the End of the Project: 13

Length of Development: 8 months preproduction, 11 months production

Lines of Code: 350,000 (including a lot of legacy code from two previous games)

Development Tools: DrinkBox Engine (proprietary), C++, GameMonkey, FMod, Box2D, wxWidgets, 3DS Max, Adobe Photoshop, Adobe Flash, SVN

About the Author

Chris Harvey is a co-founder of DrinkBox Studios Inc., an independent game studio founded in 2008 in Toronto, Canada. He has credits on games including Guacamelee!, Tales From Space: Mutant Blobs Attack, Heroes of Might of Magic: Clash of Heroes HD, Marvel Ultimate Alliance 2, and Full Auto 1 and 2. Chris graduated from the University of Toronto with a B.Sc. in Computer Science and an M.Sc. in Machine Learning.


Article Start Previous Page 5 of 5

Related Jobs

Qualcomm
Qualcomm — San Diego, California, United States
[01.23.18]

Game Designer
Insomniac Games
Insomniac Games — Burbank, California, United States
[01.23.18]

Gameplay Programmer
Sanzaru Games Inc.
Sanzaru Games Inc. — Foster City, California, United States
[01.23.18]

Gameplay Engineer
Sanzaru Games Inc.
Sanzaru Games Inc. — Foster City, California, United States
[01.23.18]

Environment Artist





Loading Comments

loader image