Darwin's Yearbook: Case Study
In this case study, I will analyze the main problems, solutions and lessons learned on the development of the game "Darwin's Yearbook".
Darwin’s Yearbook was a game developed by Cangrejo Ideas for Cartoon Network. The game is about Darwin, who is in charge of the yearbook, so he takes his camera and photographs different students and teachers to complete it. This game was aligned with a set of episodes called “Darwin’s Yearbook”, so the game had to be developed in a short amount of time to air at the same time as the chapters in Cartoon Network. In this project, I was the Lead Game Designer. I was leading a team of two game designers and communicating constantly with other teams. My responsibilities varied from directing the initial brainstorming sessions and pitch of the game, to creating the documentation, design mechanics and levels and supervising the design of the game translates in an effective manner to the art and development teams.
1. Understand the IP and looking for untapped opportunities
The first problem to solve was the genre of the game. As one of the main requests was to give the camera an important role, we had a big initial set of ideas. My first activity was to narrow down ideas using a thorough investigation about existing TAWOG games, while using the SCAMPER technique in some of them, to detect untapped opportunities and see how could we transform existing successful TAWOG games to create a novel and fun experience, taking into account player previous experiences with TAWOG games.
After the initial investigation and applying the SCAMPER technique in 3 of the most successful TAWOG games, we came up with a narrow set of initial ideas. We discovered that we had the opportunity of creating a Puzzle/Platformer game because most of the games were fast reactions games but the ones most successful were platformers. We include the Puzzle element because that was going to allow us to focus the game on an older public segment that can solve more intricate and difficult puzzles, while the younger public can concentrate on using the available mechanics to travel the levels while also understanding the puzzles in a more friendly and directed manner.
2. Using early prototypes and improve documentation
As this was the first Puzzle Platformer game of Cangrejo Ideas, there was a big amount of uncertainty involved for the development and design team. Our first task as a design team was to create early prototypes in order to prove that the proposed game mechanics were fun and that they would cover the desires of the target public and TAWOG fans. Me and Nicolás Muñoz were in charge of creating many prototypes using Construct 2 and Unity to present to the Project Leader and to the Development Leader, so they can assess the technical requirements to complete the game.
Also, taking into account this uncertainty, I developed a new system of communication and documentation, standardizing the GDD layout so updates to the document were faster and more effective to deliver the desired information to the different stakeholders (in this case, we had to communicate the idea to the Art and Development team, the Project Leader and also the client, in this case, Cartoon Network). To reduce the amount of “flying” information in different documents that get easily outdated in such a short span of time to develop the game, I start to use a Wiki to put definitive information, so each member can easily search and find the information that he or she needs to develop the game. Also, harnessing the fact that we work in small diverse teams, there was a lot of face-to-face communication, and each decision was recorded immediately in the wiki, that contained all the updated information about the project.
3. Playtesting and using signifiers
To ensure the balance of the game, we playtested the game constantly with other team members and later, with members of the target public. Early playtest sessions detected that one of the main pain points for players was going to be how to teach the mechanics of the game, that included novel mechanics in TAWOG games like stun enemies, modifying the terrain using objects, block enemies path and solving puzzles using buttons and levers to unlock different sections of the level.
To ensure that players understand the different game mechanics and solve the funnels that we detected, we used signifiers, that clearly communicate how to interact with the elements of the level. But, taking into account the target public, we decided to add tutorials, in the form of posters pasted on the wall, just where the player needs to interact with a mechanic in a different way. This proved to be a good solution in the end, because not only add Art value to the game, making the tutorials diegetic to the experience, but also because it allowed us to reduce text and use wide accepted symbols and drawings, taking into account that the game needed to launch in more that 20 languages simultaneously.
Great reception by the client and the community
The final reception of the game was great. The Client was pleased with the game and during the development of the game, the CN producer congratulated us multiple times because of the good game that we were developing and how we created a novel, while also fun and familiar game for TAWOG fans. Also, the target public was happy with the game, having good comments on social media like Youtube gameplays and the TAWOG reddit community, some of them pointing out that this was one of the best TAWOG games on the internet.
New documentation system and stretch goals leading to new tools
The development of these games also permeated in how the different processes worked at Cangrejo Ideas. The new way of documenting and presenting the game permeated to future projects of Cangrejo Ideas, reducing the time of documentation allowing to concentrate more on the content that the form. Also, it enhanced the communication between teams, resulting in more work done in less time and more accurate and updated information about the development.
Also, taking good design decisions to reduce the uncertainty in the game and the constant prototypes allowed Cangrejo Ideas members to increase their knowledge about different tools and workflows, especially for the development team who created amazing tools that allow us as Design team to playtest constantly and having a nice time designing levels and testing new enemies and mechanics.
Knowledge on how to create games for multiple target public
After launching, we could see that our investigation about the multi-target public of TAWOG was not wrong. Many of the most outstanding voices of the community were older than the target public, and they enjoyed the game because of the multi-layers of gameplay that the game offered. The game mechanics were easy to learn, but especially on the last levels of the game, the puzzle-solving abilities of players were put to test in a great manner. This knowledge permeated future projects of Cangrejo Ideas, so there was much more emphasis on the investigation and empathizing phases, allowing us to discern better what are the different public of a specific show and directing the game to most of them, using deep systems and easy to learn mechanics.
Places to improve
As in any project, there are some things that could be improved. In the case of the development of “Darwin’s Yearbook” there was a specific situation which slowed down the development of 1 world (a total of 4 levels). One of the junior designers entered later in the project and we already had a very good grasp on how to create levels and the constraints with respect to specific things, like minimum and maximum ceiling height, width of the corridors, minimum and maximum time expected to finish the level by the player and small but important details like this. But none of these elements were written anywhere, because being a small design team (at that time consisting of 2 designers sitting side to side) there was no need to document it. We explained the rules, but as we discovered later there were a lot of untold rules that we didn’t think at the time. For example, we had elevators that we could use to go in any direction and path, but we chose to only use them for vertical movement. The junior designer used many elevators horizontally, breaking the uniformity of levels. At the end, this resulted in more time invested in that single world, to ensure that all elements were coherent with the defined level design guidelines.
This leads us to create a design guidelines document for future projects, so designers that enter later in the development cycle can start to work with the least amount of friction possible.