How we balanced more than 150 weapons-spaceships combinations in In Space We Brawl
When we first started thinking about In Space We Brawl we were amazed by the possibilities that jumped to our minds. If you’re planning on developing a twin-stick shooter with various vehicles and weapons the only limit is your imagination. Well, and balance of course.
First you think about the basics like a shotgun, a flamethrower, a fast ship, a more tanky one, and then more and more crazy things start appearing in the design discussions. What about a laser sword, or an organic spaceship that regains life overtime? And doesn’t a magnetic slingshot that uses asteroids as projectiles sounds completely amazing? Of course it does, but when you end up with 13 ships and 14 weapons, things can become a little messy.
As you probably already know, the best way to check if your game is balanced is to throw at it hundreds of hours of play testing, and then do it again, and again until everything runs smoothly and no one complains about weapons being overpowered or ships being too fragile. This is the best case scenario, but you also probably know that independent studios usually don’t have thousands of hours at their disposal, and need to keep a tight schedule. Here’s how we faced this issue, and more importantly how we resolved it: we are happy to introduce you our Street Play Testing!
Here’s a small video that shows how much fun we had while touring with In Space We Brawl.
As soon as we had a decent build, we decided to take In Space We Brawl with us on the streets of Milan, Turin and Florence in Italy, to share our projects with all kind of players and learn the most precious feedback (and have a good time in the process).
We played, played, and played some more with hundreds of people, learning from them, watching their play styles and learning new things that even us as developers didn’t know about our game. It was an amazing, fun, social experience that also had great value from a design point of view. There’s nothing better than a bunch of strangers testing your game in a friendly and partying environment, well, at least this is the best way if your game is a couch multiplayer twin-stick shooter!
Thanks to our Street Play Testing (and hundreds of hours of incisive internal play time) we were able to release the game with hardly any balance issue: we already have found the overpowered combinations, and levelled everything making sure that even with the craziest of them it’s possible to achieve great results with the right hands.
Now that In Space We Brawl is available on PlayStation 3, PlayStation 4, Mac and PC, we finally have technology on our side: thanks to various analytic tools we can collect detailed data on player behaviours, and actively intervene to rebalance any misequilibium that may occur.
We look closely at data like the most played ship or the one that survives the longer, and cross the results with our weapon analysis to discover which are the most played combinations, and which are the most successful. This way we are able to tweak small parameters of weapons and ships by acting on an XML file that gives us total control. All this without asking the players to download any patch.
Using data from spaceships and weapons usage we are able to tweak the parameters to keep every combination balanced.
This type of analysis is useful if you plan, as you normally do, to add more content to your game without altering the balance. Thanks to our continuous monitoring (and thanks to the ease with which we can alter parameters) we are able to enrich the game with weapons and ships invented many months after the initial release.
Obviously internal play testing remains crucial, we’ve spent many hours playing every newly added item, but on the long run there are some issues that only a continuous monitoring of players activity can reveal.
In our experience mixing data analysis with human play testing worked very well: the feedback that a total stranger can give you after playing your game with his friends on the streets is priceless, but works well only if paired with a more traditional approach (and of course only if you’re developing a compatible genre of game).
We also learned that designing an easy way to modify your game will save you hours of work (and headaches) when you’ll need to alter somethings, and everyone knows that moment will eventually come.