Original post by Wai There is something missing in the presented method...
That problem is that I had a cost in addition to the value of the unit. If I had simply left it as c = 10v, then I'd have a correct system (but also a very odd one, if you were being paid to have units). It's probable that balance equations need some other modifier, or rather, they can only express ratios. Basically, I messed up on the formula. A unit that is worth 5 times as much value as another should cost 5 times as much. However, i'm not sure about the specifics of going about this with negatives. No matter how many times you times -1 by, you will never get 5. I expressed it wrong. Perhaps it is absolutely necessary to give every unit a positive value that you expect the player to pay for.
A unit that is worth 5 times as much value as another should cost 5 times as much.
This would be fine if you could compute the worth, but I think there is a fundamental problem in how the worth is computed in the method:
Suppose there are three unit types:
1 Hero = 10 Soldiers = 1000 Bunnies
Conceptually, you would assign the costs like this: Bunny = $1 Soldier = $100 Hero = $1000
There are different types of matrices you could use. Suppose you use a ratio matrix such that (row,col)=n means 1 unit of ROW can cancel n units of COL.
H S BHero 1 10 1000Soldier 0.1 1 100Bunny 0.001 0.01 1
In your original method, you would sum the values of each row. The sums are:
Hero = 1011 Soldier = 101.1 Bunny = 1.011
The ratio between them is indeed 1, 100, 1000.
Your 5-unit example (some ratios change due to nasty decimals):
A S H C P TOTALArcher 1 4 0.25 0.2 2 7.45Sword 0.25 1 2 0.25 0.5 4.00Horse 4 0.5 1 1 4 10.50Cannon 5 4 1 1 0.5 11.50Private 0.5 2 0.25 2 1 5.75
Do the TOTAL numbers have a meaning? Suppose Cannon is an unquestionable counter to Horses, such that the table is like this:
A S H C P TOTALArcher 1 4 0.25 0.2 2 7.45Sword 0.25 1 2 0.25 0.5 4.00Horse 4 0.5 1 0.01 4 9.51Cannon 5 4 100 1 0.5 110.50Private 0.5 2 0.25 2 1 5.75
According to this table, although a Cannon can kill 100 Horses, it only costs 10 times as much. What is the meaning of the row sums?
I think it would be helpful to understand why RPS works so well...
Simply put 1 can not move on the other without fear of retribution of the third...
if we say...A = 15/10 (offense/defense), B and C both equal the same as A...
What happens if A attacks B? A and B are left with 5/0 assumedly. If C attacks they win.
What happens if A allies with B and they attack C? One must attach first and since both unless stupid are going to want the other to go first, they won't attack because it leaves them open meaning C is protected or one of the allies with turn and destroy the other.
In other words A, B, and C are all in a position where any action they take will most likely destroy them so they are left to wait till one of the other 2 make a move militarily.
So...how then do we win? The ability to change the balance through the acquisition of more defense or attack, usually meaning gathering and building of materials and speeding up the productivity of our nation Or the slowing down of productivity of another nation.
So really an RTS is not really about the game being balanced, but rather the ability to control the balance.
While the rock-paper scissors method some mentioned here is one of the most straightforward ways to go about it ... and has been done in many games ...
It should be noted that there are many RTS players who fervently despise RPS balance systems and will not even touch a game which employs it.
Personally, it's not my favorite method but it does do the trick and requires less effort than the alternatives. If you choose to go with a RPS system, just be sure to implement it well, and in a believable way.
While the rock-paper scissors method some mentioned here is one of the most straightforward ways to go about it ... and has been done in many games ...
It should be noted that there are many RTS players who fervently despise RPS balance systems and will not even touch a game which employs it.
Personally, it's not my favorite method but it does do the trick and requires less effort than the alternatives. If you choose to go with a RPS system just be sure to implement it well ... and in a believable way.
RPS is the poor man's game design in this case. It's admirable to start from abstract gameplay and attempt to build content around it, but when that initial abstraction is a very tired and trivial concept it's not really worthwhile. RPS is really one way to express the concept of using the right tool for the job, and what you need to do is provide a range of tools that the player can choose from, each of which with a distinct purpose and applicability.
In this case I would come at it from the other direction: look at your game setting and fiction and sketch out a handful of units you'd like to have. Pick arbitrary stats that make sense to you first. Then calculate damage-per-second rates for your combat units to get an idea of their relative potency, and apply the damage-per-second calculations to the toughness of other units to see how long a battle between them would last, who would win, and by how much.
From here you can adjust balance to taste: - scale rate of fire, damage per hit, or toughness/hit-points somewhat to strengthen or weaken units where necessary; - add secondary benefits to make weak units more useful (eg. increased speed, decreased construction cost or time, area-of-effect attack, regenerates over time); - add secondary limitations to make strong units less overpowered (eg. slow movement, weak armour at rear, no defence against aerial attack, requires structure or tech level to construct); - add new units, structures, or abilities that compensate for any features that remain unbalanced due to the game fiction requiring them.
Another aspect that is worth measuring is a player's overall damage-per-second over time. If a $100 unit deals exactly half the damage of a $200 unit but also takes half the time to construct, then you'll be better off constructing 2 of the $100 units, as the first unit can be up and dealing damage earlier. Generally you'd want to skew this slightly so that there is a potential gain to be made from waiting longer for the more powerful unit, thus providing the player with an interesting choice of strategy and their opponent with a potential counter-strategy.
RPS is a good way to understand basic fundamentals of RTS balance, but it only scratches the surface. What type of RTS do you plan to make? If one based on history or modern military RPS may be fine, but it has that 'been-there-done-that' feel to the game-play and still requires more input than basic attack(or damage per shot) vs. HP.
Really, it comes down to what you want in your game. I'm a novice designer working on a Sci-Fi, squad based RTS with interchangeable weapons. This has proved a real biatch; but a very rewarding experience. I decided the best way to accomplish balance in my game was by separating unit stats from weapon stats. Example:
Here you can see a lot more goes into balancing than just attack, and thats just one race's weapon stats excluding the unit factors such as LOS, speed and Hit points, cost- All of which have to be calculated through your own formula.
The more options you include, the harder the challenge to design. But, you should really look at your target audience and ask what will be fun for them. If you want a webbased RTS simpler may be better.
The way I used to balance units is to compute the price of a unit based on its stats. I have a cost per weapon, per HP, per reactive strength, per energy capacity, and per speed. For each unit, I add up the features cost to get the price of the unit.
I balance the equation using a few benchmark units. Once those are balanced, I assume that the equation is correct, and would only adjust the weapon costs.
So if everything else is the same a space cruiser that has two cannons instead of one would be more expensive by the cost of that extra cannon. I don't run simulations to see how many fighters of each other class would need to take out a unit. That method has a fundamental flaw, because some of the units I had cannot attack. (such as a shield generator). A standalone shield generator would cost much less than mounting a shield generator to a vessel, because a standalone shield generator can move, and has its own HP and reactor. Whereas if you mount a generator to a vessel, you could reuse the reactor mobility, and protection of the vessel.
This method of computing the cost universally applies to everything, including space stations, and space turrets. Turrets are cheaper than fighters because they can't move and they don't have their own reactors (they relies on a power grid to power them). Energy towers are low HP reactors with no weapon and also no speed. Lack of features makes a unit cheaper. A battery is a unit with low HP, no reactor, but high capacity for energy. Build some batteries near turrets and the turrets can fire burst cannon shots.
An isolated turret is completely useless. But it is well supported it by batteries and energy towers it could destroy a battleship in no time. When that happens, the cost of building the turret, the batteries, and energy towers do not add up to the cost of a battleship. If an isolate battleship charges in like that, it would cost the other player nothing to destroy.
All the costs are calculated accordingly.
Other than this there was nothing systematic about how units are balanced.
Small fighters are built because they cost less and are faster than battleships. They can dodge turret shots. A squadron of small fighters can fly around turrets and attack the energy towers.
Light battleships are good against small fighters because they have shields and they have multiple guns to shoot at multiple enemies at once.
Large battleships are good against light battle ships because they have cannons. Large battleships cannot power their cannons and shield at the same time and needs to have external generators. Small fighers attack these generators and they are intercepted by other small fighters.
There is not really a rock-paper-scissors system. You don't use small fighters alone to attack a base simply because the base also has small fighters. With the turrets, the small fighters would just die without doing any lasting damage. The way it works, is that a player send in the small fighters to distract the turrets and destroy the energy towers. At the moment that some of the energy towers are destroyed (thus the power grid is weakened), and the battery energies are spent, you send in the battleships to take out the turrets. You do this so that the turrets cannot burst fire on the battleships. Small fighters flying around an enemy base do not last very long, if they are not withdrawn they could be all dead by the time the battleship begins to attack. If that happens, the small fighters of the defending base could swamp the battleship and kill it. If the invading small fighters are withdrawn in time and with enough number, then the battleship could be protected and will finish the base.
A command tower is a structure that automatically build and send reinforcement to a deployed squadron, it assigns a leader to the squadron when its leader is destroyed. In automatic mode, the command tower selects the target and sends out the squadron when it is ready.
A fleet assembly is a structure that maintains the composition of a fleet. It builds the fighters that a fleet is defined to have, also the mobile generators, and supporting drones. When the player builds a fleet assembly, the game automatically begins to construct the fleet as energy is available to the assembly. A fleet assembly would automatically build additional energy towers, batteries and turrets around itself.
A starbase is a structure that maintains is own squadron, builds energy towers and turrets around itself. In auto mode it would also spawn command towers and fleet assemblies.
There is a hard unit limit, and every structure and unit that the player builds cost 1 of those slots. Energy is free, so a player could build a lot of energy towers to get a lot of energy, but it would be taking up the slots that could be used to build fighters.
What I've done in a TBS design (so it may not be usable for an RTS) is this.
I separate the weapons and armor from the unit. Each unit is 100 men, all with the same stats. The player decides how much armor (light, medium, heavy) and what weapon that unit will use. In addition, extra skills are added as desired/needed.
The weapons have their own stats, but generally don't deviate much. Swords aren't as good against heavier armor, but axes are. Axes are slower, and harder to hit with. Maces lie in between, as do hammers. Crossbows are more accurate, but reload much slower and have less range than bows.
Any armor disallows certain traits like swimming and mountaineering. Heavier armor reduces the amount of movement a unit has. With a base move of 20, the unit could lose up to 50% of it's move points. Cavalry basically doubles the base amount of move points, so a heavily armored cavalry unit would lost about 25%.
Cavalry can't cross mountains or swim (this is presuming deep water, any unit should be able to cross shallow water).
This gives the player a more dynamic army than just set units. Spamming the same unit won't make much difference either, due to various mechanics in the combat system. The only set units are siege equipment, and that is mostly basic infantry using a single, specialized skill.
Another method of introducing a more dynamic army is training time. Basic training is a week, but the player can let the unit train for up to 10 weeks. As each weapon has a skill level, this gives the player a better army, at the cost of more than 3 months game time, and a lot of money.
As far as unit limits, it's dependent on the player's population and food production. The entire thing is pretty simple, but a bit hard to describe at 3am after a long day.
The reason that SPR is such a well used method of balancing a game is that, unless you go too wildly out the standard format, it does guarantee a balanced system.
If A beats B beats C beats A, then no matter what a player uses, you will always have a way of at least equalling or beating them. This is then balanced.
But a perfectly balanced system is not always fun. What you need is a method of changing the balance slightly so as to allow a player to play a "bit dirty".
What most people think of as a SPR system is one that is played out just like the game of Scissors-Paper-Rock. Each player has no knowledge of their opponent's choices until they are revealed at the same time, and that all choices are equal.
SPR can exist even when these two assumptions are false, but it is only if these assumptions are true that the concerns over SPR are valid.
For example: 1: At the beginning of the game, for no cost, all players make a basic move (chose either Scissors, Paper or Rock). 2: If you win, you take the pot of resources. 3: If you tie the pot is split between you. 4: A play must play one of the move or forfeit the round. 5: Each player in turn can make a move as described below by placing resources into a pot: - It costs 1 resource to play a basic move (Scissors/Paper/Rock) which is not revealed at that time. - To change a move it costs the same as a basic move, but any resources you have already used for previous moves are not returned. - You can ask if the opponent's move is a particular move (eg is you move Paper?) and only get a yes or no answer for a cost of 3 resources. - You can force a reveal on your turn for the cost of 5 resources.
This is a very simple game and is not designed to be a very deep game. So taking that into account can it be fun, and where is the gameplay?
So, is this game about Scissors, Paper and Rock. Well yes and no. The game is actually about bluffing and risk. In this respect it is a bit like poker. As the "hand" continues, the stakes rise.
Although the result is determined by the SPR system, the actual gameplay is not. The Gameplay is determined by bluffing and trying to second guess you opponent.
But what about when the choices are not all equal. What if it cost 3 to play Scissors, 2 to play Paper and 1 to play Rock, how would this influence the game play.
Well, for one it would make certain choices more likely and others less likely, but probably not how you think. Because it is cheaper to play Rock, you might think it would be the most likely one to play, but because a beginner might think that, it becomes more likely that someone will play Paper instead. And so it goes around and around (you can work out what the ratios would be, but I am not all that familiar with the maths). However, because the choices are no longer completely random (you can have knowledge of your opponents choices, and can change your own choices) you can attempt to bluff your opponent by changing your choice and then calling them out on your next turn.
This is what people forget about the Scissors, Paper, Rock system when applied to games, it should not be the be all and end all of the system, but only one aspect. The aspect used to make the result fair and balanced.
It has got some bad press, usually justified because of a bad implementation, but on the whole the SPR system is not a bad system.
What is occuring with SPR is a bit like saying that all FPSes are bad just because you happened to play a really bad one once. I agree, there are some really bad implementations of FPS in games, but look at the popularity of the Beat-em-up games like Street Fighter and the like. These use fairly strong FPS systems and people don't complain about it. It is the implementation rather than the FPS system itself that is the problem.
Balance is about making each choice fair, this does not mean that the information has to be hidden, or that each choice has to be equal. It just means that no choice will always win. SPR guarantees that, and so is a good basis for making a balanced system. It is just that if all you do is stick with the implementation of SPR as it is in the game os Scissors Paper Rock, then you will not ahve a system any more interesting that that.
If all game design was, was implementing set design patterns, then the criticisms of SPR would be justified, but game design is not about that, it is much more than that.
