A few months ago a colleague and I began our first foray into game design. Since then, I’ve been joining sites like this and have spent hours reading articles. forums, and blogs. I’ve really enjoyed the process so far but now I’m coming to a point where I need some help and advice - unit stats. I’ve done a lot of reading about stats and balance over the last few weeks but, few articles seem to be able to give me an idea of how to lay my groundwork.

I’ve gone ahead and put some ideas together but, I would love to know if I’m on the right track or if I’m completely out to lunch with my stat / balance ideas. Any criticism or advice would be greatly appreciated.

Game Overview

The game we're trying to develop is a turn-based strategy that uses a large number of randomly drawn units - at times I will almost describe it as being collectable card game influenced.

In the game, the player attempts to control areas on the game board. Controlling areas earns the player resource, for which the player can use to hire units, or to equip items to hired units. Players win the game by eliminating all other players - by taking all of their areas, and eliminating all of their units.

Units are drawn into the players hand from a deck, and can be hired with resources earned from the game board.

• units can only be hired to areas under player control or to areas having a player unit already on it.
• units can only perform 1 action per turn
• units can only move to an adjacent area
• units can only attack enemy units if both are on the same area

Units are able to perform 7 actions in the game

Move – move unit from current area to an adjacent area.
Control – unit attempts to possess an area not already under players control.

Dominate – unit dominates area, in an attempt to gain a secondary benefit from controlled area.

Equip – add equipment to unit, enhancing stats.

Research – unit does nothing on game board, instead unit is used to help unlock additional equipment.

Attack – unit will attack unit under control of another player.

Defend – unit defence increased and unit hit points recharged an amount (based on unit heal ability).

Units

In my game there are two races - magic users and mecha users; and four classes per race. I would like to have this reflected in the units created as well. My idea is to create generic “blueprint” units and then apply a “modifier” onto that unit to adjust it's stats into reflecting “X” race and “Y” class.

If I had the skill, another aspect I would love to employ is that, as a magic user there would be decreasing returns in relation to cost “less bang for your buck”. But, as a mecha user, I would have increasing returns or “more bang”. I think I might need to design two pools of units if I did that though.

My unit stats are going to be:

Attack – multiplier for all units attacks. Used when determining attack strength.

Defence – multiplier for units overall defence.

Intelligence – multiplier for all know-how related actions (research, magic, mecha).

Presence – multiplier for all control and Dominate actions

Health – amount by which unit can heal per turn

Strength – physical stack force. Used when determining physical stack strength.

Physical – resilience of unit. Used when determining resistance to physical attacks.

Range – distance from which unit can hit. Used when determining ranged attack strength.

Agility – ability to dodge ranged attacks. Used when determining ranged attack defence.

Magic – units magical ability.

Mecha – units ability to use technology

For actual actions, I was thinking this would be how they are affected by stats:

Attack Actions

Physical attack = Attack x Strength

Ranged attack = Attack x Range

Magic or Mecha Attack = Intelligence x Magic or Mecha

Defence Actions

Physical Defence = Defence x Physical

Ranged Defence = Defence x Agility

Magic Defence = Defence x Magic

Equipment Actions

Research (Gear) = Intelligence x Mecha) / Magic

Research (Magic) = (Intelligence x Magic) / Mecha

Equipping Gear = Mecha

Equipping Magic Items = Magic

Area Actions

Controlling = Presence

Investing = Presence x Intelligence

Blueprint

With all that, the “blueprint” portion of my idea is based off of the list found below. I equated each attribute to a cost, and then added in a cost change after a certain number of points is given to that stat. My idea is to create a list of all the possible attributes a unit can have at a given resource cost, and then keep the “relevant combinations” - those that have attributes that work well together (i.e. attack and strength). This would create my blueprint units up to whatever cost I decide.

For a base unit cost, I decided that a unit with a cost of 0R(resource) will have:

1 attack, 1 intelligence, and 1 Magic or Mecha (depending on race).

These base unit stats will be added to blueprint units created using the following stat cost outline. All possible card combinations are made for a unit with stats totaling 1R. Then again for 2R, and so on until a resource pool with sufficient depth and cost diversity is attained.

Intelligence and Magic

cost: 4

until greater than: 3

new cost: 5

Defence

cost: 6

until greater than: 2

new cost: 4

Attack

cost: 4

until greater than: 2

new cost: 3

Mecha

cost: 4

until greater than: 3

new cost: 2

Heal

cost: 2

until greater than: 4

new cost: 3

Presence

cost: 2

Strength / Agility

cost: 2

until greater than: 4

new cost: 1

Physical / Range

cost: 1

until greater than: 5

new cost: 2

Lastly, I mentioned that there would be 4 “classes” per race. The classes each come with an additional stat modifier

Magic 1 +1 Agility

Magic 2 +1 Strength

Magic 3 +1 Presence

Magic 4 / Mecha 4 +1 Heal

Mecha 1 +1 Physical

Mecha 2 +1 Range

Mecha 3 +1 Intelligence

I know it’s not a lot so far but, I wanted to make sure I wasn’t completely out to lunch before I really invested serious hours. Thank you for taking the time to read this, I really do appreciate it.

Have you played Chaos Overlords? Sounds a bit similar (equip and reserach as an action that uses up a turn), I recommend checking.

Also a practical advice, since this is your first game I would ignore stats, it's a really minor thing, I would concentrate on making the prototype. Plus, balancing stats is far easier after you have a fully playable game than during design stage. No matter what you plan now it will work completely different than you expected anyway in the real game :)

Hello Drahaus!

Very interesting post.

Just a few questions from the get go there:

- I'm currently under the impression this is a board game. Do you intend to make this a computer video game, or a physical board game? The reason I ask is because the design space allocated to complex stats and formulae would benefit from being lighter if it is meant to be a physical board game whereas it would be appropriate if it is meant to be computerized.

If I had the skill, another aspect I would love to employ is that, as a magic user there would be decreasing returns in relation to cost “less bang for your buck”. But, as a mecha user, I would have increasing returns or “more bang”. I think I might need to design two pools of units if I did that though.

If I understand correctly, you'd like the wizards to be advantaged in numbers, whereas mecha should be a "quality first" type? You have to be EXTREMELY careful about this in a game where territory plays out. You have to account for the following:

- Mobility (more units can have a better overall reach)

- Control (you game relies on controlling more regions, and more units can more easily control more regions)

- Concentration of forces / flanking (large amount of units can more easily outnumber the enemy at wanted encounter points).

To better examplify this one, note that a game of chess with a king and a queen faced against a king and all of its minor pieces will put the latter player at a serious advantage. A skilled player will easily thwart the Queen's mobility in but a few turns.

Blueprint

With all that, the “blueprint” portion of my idea is based off of the list found below. I equated each attribute to a cost, and then added in a cost change after a certain number of points is given to that stat. My idea is to create a list of all the possible attributes a unit can have at a given resource cost, and then keep the “relevant combinations” - those that have attributes that work well together (i.e. attack and strength). This would create my blueprint units up to whatever cost I decide.

For a base unit cost, I decided that a unit with a cost of 0R(resource) will have:

1 attack, 1 intelligence, and 1 Magic or Mecha (depending on race).

These base unit stats will be added to blueprint units created using the following stat cost outline. All possible card combinations are made for a unit with stats totaling 1R. Then again for 2R, and so on until a resource pool with sufficient depth and cost diversity is attained.

Your theoretical analysis is flawed. The thing is, you can account for each separate mechanic's worth and compare them to one another, but you can't possibly see all the potential synergies coming. Its good that you try and build a theoretical model to have something that could work as a first draft, but, this is just the type of thing you'll need to prototype as quickly as possible.

Not too long ago, I was working on a similar board game idea and brought it to prototype as quickly as possible (currently under its 11th full iteration). The early iterations quickly revealed that despite my efforts, I could not account for some of the synergies I had not anticipated. I initially though that, in retrospect (aka, after finding these) I could apply a new theoretical model that would account for these, but it kept on failing because the interactions are much too subtle for me to fully grasp the entire model.

On the one hand, this is a good thing, because it proves that the game has strategic potential, and players get to be able to "break the curve" through analyzing and mostly playtesting their ideas. On the downside, it makes it very tough to model efficiently.

In the end, my solution for interactions and synergies was simply to put the model through severe playtesting and try crazy things. The downside with this method is that there will be some dominant strategies that haven't been discovered during these playtestings, and once players eventually toy around and discover these, the game will lose its appeal to them. In other words, they'll have BROKEN the game (understood it to the point where its inherent flaws, no matter how concealed, become apparent).

One way to avoid this is to prevent units from having overlapping synergies. Each unit being a specialist for example. One is mobile, one is ranged, one is melee, etc. My personal solution for this was to utilize the board as a unit of influence. Think of it as a heatmap:

- The melee soldier has a very small area of influence, but its burning red because, once it has reached its destination, it takes it like a champ.

- The ranged soldier has a larger area of influence, but its pale. It can cover larger areas of the map, but won't easily prevail within 1 turn.

- The mobile soldier has the advantage of speed. Generally speaking, I usually coupled that with a strong melee attack, but it could also be applied to a ranged unit. Technically, it gives it a lot more ground to cover, thus, a larger influence, but it will generally not be as strong as the melee soldier. Also, in an environment where you move OR attack, it has a clear offensive advantage, but will suffer at the hands of a defensive unit such as the ranged and melee soldiers (it will take at least 1 hit from its advance).

Idea to consider (diverse units will cause confusion unles player can figure out how to organize them locally/at locality to reinforce each other)

---

Classic Napoleonics (3 basic flavors of function/action capability)

Infantry

Cavalry

Artillery (Napoleon was originally an Artillerist)

When you have all 3 in one place you have flexibility and if your opponent doesnt then you can use the element they are missing to counter/win against them.

---

So if you want your game to be fun to play and not arbitrary (players like to know their tactics are not rendered useless because of simple chance/randomness) then you will need some small number of equivalent factors for your game that will allow the player to quickly organize MOST of his units -- he can still finess situation, but it wont require tedius mental recombining to get a adaquate organization in place for their available units and quickly see where their disadvantaged situations will be to be specially handled.

Infantry

Cavalry

Artillery (Napoleon was originally an Artillerist)

You'll obviously want to divide your classes by their advantage.

Here, probably:

- Cavalry: Mobility (it can be where you need them to be fast enough to capitalize on openings)

- Artillery: Range (it can defeat the others without fear of retaliation when at a safe distance)

- Infantry: Numbers/Firepower (from upclose, it can defeat the others)

I've used the same process when developing my game economy for a space conquest game and ended up with aproximately 10 roles that units could fill (most units being able to fill only 1-3 roles at a time).

It isn't necessary to have all 10 roles as some roles are different ways to achieve a similar undelying objective. For example, you can see to acquire control over a planet by either bombarding it dry, or by sending more troops on the surface. These two strategies are very different, but the outcome is roughly the same: at some point, the enemy will be defeated and you can claim the planet.

Of course, I also use the Ranged and Mobility advantages for at least 2 roles, but I like to mix and match missions that are more complex.

For example:

To be a good scout, a unit needs to be fast, has good sight range, is hard to see and have a low mass (so that it doesn't require a lot of fuel). It looks at many characteristics at once which are all required to effectively make it a good scout.

If your game allows it, I suggest that you make your "roles" a bit more complex as it will add a lot of depth to your strategies.

Have you played Chaos Overlords? Sounds a bit similar (equip and reserach as an action that uses up a turn), I recommend checking.

Funny enough, when we were originally coming up with the game idea, someone said the same thing. We looked at it and, in a lot of ways, it’s the 1996 version of the game we hope to build. In some ways, my dream is comes close to what a modernized, slightly re-imagined version of that game could be.

In terms of prototype, we’re just in the middle of getting our first build up and running. I agree that once we have a running prototype, things will be a lot less murky. I would just like to have my self set-up as best I can before we get there.

I'm currently under the impression this is a board game. Do you intend to make this a computer video game, or a physical board game?

First, thank you for such a great reply. It is a computer game but, I find it’s easier to explain the game in terms of a (conceptual) board and cards.

If I understand correctly, you'd like the wizards to be advantaged in numbers, whereas mecha should be a "quality first" type? You have to be EXTREMELY careful about this in a game where territory plays out. You have to account for the following:
- Mobility (more units can have a better overall reach)
- Control (you game relies on controlling more regions, and more units can more easily control more regions)
- Concentration of forces / flanking (large amount of units can more easily outnumber the enemy at wanted encounter points).
To better examplify this one, note that a game of chess with a king and a queen faced against a king and all of its minor pieces will put the latter player at a serious advantage. A skilled player will easily thwart the Queen's mobility in but a few turns.

Your chess analogy is quite apt, and it highlights my concerns perfectly. The hope that I have right now is that if I can balance my units right, I can have a transition from magic to mecha with minimal disruption. Magic being minor pieces and mecha being the queen, I would ideally like to keep the dynamic of the chess scenario you presented. Mecha should not completely dominate magic but, magic shouldn’t be able to thwart mecha easily or without some strategy or tact. My the idea is to have magic users being a unit that is effective at the start of the game (“out of the gate” if you will) but will become less and less effective as higher quality (price) units come into play. Having said that, what I need to do now is have a look at the concepts of mobility, control, and concentration; what role they play and how I can best utilize that in my design (or what relevant changes I need to make). I want to make sure I’m understanding the idea’s correctly though.

In my game, because magic is cheaper and weaker (requires more turns to control an area, weaker attacks), the player would have a greater ability to hire additional units based on their having a lower cost. Additional units can either begin taking over multiple areas simultaneously or can concentrate on an area and control it more quickly. Conversely, mecha units are stronger (can control an area more quickly) but, due to their higher cost, a player will be able to hire mecha units less frequently.

Mobility - with respect to my game, I feel like this would involve a players ability to grow their controlled area (with units) or simply the number of units a player would be able to move in a given turn.

If I have that right then I think the balance here comes in terms of a units ability to take control over an area.

Control - where as mobility deals with the players ability to grow their territory, especially in multiple directions, I think control would relate more to a players ability to control and subsequently dominate an area.

Concentration - I think this would apply to ideas such as “stacking” units on a given area and the subsequent effect this will have on (combined) unit actions. Again, this is highlighted in your chess example above.

Your theoretical analysis is flawed. The thing is, you can account for each separate mechanic's worth and compare them to one another, but you can't possibly see all the potential synergies coming. Its good that you try and build a theoretical model to have something that could work as a first draft, but, this is just the type of thing you'll need to prototype as quickly as possible.

Good point. I guess my thought with the whole “relevant combinations” was that, without it, I would be testing about a thousand or so units. I’m just not sure of how to do that without it taking an inordinate amount of time. I think this is the crux of my first problem - I can create a database of nearly every possible combination of stat (based on my outline) including modifications for race and class. But how do you play test a database that large?

Idea to consider (diverse units will cause confusion unles player can figure out how to organize them locally/at locality to reinforce each other)

I like the idea os specialization and “roles”; and I agree that it would help the player greatly and minimize confusion. Like you saw I’m already thinking of dividing units down by race and then by class. I think if I keep developing this, I can incorporate your idea further. If I take Orimus’ advice as well and develop a deeper role, it will be a bit like separating trail mix into its ingredients. I can have clear distinctions between all of my units but, I also have a wide variety of units within that distinct role.

So if you want your game to be fun to play and not arbitrary (players like to know their tactics are not rendered useless because of simple chance/randomness) then you will need some small number of equivalent factors for your game that will allow the player to quickly organize MOST of his units -- he can still finess situation, but it wont require tedius mental recombining to get a adaquate organization in place for their available units and quickly see where their disadvantaged situations will be to be specially handled.

If your game allows it, I suggest that you make your "roles" a bit more complex as it will add a lot of depth to your strategies.

I think this might allow the player to, as you said, quickly organize most units (conceptually) and allow the player to for a better strategy. Having that diversity within the role allows the player to finesse the situation and allow for more strategic play as opposed to being simply tactical as well.

Acharis, on 04 Jun 2013 - 01:17, said:

Have you played Chaos Overlords? Sounds a bit similar (equip and reserach as an action that uses up a turn), I recommend checking.



Funny enough, when we were originally coming up with the game idea, someone said the same thing. We looked at it and, in a lot of ways, it’s the 1996 version of the game we hope to build. In some ways, my dream is comes close to what a modernized, slightly re-imagined version of that game could be.

Well, if you are making better Chaos Overlord, do you intend to fix its issues? The biggest one was the growing number of units and slower and slower turns (+1 unit per turn to control and you had to issue an order to each unit each turn). Some kind of Sid Meyer's "corruption" mechanic would be nice or something like a progressive upkeep cost (Warcraft 3).

Generally, at a certain point (in Chaos Overlords) I was not really paying attention to units stats anymore. There were too many to control. I mean, if you really want meaningful unit abilities you need to make fewer units. The more units you have, the less important it becomes.

Also, how are you going to select/buy new units? That's quite important and affects the attributes (do you actually have a choice what unit you get?)

My take on ChaosOverlord type on game :)

- standard grid map (no change here)

- two kind of units, movable and garrision units. Each sector under your control (you need to conquer it first) can have exactly one garrision unit, it can't move or take any orders (you can only replace it), all they do is stay and fight any enemy unit that enters

- you have reputation points (gained from territory control, but not linear), reputation determines your maximum number of movable units (the goal is to allow no more than 30 units total even if you conquer the whole map and have very high reputation)

- alternatively, you could have command points (Space Hulk style, limits the number of orders you can give to your units each turn) instead of reputation, this would allow more units but has its drawbacks...

- leader unit, grants bonus to all units in adjacent sectors

- no research/chaos/influence units, or at least hide them somehow. There should be only combat units on the map (or allow peaceful units in headquarters sector/s only).

Your chess analogy is quite apt, and it highlights my concerns perfectly. The hope that I have right now is that if I can balance my units right, I can have a transition from magic to mecha with minimal disruption. Magic being minor pieces and mecha being the queen, I would ideally like to keep the dynamic of the chess scenario you presented. Mecha should not completely dominate magic but, magic shouldn’t be able to thwart mecha easily or without some strategy or tact. My the idea is to have magic users being a unit that is effective at the start of the game (“out of the gate” if you will) but will become less and less effective as higher quality (price) units come into play. Having said that, what I need to do now is have a look at the concepts of mobility, control, and concentration; what role they play and how I can best utilize that in my design (or what relevant changes I need to make). I want to make sure I’m understanding the idea’s correctly though.

Thanks for clarifying. I was under the impression one side would play Mecha and the other Magic, hence why I was worried about this asymmetric decision (not that asymmetry doesn't work, but there's been good examples that prove that one mobile side against a turtle side tends to thrump it all based on numbers or mobility).

One alternative to keep minor units (magic) relevant while Mecha have a clear tactical advantage, is to give you magic unit an 'economy role' that can't fit fitted by mecha. For example, Mechas can't control territories, or can't generate units of resources. You'll notice that chess' this most important piece is the weakest (pawn) based on its economic value. Provided you play your game right, you can trade queen for queen, but be the first to get your queen back, and that's no small advantage later down the road. By granting your magic units this advantage, you make them critical in the early game, and relevant in the late game. You still need magic units to sustain the logistics behind your mecha units so to speak.

Mobility - with respect to my game, I feel like this would involve a players ability to grow their controlled area (with units) or simply the number of units a player would be able to move in a given turn.

If I have that right then I think the balance here comes in terms of a units ability to take control over an area.

What about moving twice for some units?

Control - where as mobility deals with the players ability to grow their territory, especially in multiple directions, I think control would relate more to a players ability to control and subsequently dominate an area.

I believe you have the wrong assumption of what mobility is. It's not as much as the place your troops are, but how fast they can be where you want them to create a tactical advantage.

For example, the Queen has a great mobility, and its quite obvious, but while the knight's mobility is fairly limited, its still a very mobile unit because:

- It jumps pieces, making it the only piece able to bypass a strong defense altogether

- It has an odd capture pattern which allows it to endanger units without endangering itself

(you'll have guessed that the knight is my favorite chess piece by now!)

So while a Queen's area of influence is fairly straightforward, the knight's area of influence solely depends on how you're willing to use it, but positioning will be key and will determine where it can or can't go.

Good point. I guess my thought with the whole “relevant combinations” was that, without it, I would be testing about a thousand or so units. I’m just not sure of how to do that without it taking an inordinate amount of time. I think this is the crux of my first problem - I can create a database of nearly every possible combination of stat (based on my outline) including modifications for race and class. But how do you play test a database that large?

Well, quite frankly, I doubt you need all of the above. You need to determine how your gameplay will feel and come up with only that which feels like a 'right' combination to support that. Then, you toss them together and playtest. I suggest the following for EACH iteration (aka, whenever you change one unit).

- Test it yourself, make small adjustments until you have something viable and test again

- Test with a friend until it makes sense (don't be afraid to go back to the drawing board)

- Let two friends test it out, and only observe (your only cue should be to clarify the rules if they clearly can't agree on what's happening)

(you'll have guessed that this playtesting will all occur before actually coding anything)

- Make/Adjust the prototype and test it

- Test the new prototype with a friend

- Let two friends test the prototype and observe

- Create a metric system to implement along with the prototype

- Let a wider beta tester audience test the new prototype, ask them to report everything, exporting their save files which possibly has a turn-by-turn log of some kind, and consult your metrics

- Go back to the drawing board until it works :)

The idea here is that if you start working with a small subset of units you understand, and that strategically complement or counter one another, testing will reveal units you can remove, and units you are missing. The end result is a coherent unit roster, hopefully with the minimum amount of units you actually need, and none more. By then, you can refer to them by archetype names (by their functions for example).

I think this might allow the player to, as you said, quickly organize most units (conceptually) and allow the player to for a better strategy. Having that diversity within the role allows the player to finesse the situation and allow for more strategic play as opposed to being simply tactical as well.

One of the things you should be trying to achieve here is to give the 'obvious' function of the unit, and let them work out the more obscure function, so that when a player realizes that these units can do more than one thing, their go 'ompfff' in amazement and feel clever for figuring it out.

One similar example in chess is when a novice player that's been mostly trying to check the enemy's king with his bishop realizes he can do tricky moves such has putting the bishop behind his own rook, then move the rook to check the king, all the while insuring he can capture a distant rook or queen that is has been put indirectly in his crosshairs (I remember feeling clever when I started doing that, possibly at the same time as I started to worry about my ELO rating...)