I was wondering what do the numbers of the unit stats actualy mean?What exactly is 456 turn rate?what are the units by which it is measured? how about reload time?and all the rest?
Can anyone clarify this?
Unit stats.
Moderator: Moderators
Re: Unit stats.
Spring uses Standardized Moon Units.
Re: Unit stats.
To understand turnrates you must first understand turnrates.
Re: Unit stats.
There are also a lot of factors in terms of balance that require that you can read and understand COB, in OTA mods.
For example, the real engagement speed of some units is considerably lower, and gives the unit less real combat power, than the weapon stats would suggest. CA's math posting in the Wiki, along with looking at the sleep / wait-for-turn values in a COB script, can give you real numbers. As an alternative, you could write a simple timer within the script's weapon loop to test things- it's very easy to do so.
In addition, you have to factor in relative hit-rates of a weapon vs. a given target, which gets very complicated, and involves the various strengths and weaknesses of various weapon types.
For example, if a weapon has an accuracy value of 300, or an error value of 1.648(approximate) degrees, and a range of 1000, it's real accuracy at maximum range is a lot lower than you'd think, and it's chances of achieving any damage at all is dependent largely on the area of effect.
But that, in turn, has strong effects on the power of the weapon against multiple units- so, is it weak, or strong? It becomes situational rapidly.
Such problems crop up everywhere. Here's another example:
Imagine a weapon that almost always hits, but may not hit for quite a long time. It is powerful in one sense, because it won't miss, but weak in another- in the time that has passed, the unit may have taken counter-fire that essentially makes the trade about damage only, or it may have decisively effected the outcome, because it will hit while other units can not do so (see, for example, the raw numbers involved in the RocketTank, in P.U.R.E., then test it against other unit types, in various terrains, and you'll start to see what I mean- it becomes entirely situational based on relative terrain heights- in a map like Pincushion, the RocketTank is far more powerful than its raw stats might suggest, for example).
If you factor in the speed of the weapon and relative speed of the target, and the rate at which hits are detected (for non instant weapons, the CollisionSize is quite important) , then factor in area of effect, the damage dealt over distance, which is, as Lurker demonstrated, a very odd curve, etc.... even determining the amount of average damage gets even more complex.
Not unsolvably-complex, using a flat-ground simplification of the gameworld (which, as noted above, is a crappy simulation, and probably a grave error), which is the only really practical way to attack these sorts of problems, but still, it's not really easy.
In short, you're unlikely to arrive at a suitably-sophisticated set of equations for talking about balance issues without a complete set of data. And a complete set of data is rather hard to actually acquire, because it's ultimately situational- you'd have to run several different calculations to arrive at meaningful simulations, tbh.
To get to the point of what is already a long-winded post... you can't just grab TDF / FBI numbers, and arrive at meaningful representations of balance- a lot of other things play their part, and you've got to understand what the engine's doing.
That's where attempts to balance via formula, especially in the area of real combat power, usually go horribly wrong- various factors are ignored, and the results are uniformly awful, because they do not represent the whole dataset. GIGO at its finest, basically. Not real balance.
I would like to write a complete calculator for weapon systems, at some point, just to have a tool for dealing with hit probability, because that's an issue that keeps coming up, but IRL, I just adjust everything until it feels about right, then test, like most people do, because new factors keep being introduced in the engine, and they would render such a tool, if not useless, then at the very least less accurate. And with weapon systems interactions, you can't lose a great deal of accuracy before you might as well just be tweaking it by hand and testing it out, imo.
For example, the real engagement speed of some units is considerably lower, and gives the unit less real combat power, than the weapon stats would suggest. CA's math posting in the Wiki, along with looking at the sleep / wait-for-turn values in a COB script, can give you real numbers. As an alternative, you could write a simple timer within the script's weapon loop to test things- it's very easy to do so.
In addition, you have to factor in relative hit-rates of a weapon vs. a given target, which gets very complicated, and involves the various strengths and weaknesses of various weapon types.
For example, if a weapon has an accuracy value of 300, or an error value of 1.648(approximate) degrees, and a range of 1000, it's real accuracy at maximum range is a lot lower than you'd think, and it's chances of achieving any damage at all is dependent largely on the area of effect.
But that, in turn, has strong effects on the power of the weapon against multiple units- so, is it weak, or strong? It becomes situational rapidly.
Such problems crop up everywhere. Here's another example:
Imagine a weapon that almost always hits, but may not hit for quite a long time. It is powerful in one sense, because it won't miss, but weak in another- in the time that has passed, the unit may have taken counter-fire that essentially makes the trade about damage only, or it may have decisively effected the outcome, because it will hit while other units can not do so (see, for example, the raw numbers involved in the RocketTank, in P.U.R.E., then test it against other unit types, in various terrains, and you'll start to see what I mean- it becomes entirely situational based on relative terrain heights- in a map like Pincushion, the RocketTank is far more powerful than its raw stats might suggest, for example).
If you factor in the speed of the weapon and relative speed of the target, and the rate at which hits are detected (for non instant weapons, the CollisionSize is quite important) , then factor in area of effect, the damage dealt over distance, which is, as Lurker demonstrated, a very odd curve, etc.... even determining the amount of average damage gets even more complex.
Not unsolvably-complex, using a flat-ground simplification of the gameworld (which, as noted above, is a crappy simulation, and probably a grave error), which is the only really practical way to attack these sorts of problems, but still, it's not really easy.
In short, you're unlikely to arrive at a suitably-sophisticated set of equations for talking about balance issues without a complete set of data. And a complete set of data is rather hard to actually acquire, because it's ultimately situational- you'd have to run several different calculations to arrive at meaningful simulations, tbh.
To get to the point of what is already a long-winded post... you can't just grab TDF / FBI numbers, and arrive at meaningful representations of balance- a lot of other things play their part, and you've got to understand what the engine's doing.
That's where attempts to balance via formula, especially in the area of real combat power, usually go horribly wrong- various factors are ignored, and the results are uniformly awful, because they do not represent the whole dataset. GIGO at its finest, basically. Not real balance.
I would like to write a complete calculator for weapon systems, at some point, just to have a tool for dealing with hit probability, because that's an issue that keeps coming up, but IRL, I just adjust everything until it feels about right, then test, like most people do, because new factors keep being introduced in the engine, and they would render such a tool, if not useless, then at the very least less accurate. And with weapon systems interactions, you can't lose a great deal of accuracy before you might as well just be tweaking it by hand and testing it out, imo.
Re: Unit stats.
I don't think he was asking for all that argh.
Re: Unit stats.
No, he was asking for a simple answer to a very complex problem, and he'd pm'd me, asking about details that go into balance, so meh, I figured it'd be better to explain stuff a bit. People keep making stabs at these problems, but they're too lazy to do it well, most certainly including me, although I've spent a lot of time thinking about it. Maybe he'll be the one to actually take this on and do it right, who knows?
Re: Unit stats.
What is important is to not to account for everything but account for the correct number of details as to make a game balanced with the chosen rules but not to do unnesasary work.
There is no point in going into details of the balance that not even the best players will notice.
Some things can be rounded up and maybe even ignored if they dont really show up in game and will not be noticed by not even the best and most perceptive players,which in turn means that their effect on a game's result is tiny and statisticly unimportant.
I do not yet know about whats going on behind the curtains and the question is how much do stats miss.
As i have pmed to Argh,Tireds balance,if you actually play it feels very balanced and wholesome,I played it quite a lot and felt it was very close to its objective.
You can talk math all day but you must connect it with game experiance,that can be personal or the experiance of the evolution of the balance of a certain mod.
you cannot find a single equation that will have that core tha twill unify everything and give everything its EXACT value.
Spring is not chess,its rules of combat are too dynamic even the game's board changes and each ofthose boards needs a seperate equation or a set ofequations and estmates.
Besides balance you must also think of good gameplay,at least at the unit's level and not the overall which is much more complicated.
I was thinking of establishing bounderies for unit stats,using the game experiance of one or maybe even several ota based mods.
The point of limiting stat numbers is to make a connection between
the numbers and the game thus removing unnessesary possibilites
That cant be used practicly on units.
Within those boundaries Stats can recieve values based on percentage changes within the boundaries of stats that supervise effectivness and those that supervise cost andthe ratio between them.
The change in percantages between the max and min of all kinds of stats will decide their influance on the cost of a certain unit we wish to balance.
Roughly,If dmg,for example,changes a lot between its lowest and highest boundary that means that Its influance on the cost of a unit is low compared to a stat which only changes a little bit between the maximum and minimum boundery.
If good and reasonable boundaries are found a unit is than taken
that has all its stats and cost at the lowest degree and each stat that is raised by a percantage should raise cost by a percantage as well till u get a unit with all effectivness stats at max and all cost stats at max(i am talking about an equation that gives a certain static ratio between effectivness and cost effectivness).
After thinking about it a bit I realised that there would be a need to create 2 new units(or just blatently change one units effectivness stats be lowest without a rpice change and one units effectivness stats at max without changing cost stats )that will have all their effectivness stats at max/min and all the cost stats will have to be higher/lower than existing units because there probably isnt one unit that has all its stats at the heighest/lowest of all other units and also have the highest/lowest costs.
That is a bit of a problem.
Since it means that some boundaries will have to be manually modified,however that will not mean the boundaries will be any worse ,they will just be a bit different.
There is no point in going into details of the balance that not even the best players will notice.
Some things can be rounded up and maybe even ignored if they dont really show up in game and will not be noticed by not even the best and most perceptive players,which in turn means that their effect on a game's result is tiny and statisticly unimportant.
I do not yet know about whats going on behind the curtains and the question is how much do stats miss.
As i have pmed to Argh,Tireds balance,if you actually play it feels very balanced and wholesome,I played it quite a lot and felt it was very close to its objective.
You can talk math all day but you must connect it with game experiance,that can be personal or the experiance of the evolution of the balance of a certain mod.
you cannot find a single equation that will have that core tha twill unify everything and give everything its EXACT value.
Spring is not chess,its rules of combat are too dynamic even the game's board changes and each ofthose boards needs a seperate equation or a set ofequations and estmates.
Besides balance you must also think of good gameplay,at least at the unit's level and not the overall which is much more complicated.
I was thinking of establishing bounderies for unit stats,using the game experiance of one or maybe even several ota based mods.
The point of limiting stat numbers is to make a connection between
the numbers and the game thus removing unnessesary possibilites
That cant be used practicly on units.
Within those boundaries Stats can recieve values based on percentage changes within the boundaries of stats that supervise effectivness and those that supervise cost andthe ratio between them.
The change in percantages between the max and min of all kinds of stats will decide their influance on the cost of a certain unit we wish to balance.
Roughly,If dmg,for example,changes a lot between its lowest and highest boundary that means that Its influance on the cost of a unit is low compared to a stat which only changes a little bit between the maximum and minimum boundery.
If good and reasonable boundaries are found a unit is than taken
that has all its stats and cost at the lowest degree and each stat that is raised by a percantage should raise cost by a percantage as well till u get a unit with all effectivness stats at max and all cost stats at max(i am talking about an equation that gives a certain static ratio between effectivness and cost effectivness).
After thinking about it a bit I realised that there would be a need to create 2 new units(or just blatently change one units effectivness stats be lowest without a rpice change and one units effectivness stats at max without changing cost stats )that will have all their effectivness stats at max/min and all the cost stats will have to be higher/lower than existing units because there probably isnt one unit that has all its stats at the heighest/lowest of all other units and also have the highest/lowest costs.
That is a bit of a problem.
Since it means that some boundaries will have to be manually modified,however that will not mean the boundaries will be any worse ,they will just be a bit different.