It’s been a while since the last blog and unfortunately development hasn’t progressed as much as I would have liked. So, this week I’d like to try and give you all an insight into what it’s like designing and “balancing” a game a part of a game. Last time I mentioned that I was hoping to implement the match engine so that seems like the best part to talk to you about.
If you’ve missed any of the blogs then the “match engine” is basically the part of our game that plays out a match between two teams. I’m not talking about any graphical stuff here, just the code that determines who does what and when and therefore what happens during a match. Brutalball – working title, but this is about to change! – is a game we made up that is a cross between football, handball, and rugby, played by teams of six players.
Sounds easy, right? All you do is load the two teams’ player data into memory and then run some code that uses that data to determine passes and tackles, shots and goals. Couldn’t be simpler. And, at that level, it is that simple. However, anyone who has designed a game will know that the issue of game balance will rear its head and things get a lot less simple than you might expect. As our game is in effect a simulation of a physical game, I’ll use football as an example to help explain how balancing works.
In the real world there is no balancing: When Messi steps onto the pitch he may or may not play well. In a video game he’d play well every game. It’s as if the players are robots. This presents a problem, because it means that if you can populate your team with enough Messis you will win every game. In other words, the game needs balancing such that how stats are interpreted and used to generate results doesn’t make matches too predictable.
The first idea that springs to mind is to add an element of randomness. For example, when calculating whether a pass is successful or not, I’d add randomness that maybe flips the result on occasion. This would mean that stats would directly determine outcomes and then a little randomness may occasionally throw a spanner in the works. Given that a better player is going to make more successful passes, it also means that the random flip is more likely to change success into failure. Vice versa with less skilled players.
Even with that change in place it would still need balancing of its own, because if not handled correctly it may result in outcomes drifting towards the same success rate no matter a player’s skill. And what about those games where Messi doesn’t make a bad pass and everything he touches turns to gold? How would that be implemented if a randomness element is involved?
The only way to balance all these things – and there are many more to consider, such as the concept of “match momentum”, player fitness and morale and so on – is to implement and test, test, test. It’s the part that I am most looking forward to as it’s the real meat of the game and is a big development milestone. There is a danger that I’ll get stuck just playtesting, but if I do then it must mean the game is insanely playable, and that can only be a good thing.
Talking of testing, we now have a beta test group setup with a few people who are going to help us test this beasty. If you’re following us on Twitter – @Husky_Games – you’ll know that our beta group isn’t complete yet. We’ll be adding to it as development progresses so that we’ve got a mix of people who know the game inside-out, and people who are new to the game to give fresh perspectives. If you’re interested in getting in on the beta testing make sure you keep reading this blog, and follow us on Twitter, as we’ll announce recruitment drives in those places.
As always, we’d like to say thank you to the team over at anscamobile for their support with this project. They do an amazing job with Corona, really listening to and engaging with the community of developers they’ve built up. That community is also a great resource and has helped us out on a number of occasions when developing the game.