Space Patrol: The journey from idea to prototype to final product 

progresssprogresss

Considering that Space Patrol was made within tight budget, short period of time and by a very small team without prior experience in mobile multiplayer games (which lead to splitting my work into game design, level design, UX, creative direction, project management and QA), it is a perfect example of a process that went through many trials and errors and required extreme flexibility on behalf of me and my colleagues so it could land properly on Google Playstore and Appstore.

Along with telling you what went wrong and what went right with the development process, my major purpose on this case study is to give a clearer idea of my input and the important decisions we made in order to transform the client’s initial idea into a playable and marketable product as well as giving you a glimpse into several fragments of the design process.

TRANSLATING THE INVESTOR NEEDS INTO SOMETHING THAT WORKS

schemescheme

One of the biggest problems of this game was that it didn’t involve our input from the scratch and some poor and irreversible decisions were made before we joined the creative process. This cascaded into a series of technical, marketing and design issues and it was up to our team to evade them as elegantly as possible. At the same time this gave us boundaries within which we pushed ourselves towards inventing clever technical and gameplay decisions and played a critical role in shaping the game in its final form. Our intervention resulted in the following changes of the given formula:

GAMEPLAY THAT SITS ON CODEPENDENCY AND COOPERATION

1. Rock Paper Scissors

Taking inspiration from various co-op games (Brawl Stars, Team Fortress 2, Tanks A Lot, Lost Vikings) we realized that cooperation works best when a level of codependency is added in the relationship between the different characters. They can not only help each other in a different way but sometimes nerf a player’s skill so another player’s skill can be buffed. Back when we were designing the game for three different characters it felt natural to implement a rock-paper-scissors mechanic for the skills of each player.

The three players (Pilot, Shooter and Support) had a different primary skill and objective. They were designed with the thought that each player wouldn't be able to perform their primary function without the help of some of the other players. For example: the Pilot can't steer the ship without fuel and the Support can't harvest any fuel if the Pilot doesn't steer the ship towards a fuel source

I designed several different sets of three-character teams with their complementary relationships in mind. Besides their primary function each of the characters has a special skill that they can perform from time to time. Each special skill can help in a certain situation but that always means something else might not function properly. For example: The Shield can produce a SHOCKWAVE that can stun nearby enemies but that will also deactivate the Gun for a while.

Another option for the third player was a Support Robot Hand that can perform different actions as long as they are within reach. This approach required a different set of primary and secondary skills as well as different types of codependent relationship between the players. In this case the SHIELD mechanic was one of the Pilot's special skills. Activating the SHIELD made the Shooter unable to shoot bullets through it.

In the end we decided to ditch the third character and focus on a duo gameplay experience. The Shooter was causing too much chaos and made the game more fast-paced and violent than we wanted. The Support, on the other hand, was too passive and felt like a "dog on a leash". So we decided to take the best out of two and mixed them into what turned out to be the Operator role.

2. Combo System

One of our initial co-op ideas we began prototyping was the combo system. We believed this mechanic would be the key that will transform the game from a team action game into a really cooperative experience and stand out from similar games such as Brawl Stars and Tanks A Lot. On top of having two totally different characters with their own unique special skill we implemented a combo system which allowed the players to combine their special skills into a powerful combo skill.

We had two buttons in our HUD - one for primary and one for secondary action. We definitely didn't want to add a third button for a combo action. So our solution was: if the two players performed their special skill at the same time a combo action was performed by both of them. Thus we gave the player a sense of coordination (both players should be involved) and agency (one of the players might disagree and not contribute to the combo). We wanted this to feel like a natural bond between the two players' special skills. Thus, each combo was thought as a mix between the two special skills performed. For example, The Pilot's DASH and the Operator's MAGNETIC SHIELD produce a powerful MAGNETIC DASH that makes the Pilot invincible and can cause damage to enemies.

When players progress through the game they can purchase different Ships and Vacuum Guns (correspondingly for the Pilot and the Operator role). We split all these ships and guns into three categories (thermal, electromagnetic and nuclear). Each of them had a different special skill so that players can choose a different build of Ship+Gun and plan a different approach for a level. This meant that different sets of Ship+Gun will produce a different combo skill  and greatly enhanced the tactical possibilities, especially in PvP modes.

3. PvP or PvE

We started prototyping the core mechanics of the game with PvP in mind as the more safe and trendy direction for multiplayer gaming. It was also fitting our budget better because we realized that it will be better to invest several months into prototyping nice and simple PvP modes instead of creating tons of PvE levels. Unfortunately, the client insisted the game should have a more explorational context and feared that PvP arenas would be too competitive and violent. We had to revise our mechanics and put them into a PvE environment. We had to cut many features that suited the PvP better and focus on simpler gameplay with more variety in the art, story and level design. Our best intentions were towards designing gameplay mechanics which would nicely fit into a variety of PvP and PvE modes (racing,  survival, deathmatch, tower defence, interstellar soccer, exploration, hold the ground, capture the flag and many more). Here are some of those that had more potential:  

EXPLORATION:  This PvE mode turned out to be our most used approach for the final game (and what the client liked the most). We made open and free-roaming levels as well as more linear and labyrinth-like ones. In each of them the players' goal was to gather resources, defend the Ship from obstacles and enemies and eventually reach the final destination within three minutes. We built our whole campaign mode and focused all the narrative into these exploration levels.

TOWER DEFENSE: One of our first desires with PvE in mind was to construct PvE arenas, so the tower defense was a logical direction. The main goal was that the Home Base had to survive for three minutes during constant enemy attack. This mode also gave purpose for our former third role: The Support (acting as a Robotic Hand in this case). He was able to: 1. repair four friendly Cannons with the Hand; 2. Attach the Hand to Energy Stations and harvest Energy (everybody's resource for actions). This made the gameplay constantly switching between staying close to defend the base and going far away to gather Energy. Sadly the mode turned out to be too complicated for 10-year-olds, so we ditched it. 

INTERSTELLAR SOCCER: This was one of the first prototype modes that turned out to be really fun right from the scratch. This really gave us the inspiration that PvP was the right direction (thus, we somehow preserved this mode in the final game). It was competitive and not violent at the same time and we received quite positive feedback from the kids who tested it. Taking inspiration from games such as Pyre and Rocket League, we took our Pilot and Operator with all their action skills and gave them a ball to kick around. For the sake of consistency and because we liked the ball idea so much, we implemented it as a major mechanic in all other game modes.

HOLD THE GROUND: When we decided that we're keeping the ball (and named it O.R.B.), I began prototyping different modes with it. One of the better results was inspired from the game Push Me Pull You and we made both ships compete for the ball and try to hold it in the center Zone and gain Influence. With balancing tricks and negative feedback loops such as shrinking the Zone for the winning team we produced a potentially fun mode, good enough for a stand alone game. Due to the PvE approach, sadly, it didn't make it into the final game.

DESIGNING O.R.B (our hidden third player)

When we headed towards exploration PvE levels and implemented the ball (O.R.B.) into the core mechanics we wanted to give it multipurpose: we wanted players to be able to attack with it, defend with it, unlock doors, solve puzzles etc. We wanted O.R.B. to be as significant and emblematic as God of War’s throwing axe or Half-Life's  gravity gun. We also needed to add something like a sidekick, your own little R2D2, following you everywhere on your adventure. So we kind of put it all into O.R.B.

There was a major problem without a simple solution, nevertheless. We were making a two-button game and our Operator (and its vacuum gun) already had its two buttons assigned.  Button 1 was for sucking resources as well as pulling and throwing any objects that were small enough. Button 2 was the special skill. We liked the idea of a "boomerang" mechanic where you shoot the ball and then call it back with the vacuum gun. Throwing the ball with Button 1 was obvious. But we had a really tough time figuring out how to possess the ball again without adding a third button and without backtracking and chasing the ball every time it went out of reach. 

1. O.R.B. is always near you

One of the options that stuck till the very end was having O.R.B. in your "hands" or within reach all of the time.

You throw O.R.B. with Button 1 and then use your released vacuum gun to gather resources. After crossing a certain distance (shown with radius = rO.R.B. is automatically teleported back to you. For better or worse this is what we chose in the end.

  • + almost instant access
  • + practically you have a gun
  • - no decision making
  • - no penalties for getting the O.R.B.

O.R.B. is chained to your vacuum gun like a flail or a wrecking ball. You shoot it and pull it back with a single button and your leash has a limited range.

  • + physics can produce fun gameplay 
  • + automatic "pull back" system
  • + intuitive
  • - not clear how and when you gather resources
  • - can't make long distance shots

There are lots of O.R.B.s in the level. Ddifferent sub-options introduced various O.R.B. sources: they can be harvested from destroying minerals, spawned from designated slots or just flying around. You just need to find them. 

  • + no need of produce/return O.R.B mechanics
  • + increases the purpose of looting
  • + can implement "unstable" O.R.B.s mechanics
  • - no decision making
  • - how do you break a mineral without O.R.B.? 

2. O.R.B returns to you

Another set of approaches was making O.R.B. return to you by itself

The true boomerang option: O.R.B. automatically returns to the ship when "out of reach" (leaving the zone with radius = r).

  • + boomerang mechanics are fun
  • + even more fun when you add gravity fields
  • + gives space for dexterity/accuracy learning curve
  • - colliders could be a huge problem
  • - might be hard to catch the returning O.R.B. 
  • - O.R.B. can practically get stuck somewhere

When it's not loaded onto your vacuum gun, O.R.B. is just following you everywhere like a dog on a leash.

  • + O.R.B. feels like a true sidekick
  • + no backtracking
  • - needs a pathfinding system
  • - still needs a return system if you shoot O.R.B. too far away

3. You manufacture O.R.B 

There were also lots of options where instead of finding or calling back O.R.B. you just manufacture a new one.

When you collect five mini orbs they automatically create a new O.R.B. loaded on your vacuum gun and ready to be shot.

  • + enhances the Pull/Gather mechanics of Operator
  • + gameplay becomes more choice driven
  • + easy and intuitive
  • - you are able to create an O.R.B. without wanting to
  • - there's too much time of "not having an O.R.B." 

You spend the resources that you gathered (usually used for upgrades and new gear) during gameplay to create a new O.R.B.

  • + nice decision making mechanics
  • + different playstyles
  • - extra button for spending currency during gameplay

There are factory stations that can build a new O.R.B. You will need to bring a mineral in order to manufacture an O.R.B. there.

  • + more diverse gameplay
  • + easy to balance with putting more/less factories
  • - can result in a slower level progress
  • - can get stuck (minerals are harvested with an O.R.B.)

Or instead of a mineral just go with your ship to a factory and wait there for several seconds to get a new O.R.B.

  • + faster version of the option above
  • - still have the same problems
  • - still can have a slow level progress

4. You create O.R.B. via the other player

There were also options that required cooperation between the players in order to produce an O.R.B.

There is a feature in the game called Selfless Act where one of the players is willingly unable to move while the other player gets a buff out of it. In the Operator's case this buff is a new O.R.B.

  • + stimulates co-op gameplay
  • + Selfless Act is a fun mechanic
  • - If Pilot is a troll, Operator might never get a new O.R.B.
  • - Unequal  and unbalanced Selfless Acts for the two players

One of the players donates their energy so the other player could perform something (such as creating a new O.R.B. for the Operator and a speed boost for the Pilot)  

  • + stimulates co-op gameplay
  • + even more selfless
  • - gameplay can still be broken by a trolling teammate

The Operator can gather fuel for the Pilot, while the Pilot can gather mini orbs for the creation of a new O.R.B. 

  • + stimulates co-op gameplay
  • + equal responsibility for the other player
  • - too risky to put it as a major mechanic