Learn about the development of the popular and acclaimed PlayStation Network Metroidvania -- including how the game's distinctive look evolved and competition for studio resources created friction.
In the fall of 2010 as our first game, Tales From Space: About a Blob, neared completion, we started talking about new game ideas. Prior to creating About a Blob, DrinkBox Studios did primarily contract game development work to get the company up and running. Nearly three years later we were finishing our first internally developed game and while there was a lot to be proud of, there were some mistakes we didn't want to repeat. With that in mind we had a number of high-level goals for our next project:
A game with immediate appeal. People must "get it" right away and be excited about the concept
A setting and style more grown-up and hardcore gamer-centric, but that still stood out as unique
A clear vision for the gameplay and overall game design that was well-defined before we entered full production
Fast-forwarding to April 2013, we believe we accomplished our goals with Guacamelee!. When Guacamelee! was released on PSN it became the top downloaded game for both PlayStation 3 and PlayStation Vita for the month of April, including both retail and download-only games in both the Americas and Europe. Along the way Guacamelee! was nominated at IndieCade and the IGF, and received recognition at PAX East, PAX Prime, and E3.
This success was a huge relief at the end of a long road, but while the results were great the development wasn't without its hiccups.
1. Game Design Vision
During development of our first game, Tales From Space: About a Blob, we struggled to define a clear vision for the gameplay. Was it a platformer or a puzzle game? What was the game really about and how should levels be structured around that? We thought we'd figured out answers by the end of development, but that process took the duration of the project and as a result wasn't fully reflected in the final game. For our next project, we didn't want to repeat that mistake.
Guacamelee! was born out of team pitch sessions that started taking place in the fall of 2010. We spent a lot of time talking about the kind of project we thought would work well for the team and discussed the high-level mistakes we felt we'd made with our first game.
Early concept images for Guacamelee!
Once we developed a sense of the kind of game we wanted to create, we asked everyone to put together single-page pitches for each of their own ideas. Guacamelee! was initially proposed as a pure brawler by our concept artist Augusto Quijano, who was originally from Mexico. We gradually combined other gameplay mechanics, including attack moves doubling as locomotion, overlapping parallel worlds and a Metroidvania structure.
Adding these elements to the brawler concept created a debate about whether too much was being combined. We wanted to ensure the game stood out, but at the same time we were concerned about spreading ourselves too thin over multiple ideas, or possibly basing the game around a mechanic that didn't work. We spent a lot of time on our previous title trying to get the basic mechanics to work together, and that struggle hurt the final product because it limited the time we had for refinement and polish.
In this case we concluded that the different mechanics for Guacamelee! were interesting and complemented each other within the Mexican theme, so we tentatively decided to use them all. However, in light of our concerns we decided to be cautious and avoid committing to making the game until we knew it would really work. One of the first things we did was create a concept video in Flash.
Concept video
This concept video was one of the most useful things we did for the project. It helped us quickly visualize the world and let us develop a concept for the combat system. We came up with the basic attacks (dash, uppercut, slam and throw) through this process and explored how they would be used for both combat and platforming. It's striking to look back at the video and see how closely it matches the final gameplay, but with a few key differences.
We followed up the video with two incremental demos. The first was a combat demo that let us explore how combat would work, how wrestling moves might fit in, and let us experience the special moves as both attacks and locomotion.
First combat demo
Our next demo added in a free form, dimension-swapping mechanic, simplified the basic combat moves, and was built as a vertical slice. By this point, all the key mechanics of the game had been developed and proven to work.
Trailer after vertical slice
Although questions remained, the game was well defined. This was accomplished using a small group and rapid prototyping, with the freedom for people to try different things. We considered this a major accomplishment in the context of our previous title and it gave us the confidence to move into the full production of the game.
2. Art
Our art team did a great job on Guacamelee!'s visuals and their work has received special attention from both fans and critics, including nominations for IndieCade and the IGF in the area of visual arts.
Several people on the team previously worked on retail console games, and when we started the company, we wanted to stay away from the mud, dirt and grimy brown textures typically seen in triple-A titles. Our first game bucked that style by being round, bright and friendly.
While we were very happy with those visuals, we felt they gave the wrong impression to hardcore gamers. The overall impression for many people was that the game was designed for kids, and when we showed public demos, the visuals attracted casual gamers more than the hardcore gamers we were hoping for. In contrast, when we started Guacamelee! we made a conscious decision to try and make the visuals more appealing to hardcore players.
We tried to move from a soft style to a more angular look
We wanted a more aggressive, angular look that still stood apart from other games. The starting point was Mexican culture and folk art, with its vibrant and colorful appearance. We spent a lot of time during the early development of the project trying to capture the right style and color palette for the world, as well as the right shape and look to the characters. Agonizing over details at the beginning of the project made later development much easier.
Progression of the Juan character's look
While this success was naturally a result of the talents of the art team, it also depended on a cooperative back-and-forth between the art, tech, and production departments. In particular, over the course of Guacamelee! we changed how effects were developed, counter-intuitively putting the development more into the hands of the tech team and then letting the art team direct refinement.
Early screen mockup versus final game
For character visuals we doubled down on the animation technology we'd built for our first game. The artists made animations in Flash and imported them it into the game as animated geometry. Avoiding traditional sprite sheets meant we had 60 fps animated characters that could be scaled up and down without resolution issues, while using significantly less memory. Of course, any animation system only looks good if the animation itself is done well, and to the credit of the animators that worked on the project the animation was excellent.
3. Hitting Due Dates
On this project, we set milestones for ourselves based on showing the game to external people, specifically targeting publisher meetings, public showings, festivals and competitions. This wasn't something we initially planned to do, but in retrospect the approach was a major benefit. Although external milestones run the risk of producing a lot of throwaway work, we've found that internal milestones risk creating many unrefined features.
The setup for Guacamelee! at two different PAX events
During Guacamelee!'s development, each public deadline was spaced several months apart, giving the team enough time to make noticeable progress, but still enforcing a constant pressure. This included, in order: production of a 3-5 page publisher pitch for GDC in March 2011, a concept video and combat demo for E3 in June 2011, a playable build for entry in the IGF in November 2011, a public demo for PAX East in March 2012, a press demo for E3 in June 2012 and a public demo for PAX Prime in September 2012. Having to show the game constantly while still making progress towards the final release forced us to make hard decisions about what features to include. This ensured we focused on the most important items that we thought people could measurably appreciate.
We tried to show Guacamelee! wherever we could
There were additional benefits to the public deadlines. We were able to repeatedly observe the strengths and weakness of team members at going from prototype to polished product, we were able to collect external playtests on what was working and not working in the game, and we were able to adjust our approach to production repeatedly after each milestone.
4. Working with Sony
Guacamelee! was part of the Sony Pub Fund initiative. The Pub Fund works as follows: in exchange for a period of exclusivity Sony pays an agreed-upon amount to the developer after the game ships -- typically something approaching the budget of the project. This means the developer must fund their own project, but after the game ships they can be confident that they will at least make their budget back. The developer keeps ownership of their IP, and once Sony's payment is recouped the developer receives further royalties. This is a great model for developers who: A) can fund their own project, and B) greatly value a solid minimum return on their game.
Guacamelee! at Sony's press conference, E3 2012
Working with the Pub Fund was not our original plan, however. Although we talked to Sony about the Pub Fund near the beginning of the project, we did not reach an arrangement until almost a year later. In the meantime we were in negotiations with other publishers to ensure we could get a slot on XBLA, and we were close to striking such a deal before we came to terms with Sony.
In the end we were very happy with the Sony arrangement. It mitigated our financial risk and provided on-the-floor exposure for the game at trade shows we wouldn't have otherwise attended (E3, Gamescom, etc).
As mentioned, this came at the price of some exclusivity. To weigh the options we created a spreadsheet to work out the financial break-even point of an exclusive versus non-exclusive arrangement. That analysis, plus various intangibles (like placement at shows in the Sony booth and the risks associated with working with third party publishers), told us that the Pub Fund was the way to go.
In practice, working with Sony was fantastic. The Sony team focused on indie developers is passionate and in touch with the state of the scene. We never experienced undue pressure from them or unreasonable requests. Quite the opposite, what they offered were a series of excellent opportunities. For example, Sony put Guacamelee! in Vita kiosks at Best Buy stores, which no third party publisher could have accomplished.
Other Sony benefits: the spring sale and a Platinum trophy
5. PR
For our previous two games public awareness wasn't quite what we hoped for. When we launched Tales From Space: About a Blob, we had never gone through the complete game launch process before and we had very little understanding of how to create awareness. We showed the game at PAX Prime, but struggled to get many preview articles written about it.
Members of the DrinkBox team were slightly visible at the IGF awards
Near the end of our second game, Tales From Space: Mutant Blobs Attack, we started working with a PR firm. We felt this was a good fit for us. Some teams do all their own media outreach, but this appears to rely on certain personality traits we weren't sure we possessed. In addition, we felt there was a lot we could learn from observing a PR firm in action.
For Guacamelee!, having deadlines driven by public shows meant we were constantly demoing the game, which helped get more articles written about it and acted as a long, slow burn on public awareness. Our PR firm also organized a press tour that helped build a strong awareness for the game leading into launch. Through our efforts we had proper previews, timely reviews and people seemed to generally know about the game.
How much was the increased awareness a result of our improved efforts versus a result of the game's intrinsic appeal? That's hard to say and we've struggled internally to assign concrete value to the different things we did, but regardless we can definitively say that we made substantial improvements in public outreach for this game.
1. Managing Personalities and Leadership
People who start an indie studio or work at an indie studio are often fiercely independent --that's why they're attracted to indie development!
The truth is that for a lot of people working on indie games, they want to have control, they don't want to compromise, they may have difficulty working in a group and they may have trouble working for a common cause when they disagree on priorities. While this can be said for people working anywhere, in our experience this is especially true of indie developers.
During the development of Guacamelee! we had particular difficulty managing some of the personalities on the team, and at different points on the project we had to dismiss two individuals. These dismissals were not related to work performance, but instead were precipitated by a breakdown in working relationships.
While in the past people had left the team, we had never experienced problems like these before and the build-up was a surprising and time-consuming disruption.
Trouble ahead
When we founded the studio a loose formal structure developed. The initial company was small and had people in each discipline who could communicate comfortably and confidently with one another. Everyone owned part of the company, was invested in its success, and we were all peers, which made strict rules and policies awkward. While the initial members of the team had titles (largely for the purpose of communicating with publishers), we didn't want formal roles to dictate what people felt they could contribute to or question, and so we avoided creating new ones.
During Guacamelee!, we encountered difficulty scaling this approach. Some new members of the team struggled to find their place alongside peers when working without a clear authority structure. Lacking the confidence to navigate disagreements constructively, in frustration these team members sometimes ignored decisions or emotionally disengaged from certain tasks. As a result, we've begun to put a clearer authority structure in place for the team, and we've become more aware of the need to monitor personalities and provide ways for people to make their concerns known.
In other cases we failed to set clear boundaries on inappropriate behavior. For example, it came as a surprise to discover individuals working on personal projects that seemed to be affecting their work performance and that were, in our view, in conflict with their employment obligations. As a result, we've become more explicit and proactive about enforcing company policy and behavior.
2. Memes and References
While we've placed this item in the What Went Wrong category, it's probably more of an "Important Thing That Happened That Was Both Good and Bad." Our previous titles were full of references to other games, pop culture and online memes such as "O Rly owl" or "Business Cat."
A previous in-game reference
Why do this? It amuses the team and creates lots of little jokes that players can discover. Even if people don't understand the jokes themselves, the source material creates a jumping off point for an interesting image or phrase. Naturally we continued this trend with Guacamelee! and thought nothing of it. We made an effort to integrate the references into the game world within the Mexican theme in order to avoid the accusation that they were unnaturally forced in.
When the game was released the memes were a problem, and a vocal group of people took exception to them. In particular, the memes seemed to offend some people. From our perspective the references were a little piece of extra fun primarily isolated to the two towns the player visited. There were references elsewhere in the game but they were few and far between.
However, in retrospect, things may have gone too far. The emphasis seemed to have moved more towards memes than game references. In addition, this bit of environmental spice was not as unique as it had been in the past, and games such as Borderlands 2 made the approach seem less fresh.
One reference in a town area of Guacamelee!
On the flip side, in spite of early blowback on the memes and references there remain a large group of players who appreciate them. The screen capture capabilities of the Vita allowed players to Tweet pictures of the references to each other, and a few sites even wrote articles cataloging them. Did this hurt the game more than it helped? It probably helped it more than it hurt, but in retrospect we would like to have emphasized the game-references more than the memes, and perhaps scaled the quantity back a bit.
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.
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.
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
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.
Read more about:
FeaturesYou May Also Like
