:strip_icc()/pic3203424.png)
/pic3160828.jpg)
Part I: Genesis
My first published game, Kosmonauts, received a lot of feedback like "game is cool but where are lasers, guns and other stuff?!". The next one, Labyrinth of the Mirrors, was even more peaceful. The worst thing that you can do in this game to your opponents is snatch valuable treasures right under their noses. (Okay, you might add evil laughing to increase the effect.) Finally, my manliness broke through and I became obsessed with designing a game in which you
I was thinking about the game setting and found that probably the best would be combat between giant anthropomorphic battle robots.
:strip_icc()/pic3203381.jpg)
Early robot concepts
The second idea was to build your own death machine during the game from different modules. Some of them should move your robot, others rotate it, and of course there should be a lot of different deadly weapons. A game turn should consist of activating one of those modules and using its special ability.
Since game balance is extremely important for me, this game balancing was a real challenge. There should be a lot of different weapons, and all of them should be not only cool, but also effective in comparison to one another.
:strip_icc()/pic3203383.png)
Early weapon tile concepts (text in Russian)
All my game design experience tells me that I should start to think about balance even earlier that I start to create specific modules. If a game is balanced on the core level, it will reduce the number of required tests and make development easier and faster.
But what is balance? I have read a lot of definitions of game balance, spent a lot of time thinking about it, and can finally state it in the following way:
Quote:
A game is balanced when every game element has comparable application area in comparison to other game elements of that kind.
"Game elements" are quite broad in conception, including not only cards, units, weapons, building, etc., but also tactics, strategies and even player order. The application area of game elements is the set of game situations in which a particular element is more preferable than all (!) other elements of that kind.Part II: Types
In this game of destruction, you will construct your robot during play, so my goal was to give players real, multi-valued choice of which modules to collect and in which order — but before I started to create modules, I thought about their types and the core mechanisms of the game. There should be at least three types of modules: moving modules, rotating axes, and (naturally) weapons. To balance them, I used irreplaceable abilities technique.
:strip_icc()/pic3203483.png)
Move, turn, and attack modules—early versions (text in Russian)
The idea is that you can provide comparable application area by giving each game element a special function. That function should be not only necessary for the win, but also irreplaceable with other game elements.
So why do robots have to use weapons? Because it is the only way to win. Specifically, the player who destroys the most enemy modules by the end of the game wins.
Why do robots have to use moving parts? First, through movement they will collect new modules. Why is this important? Because the modules that will be collected are more powerful than the starting modules. Moreover, during the game even more powerful modules will appear on the battlefield (which should also give us tension mounting during the game and an epic finale).
Second, movement is essential for the same reason as rotating axes; robots have to be mobile to move and rotate quickly. Without this ability, it will never get a chance to attack opponents. Moreover, a slow robot will be an easy target.
:strip_icc()/pic3203395.png)
Second generation move, turn, and attack modules
So all three module types have to be used and therefore they have to be collected. (If you remember, robots need to replace weak starting modules with more powerful ones.) And the question of which module you should take/use has different answers depending on your chosen strategy, present tactical position, and current robot status. On the basic (or "zero iteration") level, we give to every module type theoretically comparable application area and as a result may think that they are preliminary balanced.
Of course it is only a hypothesis, and of course we need to create specific modules and test them a lot of times to prove it. Moreover, we probably will change some things (or even many of them) in the game after tests. But the fact that we design the core level of the game considering the balance will save us a lot of time because we will make many fewer modifications and adjustments.
I know that most game designers think something like "let's create basis of the game, let's make it work, and after that maybe we will do something with the balance", but all my experience with both my own games and my colleague's games that I have helped to balance tell me that it is a mistake. Usually it is much easier to completely recreate a whole game than to balance it in its current state.
Part III: Comparison
When we are going to create a group of balanced elements, the most obvious way is to use a points system. Every element has the same number of points as all other elements. Points are spent on parameters, so when you make some parameters high, you have to make some others low. Every ability also has a price in points.
As far as I know, this is a quite popular technique, but for this game I had to use another one. As we considered in the first part, game elements are balanced if they have a comparable application area in comparison to other game elements of that kind. So I decided to create a standard for every module type; when I created a new robot module, I immediately compared its application area with the application area of the corresponding standard. If their application areas weren't comparable, I changed the module and compared them again until success.
Sometimes I needed to make a module more powerful than standard, but in this case some negative attribute needed to be added to recoup the balance.
:strip_icc()/pic3203406.png)
For example, both EQUALIZER and O.R.C. are ranged weapons with damage 2, but since O.R.C. is a rocket launcher, I gave it high shot and explosion abilities with one penalty: it is a single-use module. So there are many situations when O.R.C. is preferable, but also sometimes you would like to use your weapon more than once per game.
When all modules of some type was created and basically balanced, I compared them to each other and corrected them if their application areas weren't congruous. Let us consider some examples of mentioned comparison:
:strip_icc()/pic3203400.png)
Dimensional application areas are good for move modules. The tiles to which you can move using the WALKER module are indicated by number 1. CRAB could move your robot to tiles with "2". If you need to jump over an obstacle or enemy robot, FLEA is definitely your choice.
For some cases, it is necessary to analyze the time domain to compare application areas. It is especially important for auto-cooling modules. (Most other modules have to be cooled before their next use; all modules are cooled during a single turn.)
:strip_icc()/pic3203477.png)
In released version, its named CRUSH
:strip_icc()/pic3203417.png)
For example, CRUSH 2 with the auto-cooling ability deals less damage per turn then CRUSH 3, but after the second turn it has better results since it does't need to be cooled. Thus, CRUSH 3 has an application area in one-turn attacks while CRUSH 2 AC is preferable in protracted fighting.
After every module was compared with all other modules of its type (the first iteration of balancing), I compared combinations of modules (the second iteration). In this game, there is no need to compare every combination, but only combinations that have emergence — new properties that appear when you use both modules. Melee weapons, for example, become very effective if you have speed move module.
:strip_icc()/pic3203423.png)
Good combo!
Moreover, the combinations of weapons and enemy armors have to be checked.
Armor modules
In Steel Arena, I did not recalculate the application area of modules after the analysis of their combinations; I found that for this game that I needed only to avoid much too powerful combos, but for some games such recalculation is necessary.
Of course, I used many more techniques to balance the game, but let me finish and not to make a draft on the reader's patience.
Afterword
Using the described approach, you have to spend more time during the creation stage, but that work can save a lot of time later when you test and develop the game. In Steel Arena, I changed just a few modules due to balance problems after dozens of tests. Of course you still have to test the game a lot of times, but during those tests you can focus on the other important things: player interaction, gameplay deepness, replayability, etc.
Yury Yamshchikov
/pic3190468.jpg)
:strip_icc()/pic2796255.jpg)
:strip_icc()/pic3179619.jpg)
:strip_icc()/pic3203743.jpg)
:strip_icc()/pic3197880.jpg)
