Game Design Deep Dive is an ongoing Gamasutra series with the goal of shedding light on specific design features or mechanics within a video game, in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.
Check out earlier installments on the the action-based RPG battles in Undertale, situational awareness and player frustration in GRIP, and the capital ship invasions in Dead Star.
Also, dig into our ever-growing Deep Dive archive for developer-minded features on everything from rocket jumping in Rocket League to Dying Light’s Natural Movement System.
I am a games designer with 10 years experience in the industry. I used to work at Frontier Developments with Oli De-Vine but we left at the beginning of last year to start our own studio. Our first project is a cooperative cooking game called Overcooked which released on August 3rd for Xbox One, Playstation 4 and Windows PC.
A lot of games seem to add ‘co-op mode’ as an afterthought. We’d played lots of games where co-op simply meant two avatars and twice as many enemies, and they almost always devolved into a race to see who could kill the next enemy or grab the next loot drop.
With Overcooked we wanted to make a game where cooperation was a central pillar, a game which was much more focused on how a team works together rather than simply adding more players to a single player experience.
I want to talk through the development process for the game, calling out some of the key decisions we made and the challenges we faced developing a game which actually required players to cooperate.
When we started the project, before we had landed on the concept of a kitchen or of cooking, we knew we wanted to make the game about cooperation. There are lots of games which allow players to work as a team, but more-often-than-not the focus is on the skills and abilities of the individuals rather than how good the team is at communicating or coordinating their behavior.
I’ve worked in various restaurants over the years, earned my stripes pot washing and bussing tables, and kitchens have always struck me as a perfect analogy for a cooperative game: an occupation where teamwork, time management, spatial awareness and shouting are all vitally important 🙂
But how do you encourage players to work together? And how do you make that a fun experience?
Prototype: cooperation is about realizing you can achieve much more as a team than you ever could on your own. As in a real kitchen, time is one of the most important elements in our game we have to play with. The premise is simple: you have to try and deliver orders as quickly as you can or you risk upsetting your customers. You can choose to perform all actions yourself but you quickly learn that by sharing the workload you can drastically reduce the time it takes to achieve your goal. It’s a very simple metric which players are always quick to pick up on: Many hands make light work.
So our initial prototypes focused on the most basic example of this we could think of: Players were challenged to pick up an ingredient, take it to a chopping board, add it to a plate and then serve. If they served the dish before the time ran out, they wouldn’t lose a life.
As a player, when you started the level you had a choice, you could either carry the ingredient all the way around a central divide or you could save time by passing it across the counter so your team mate could chop it for you. It’s extremely simple but in many ways that example is at the Centre of our game’s design.
We kept the controls deliberately simple: 1 button to pick up, 1 button to interact and a thumbstick to move. We discussed giving chefs different stats: chefs who were faster at chopping or chefs who could move more quickly, but again we wanted the game to be more about how a team works together so we decided to keep all players on a level playing field.
We created a handful of different kitchen layouts which played on this very simple idea of cooperation, levels with corridors that only 1 person at a time could fit down, levels which required players to relay ingredients between 3 or 4 players. It was instantly rewarding and player’s picked up the basics really quickly, but we also found they would (after a brief period of discussion) fall into familiar roles and comfortably complete a level simply by performing the same action on repeat until the end of the level. After the initial flurry of activity and communication players would start to settle, cooperation became fairly rote and cooperation unspoken.
We tried several different ideas to address this, but these were the 3 most important changes we made:
- Firstly we made sure there were generally always more actions to perform than players available. Players had to retrieve ingredients, prepare them, cook them as well as cleaning the dirty dishes. This instantly meant players couldn’t simply perform one action for the whole level, they would have to split their time between the available actions and communicate to make sure everyone was on top of the different tasks.
- Secondly we added delays: when ingredient were added to a pot, when plates were sent out to the restaurants, in order to avoid wasting time players would need to busy themselves with other tasks while they waited for their soup to cook or the dirty plates to return to the kitchen. This added a simple element of risk: stay with the pot, or start preparing for the next order and risk the pot catching fire.
- Thirdly and most crucially, we experimented with adding disruptions: events which would change the rules midway through a level forcing players to rethink their strategy and importantly, to communicate.
Disruptions: This last point was a defining moment for the game’s design. We quickly realized that players enjoyed having to think on their feet and respond to the changing levels. We added a level on board a ship here the counters would slide and change the layout of the kitchen, we built a level which would be torn apart by an earthquake leaving players temporarily separated from one another, we added rats, floating counter tops, even moving ice floes. Suddenly players were having to really concentrate on what every member of the team was doing and stay in constant communication in order to stay on top of the chaos, more than that they were also being forced to change their roles midway through a round: it’s hard to remain in control of the chopping when the chopping board has suddenly slid to the other side of the kitchen!
One of the more dynamic Overcooked levels set on a pirate ship.
We built up an arsenal of new levels and then yet again went back to playtesting the game with friends and at various conventions to see how they got on. We found the game had greatly improved, players were engaging a lot more, there was a lot more communication and people were just generally enjoying themselves. We felt a lot more confident with the direction the game was taking but there were a number of issues we still had to address which challenged the goal of the project. I want to just go through some of the key issues now to give a sense of how we adapted the game for team play:
Scoring: Our original take on the game gave the players 3 lives and would deduct a life every time the player failed to deliver an order in time. It was a fairly simple system, we’d gradually ramp up the number of orders and the players had to stem the tide for as long as they could, but there was a general sense from players that they were constantly failing and that they were just doing their best to prolong the round which detracted from their sense of unity.
To counter this we made a fairly big change to scoring and instead gave the player a time limit within which to serve as many orders as possible. Player’s could still fail orders, but they instead incurred a minor deduction in score. It made the game much more fun and allowed players more breathing room to think about their actions and coordinate themselves with their teammates.
Freedom and restriction: We focused a lot of our attention during the bulk of our development on this aspect of the game. The original prototypes we built gave the player much more freedom to make mistakes. Players were required to communicate a lot more information to each other, which was great, but there was also a lot of room for players to make silly errors or to forget what stage in the process they were up to.
Case in Point: Originally players were given no indication of the contents of a pot. Players were required to communicate clearly or risk getting an order wrong:
“What’s in this one?”
“Erm… I think I’ve put 3 onions in that one!”
“Oh… I think I might have just added a tomato by mistake…”
On the plus side this required a lot of communication between the team, but it often lead to a lot of frustration particularly when coupled with the additional gameplay factors to keep track of.
So we spent some time balancing how much freedom to give the player. We restricted the number of items you could add to the pot, and we added item icons so players could track the contents of each meal. We stopped players from being able to add unprepared ingredients to a soup or to a burger and we replaced our word-based interface with an iconographic approach. We were constantly checking and balancing to ensure player’s still had to communicate but didn’t feel too frustrated if they made a mistake.
Playtesting the game with students at Anglia Ruskin University.
Players could suddenly focus much more on cooperating and weren’t constantly worried about making a simple mistake that might cost them the round.
Level Design: Every new level we created we would always work backwards from the experience we wanted the players to have. We’d try to think of unique situations which would create interesting and unique cooperative experience: What if the player’s were separated and had to pass ingredients using a conveyor belt? What if players had to open doors for one another? What if the cooking stations moved around? What if you had to ferry ingredients between kitchens using a space shuttle.
We went through this cycle of building a level, playtesting it with users and then adapting and tweaking to ensure we were always staying on the right side of fun and frustration, making sure players were challenged but didn’t feel completely overwhelmed
Even if on the surface, the game is about cooking with your friends. Ultimately we wanted to create a game which was much more about getting friends and family to work together.
Having a central pillar to always look to was extremely useful on the project, it was a filter through which we could run any new idea and against which we could measure any feature (even the van you control on the game’s world map is controlled by all players simultaneously).
Watching people play the game over the past few weeks on YouTube, getting to see and hear their reaction has been a truly rewarding experiences. Watching a team of friends fall apart, reassess and then work together to conquer each new level together is always exhilarating for us.
There are team’s who communicate well and manage to stay on top of the chaos and then there are team’s who communicate… less well and you start to see their inner Gordon Ramsay reveal itself…
We’re particularly proud when we hear about families playing the game together, or people playing the game with their friends or relatives who have never even picked up a controller before. cooperation is a concept everyone is familiar with and we’re extremely pleased that we could provide a game which allows players of all ages/abilities to play together.