The Gamasutra Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features 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, including creating the gorgeous voxel creatures of Fugl, designing the  UI for VR strategy game Skyworld, building an adaptive tech tree in Dawn of Man, and achieving seamless branching in Watch Dogs 2’s Invasion of Privacy missions.

Who: Johnathon Moss and Timothy Neville -- co-founders of two-person indie developer Burnt Bag Studios.

Johnathon here. First off, a little about us. Tim and I founded Burnt Bag Studios around 18 months ago. Coming from Marketing (myself) and Accounting (Tim) backgrounds, neither of us had any formal education in the skills and/knowledge required to make a video game. After diving headfirst into the unknowns of game development and brushing up on our skills for around 6 months, we decided to take the plunge and work on our first game Emergency Water Landing (EWL) full time. 12 months later we were happy to announce our release of EWL on Steam and Xbox. 

The story behind the name - As childhood friends growing up through the 90’s, Tim and I spent countless hours playing games together. We wanted our studio name to be a throwback to those days we spent furiously mashing away on buttons, breaking thumb-sticks and letting loose every possible combination of dirty words we could think up. 

Early one frosty morning, all snug in our sleeping bags while having a group play session of The Legend of Zelda: Ocarina of Time, a burning smell started to fill the air in the room. It turned out a 12 year old Tim had been sitting a little too close to the heater and his sleeping bad had caught on fire. After rolling around madly for a few seconds followed by an uncontrollable bout of hysterical laughter, everyone was ok (except for the sleeping bag) and a story to inspire a studio name was born.

What: Frenetic local multiplayer design in Emergency Water Landing

Emergency Water Landing is a local multiplayer game inspired by the aesthetics of a flight safety card, where players control high powered rescue rafts and fight to save the most passengers. Players pick up passengers from the water, or ram into other players in order to steal their passengers. To save passengers, and score points, they launch their passengers into a rescue boat that circles the area.

Players can also pick up and launch floating debris at opponents either to steal their passengers, or strategically prevent them from scoring. The game plays in fast paced 3 minute rounds, with player rafts deploying as the plane comes crashing down into the water. The player who has rescued the most passengers is the winner.

Our primary design goal was to have the gameplay feel fast paced and frenetic, with simple controls so that anyone could pick it up quickly and bring out their competitive spirit. We had grown up playing games like Mario Party and Bomberman 64, and wanted EWL to deliver a similar experience, with players gathered around the TV shouting at each other and getting competitive.

We wanted the visuals to reflect a flight safety card with it’s crisp outlines and flat shaded colors, so the initial prototype began with a basic toon outline shader,  and scene camera angled down from high above, with a crashed plane in the center, and the player controlled rafts all on screen at the same time.

This "safety card-esque" camera angle was the first constraint on how the gameplay was developed. On the one hand it was a positive constraint, as it allowed us to write a simple camera controller that stayed relatively static, only needing to pan and zoom to ensure all players were visible on screen. On the other hand, it meant we had to limit the play area quite tightly around the plane so the camera didn’t zoom too far out making everything appear tiny amid a literal ocean of water.

The obvious first step was to add barriers to keep players contained, so we added floating rope buoys around the perimeter, courtesy of Unity’s Hinge Joints, which were easy to setup and provide a nice sense of flex and rebound when players run into them. Now that we had players were contained, we had to work out how to keep them moving around the space without feeling too claustrophobic.

We had played around with the idea of the plane breaking apart on impact at the start of the game which allowed plenty of space to maneuver around, but that meant an abundance of passengers all at once, and during play testing it ended up as a total free for all, with players swarming on passengers like piranhas. It scored well in the LOL department, but we wanted to encourage more strategy and create situations where players would give chase, fighting tooth and nail to rescue those passengers.

So we decided to keep the plane intact throughout the round, until the final stages when it cracks apart, spilling out passengers as it sinks into the ocean. This led our attention to how each round was paced, and we began playing around with the rate at which passengers were “dispensed” from the plane. We wanted the right amount of scarcity to cause players to have to fight over passengers and get creative in their maneuvers, while ensuring there were always some passengers evacuating from the plane.

To achieve this, we created an object pooling system that would instantiate a certain amount of passengers per player at the start of the round, and dispense them at random intervals between 1-3 seconds, at a random door or window exit of the plane. As a passenger gets rescued, it goes back into the object pool and is added to the respawn queue, unless the plane breaks apart in which case it will spawn all passengers up to the maximum, inside of the aircraft cabin, and no further passengers are spawned. I think we ended up with about 20 passengers per player + a static number of pilots and crew.

To keep players moving around the plane, we then looked at the rescue boat and how it’s path affected players activity. In early prototypes it simply moved around the area in a clockwise fashion based on a small number of waypoints. This became very predictable for players, and their encounters with each other always tended to be a similar distance from plane, leading to a lack of variability in how they moved around the map.

To resolve this, we created a simple node based pathing system and setup several interesting paths for the rescue boat at varying distance from the plane. The rescue boat will move along a path in a random direction, and once completed will randomly select another path and switch to it. We did intend on having the paths randomly generate at runtime, but the variability we achieved was enough that we could direct our attention to more import areas of the game.

Another factor in how players would interact with each other and the world was in the predator’s behaviour. We added predators, such as the great white shark, very early in development and played around a lot with their behaviour to make them feel alive and a part of the environment. Our goal was to have the predators keep players on their toes without appearing to specifically target player rafts in a way that felt contrived.

Under the hood they use Unity’s Navmesh Agent system for path finding and navigation, along with physics overlap sphere to find passengers and player rafts. Initially predators had no preference between eating passengers and attacking rafts, so they ended up staying quite close to the plane to ensure a quick meal. We wanted predators to be in a position to interrupt players as they were on their way to the rescue boat with a haul of passengers, so we added a dynamic waypoint system to the predator AI.

The predator AI is quite a simple implementation, with the predator going between a patrol state, pursuit state and attack state, with a cool down timer after the attack state. Following an attack state, the system creates a waypoint between the plane and the rescue boat, with a randomized distance and offset, which causes the predators to move away from the plane, toward the rescue boat. To add variety we added a unique predator for each level, with the Orca whale in the arctic level being the most effective at interjecting on players rescue plans.

The final piece of the puzzle was the passengers and the part they play in the core gameplay loop. To keep with the fast paced rhythm of the game, passengers are instantly placed in player rafts when collided with, rather than requiring a button press or animation sequence to play out. When a player raft is rammed into by an opponent, passengers are ejected in the opposite direction of impact, meaning their trajectory is toward the player who did the ramming.

With regard to saving passengers and scoring points when launching them into the rescue boat, we spent some time and iteration to get this feeling good. In early prototypes, all passengers in the raft were launched out at once, with the goal being to keep action fast paced. Though we iterated on this several times, players found it hard to aim and would often miss the rescue boat entirely, as they couldn’t reliably anticipate the trajectory of the passengers ahead of time.

One alternative idea for the saving passengers mechanic, was to have the player raft move alongside the rescue boat and slowly offload their passengers. We had hoped this would create a sense of tension as they tried to save their passengers, while giving other players the opportunity to interrupt them scoring. It turned out to be more of an annoyance however, making it difficult for anyone to score when multiple rafts were attempting to offload their passengers, while also ramming each other at close range.

We instead reverted to players launching passengers into the rescue boat, but instead, one at a time per trigger press giving it an almost machine gun like quality. This gave players a sense of the trajectory of their passengers, encouraging them to launch from a distance, without the risk of launching all their passengers on a bad vector. In combination with each raft’s boost ability, players can execute some exciting forward planning, boosting just out of the path of an opponent to score over the top of another.

Result: Frantic and fast-paced local multiplayer action

Overall, we ended up quite happy with the result and how the game plays. Especially when there are four competitive players gathered around the TV. We feel the game achieves the frantic fast paced action we set out to accomplish. There’s always plenty of laughter and the game really brings out the competitive nature in players.

For our next project, we would definitely make more time available for play testing. Although we did do some limited play testing with mostly friends and family, we feel the game would of benefited from receiving more feedback and iteration to help achieve a more polished outcome. When you’re a small team responsible for all art, animations, sounds, music, design and programming it’s easy for such an important aspect to become neglected.

We also had a lot more content we would like to of added to the game before launch for example, additional levels, AI opponents, more games modes. However, we decided it was more important to find a balance between content and shipping the game on time.