Report message to a moderator

Report message to a moderator

Report message to a moderator

It is not possible to predict battle outcome with 100% accuracy. Actual battle outcome depends on lot of unpredictable things. I have seen people losing battles that they testbedded about 10 times.

Equal init fires random, fleets get random weight bonuses, they often move randomly, cost (so exact tech levels, BET, CE and IS or WM) affect attractiveness, missiles have their random accuracy, often not all the ships in fleets are fully healed, there are lot of possible different battle orders and odd quirks in battle engine. The starting position can be often vital, if it is planned 4-way battle then there just sole fift guys scout can completely turn the tables.

Since the battle outcome is quite often so random anyway, does someone expect a tool that can be more accurate than the real life? Best you can do is to address it bit more "statistically".
1) Best case scenario for side A,
2) best case scenario for side B
3) average outcome for about 50 battles

Should be possible to give out in seconds by modern computers.

[Updated on: Tue, 16 November 2004 07:38]

Report message to a moderator

[Updated on: Tue, 16 November 2004 09:06]

Report message to a moderator

Report message to a moderator

There are no battle outcomes that can be shown as one number.

There are usually multiple stacks at each side and after battle for each stack 2 numbers describe its condition. Survival and damage.

Lets say average player does not worry about damage too lot. Damage can be repaired with few turns. Then it leaves only the survival. Giving survival for each stack separately is probably vital anyway since people may be sometimes very interested in results like "do bombers survive".

If we take that jugger versus jihad scout battle and see that jugger scout stack is dead 38 times and alive 62 times from 100 and never partially survived so we can say that:
worst case is its 0% survived
best case is its 100% survived
in average its 62% survived

I believe that such tool would be wonderful.

Report message to a moderator

Report message to a moderator

Report message to a moderator

Thanks for the suggestions and help, everyone.

Now I can run my simulation a thousand times and see what the min/ave/max survival rates are for each stack.

But how can I tell whether my results (and hence, the simulation code) are correct or not ? I'm not entirely sure I can

Report message to a moderator

Simulate a battle 1000 times.
Make stars do the battle 1000 times.
Compare.

Report message to a moderator

SnakeChomp wrote on Wed, 17 November 2004 03:23

Simulate a battle 1000 times. Make stars do the battle 1000 times. Compare.

This is possible as long as each token in the battle can be produced in 1 year and the stars are neatly arranged.

Ships just have to happen to be in the same place 1 year, while on autoroute to some further away spot. Difficult to set up and only works for one engine type(as this determines speed), but then just set the right ships in queues a few thousand times and gen a thousand years.

Carn

Report message to a moderator

Staz wrote on Tue, 16 November 2004 19:03

But how can I tell whether my results (and hence, the simulation code) are correct or not ? I'm not entirely sure I can

Do it like any you would test any software.
Set up examples where you know the result beforehand, and gradually increase the complexity.
Things like ship movement should be easy to check.
Then introduce ship weight and see what happens.
Then battle orders.

Report message to a moderator

Staz wrote on Tue, 16 November 2004 21:03

But how can I tell whether my results (and hence, the simulation code) are correct or not ? I'm not entirely sure I can

Sure, making good model is separate task from giving out useful results for end user.

First you need some visualization of single battle step by step of course. Maybe find out if you can use some code from Freestars for it. Even if they have nothing to offer you can then give your algorithms to them when ready.

Then its lots of testing ... to ease it you can use test battles where randomness does not matter much first.

For example if you want to see how something moves with some specific battle orders you need to have them lots at board split up. Then you see the probabilities for them to move this or that way both in stars and your simulation.

Similarily if you want to see if simulation torpedo damage is correct or not you need to test it with rather large stacks of torpedoes firing at rather big stacks of armor, because there the differences between battles should be very little.

Finally, if your tool does show some different results than it really happens in stars you will soon hear about it from annoyed users.

Report message to a moderator

Report message to a moderator

Report message to a moderator

Staz wrote on Wed, 17 November 2004 21:12

Regarding ship movement - does anyone have the first clue what algorithm the Stars! battle engine uses ? Sometimes it's choices seem totally random to me. A search of rgcs seems to indicate that it hasn't been analyzed much, if at all.

I just paste here an article i have somehow stored on my harddrive, by great FAQ maker James McGuigan. I think it was in r.g.c.s newsgroup in some movement thread. I am sure that "minimize damage to self" works a bit differently, but for starters it is certainly better than nothing... :

Here are the guts of the battle engine as I understand it from both
experience, observation and the help file (please pull me up on any points I
get wrong)


For a battle to take place 2 or more fleets (or a fleet and a starbase) must
be at the same location and at least one of the fleets must be armed and
have orders to attack ships of the others race (the type of ships involved
doesn't matter). If are race has a fleet present at a location where there
is a battle, but doesn't have orders to attack any of the other races there
and none of the other races present has orders to attack it then it will not
take part in the battle (and can not benefit from potential tech gain).

Each ship present at the battle will form part of a token (AKA a stack), it
is possible to have a token comprised of just a single ship. Tokens are
always of ships of the same design. Each ship design in each fleet will
create a token, splitting a few ships off to form a second fleet before the
battle will create a second token on the battle board.

The battle grid is made up of 10 squares by 10 squares. Each token is in a
single square, there can be more than one token in the same square.There is
an limit of 256 tokens per battle event for all players involved, if this
limit is exceeded, then excess tokens will be left out (those created from
fleets with the highest fleet numbers), in such a case each player will have
an equal number of tokens, each player will be guaranteed to get their
"share" of the available token slots (ie in a 4 race battle 256 / 4 = 64
token slots), if a race doesn't use up all their "slots" then they are
shared equally between the other players.

Each battle is made up of rounds. There are a maximum of 16 rounds in each
battle. Each round has two parts, movement and shooting. Each token has a
speed rating, and will be able to move between 0 and 3 squares in a single
turn. If a token has a fractional speed rating then they will get a bonus
square of movement every set number of turns. a 1/4 bonus means an extra
square of movement on the first round and then on every fourth round after
that starting with the fifth. A 1/2 speed bonus gets a bonus square of
movement every other turn starting with the first, and a 3/4 speed bonus
gets a bonus square of movement for the first three rounds of every 4 round
cycle. The order of movement is this, each token with 3 movement squares
moves a single square, then each token with 2+ movement moves a single
square (if it had speed 3 then it would move for its second square) and then
all ships with at least one square of movement move again. At each stage the
ships with the most weight will move first though there is less than a 20%
difference in weight then there is a chance that the lighter ship will go
first. The smaller the weight % difference the greater the chance of the
lighter ship going first.

Each token has an attractiveness rating. This is used in both working out
where ships move to and which ships are shot at first. The essence of the
formula is cost / defence. A ship will have different attractiveness ratings
verses different types of weapons (beams, sappers, torpedoes and capital
missiles). Cost is calculated by summing the resource and boranium costs of
the ship design used (iron and germ costs don't affect the attractiveness
rating). Defence is calculated by the shield and armour dp modified by the
enemies torpedo accuracy (after base accuracy, comps and jammers are worked
out) if defending vs torps or capital missiles, the effects of double damage
for unshielded targets vs capital missiles and the effects of deflectors
against beam weapons. The attractiveness rating can be change during the
course of the battle as shields and armour deplete. Attractiveness doesn't
take into account the one missile one kill rule, thus chaff has become a
fairly effective tactic.

Battle orders are comprised of 4 parts. A primary and secondary target type,
legitimate races to attack and the tactic to use in battle. Ships will only
attack tokens belonging to legitimate target races, however if another race
present has any ships (including unarmed ships) with battles orders to
attack your race then that race will also be considered a legitimate target.
When attacking ships will try and shoot the most attractive ship of a type
listed as a primary target and if no ships are available which are primary
targets then the most attractive ship of a type listed as a secondary target
will be targeted. Ships which are not listed as primary or secondary targets
will not get shot at, even if they are shooting back.

There are 6 different battle orders which determine the movement AI of the
ships in battle, the movement AI is applied each time a ship wants to move a
square on the battle board.:

Disengage - If there is any enemy ship in firing range then move to any
square further away than your current square. If you are in range of an
enemy weapon but cannot move further away then try move to a square that is
of the same distance away. If you are in range of the enemies weapons and
cannot move away or maintain distance then move to a random square. If you
are not in range of the enemies weapons then move randomly. Also you will
try and disengage which will require 7 squares of movement to be clocked up
before you can leave from the battle board.

Disengage if Challenged - Behaves like Maximise Damage until token takes
damage and then behaves like Disengage.

Minimise Damage to Self - (Not 100% sure on this one) If within range of an
enemy weapon then move away from the enemy (just like Disengage). If out of
range of the enemies weapons or cannot move away from the enemy then try and
get in range of the best available target without moving towards the enemy.

Maximise Net Damage - Locate most attractive primary target (or secondary if
no primary targets are left). If out of range with ANY weapon then move
towards target. If in range with all weapons them move as to maximise
damage_done/damage_taken. The effect of this is if your weapons are longer
range then try to stay at maximum range. If your weapons range is the same
then do random movement while staying in range. If your weapons are shorter
range and also beam weapons then attempt to close in to zero range.

Maximise Damage Ratio - As Maximise Net Damage but only considers the
longest range weapon.

Maximise Damage - Locate most attractive primary target (or secondary if no
primary targets are left). If any of your weapons are out of range of that
token then keep moving to squares that are closer to it until in range with
all weapons. If using any beam weapons (as they have range dissipation) then
attempt to close to 0 range. If just using missiles or torps and in range
then move randomly to a squares still in range.


After the movement phase all ships will shoot their weapons, a token will
fire all weapons from the same slot in a single shot. The weapon slot with
the highest initiative will fire first. If there are two ships with slots of
the same init, then the ships will be randomly given a priority over who can
fire first (which will stick for the entire battle). The rest of the weapon
slots are then fired in init order. Damage is worked out in between each
shot and applied to the ships. If ships or tokens are destroyed before their
turn to shoot then they won't be able to fire back. The movement AI will go
after the most attractive primary target on the board, but if this token is
not in range, then the ship will fire on the most attractive primary target
within range (or secondary if none available). Starbases have a +1 range
bonus to all their weapons (this also gets applied to minefield sweeping
rates), though cannot move. The movement AI doesn't take this bonus into
account when moving ships to close in on an enemy starbase.

Damage for each shot is calculated by multiplying the number of weapons in
the slot by the number of ships in the token by the amount of dp the weapon
does. For beam weapons, this damage will dissipate by 10% over the range of
the beam (for a range 2 beam - no dissipation at range 0, 5% dissipation at
range 1 and 10% dissipation at range 2). Also capacitors and deflectors will
modify the damage actually done to the enemy ship. Damage will be applied
first to the tokens shield stack and then to armour only when the entire
shield stack of the token is down. For missile ships, each missile fired
will be tested to see if it will hit, the chance to hit is based on the base
accuracy, the computers on the ship and the enemy jammers. Missiles that
miss will do 1/8 of their damage to the shields and won't affect armour. For
missiles that hit, upto half will be taken by the shields, the rest will go
to the armour. For capital missiles any damage done after the shields are
taken down will do double damage to the armour. Whole ship kills are worked
out by adding up all the damage done to the armour by a single salvo (from a
token's slot) and dividing this by the amount of armour each single ship in
the token has left (total armour x token damage %). The number of complete
ships the shot could kill will be removed from the enemy token, the rest of
the damage will divided equally among the rest of the ships in the token and
applied as damage. As token armour is stored in 1/512ths (about 0.2%s) of
total armour and not as an exact dp figure (shields are stored as an exact
figure), there may be some rounding of the damage after each salvo (AFAIK
its always rounds up). This fact can be abused by creating lots of small
fleet tokens with weak missiles and many slots, where each slot that hits
will do 0.2% damage to the enemy token even if each individual missile would
do less damage normally (especially the case with a beta torp shooting a
large nub stack).

After all the weapons that are in range have fired, the next round begins,
starting with ship movement.

The battle is ended when either the 16 round timer runs out, there is only
one race left present on the battle board or if there are two or more races
which have no hostile intentions towards each other.

After a battle, salvage is created. This is equal to 1/3 of the current
mineral costs of all the ships that where destroyed during the battle. This
is left at the location of the battle and will decay over time, or if the
battle happened over a planet, then the minerals will get deposited there.

Any races that took part in a battle and had at least one ship that managed
to survive (either through surviving till the end or retreating beforehand)
has a potential to gain tech levels from ships that where destroyed during
the battle. For the exact details of the formulas and chances involved see
the Guts of Tech Trading in starsfaq.com.

--
Rules are written for those who lack the ability to truly reason,
But for those who can, rules become nothing more than guidelines,
And live their lives governed not by rules but by reason.
- James McGuigan

Report message to a moderator

Kotk wrote on Thu, 18 November 2004 12:32

Staz wrote on Wed, 17 November 2004 21:12 Regarding ship movement - does anyone have the first clue what algorithm the Stars! battle engine uses ? Sometimes it's choices seem totally random to me. A search of rgcs seems to indicate that it hasn't been analyzed much, if at all. I just paste here an article i have somehow stored on my harddrive, by great FAQ maker James McGuigan. I think it was in r.g.c.s newsgroup in some movement thread. I am sure that "minimize damage to self" works a bit differently, but for starters it is certainly better than nothing... :

Wow, thanks. That is a lot of useful information.

It doesn't describe movement in the kind of detail I am after, but I don't think anything will.

What I am after is a description that is complete enough that I can write code from it. For a given stack it will have (up to) 8 other squares it can move to. Some of these will be closer to the target, some further and some the same distance. If I know I want to be further away, which of the (generally 3) possible squares should I move to ? Is it random ?

One thing it mentions that I am currently doing differently is that it suggests stacks/slots with the same initiative are ordered randomly (which I suspected), and that the order stays the same for the entire battle (which I had assumed is not the case). This seems a bit unfair - if my colloidal CCs are fighting yours then we'll both have the same range & init and so first shot advantage can be significant and keeping it for the entire battle can be decisive. However, unfair or not, if that is the way it works then that is what I need to simulate.

Report message to a moderator

Report message to a moderator

Report message to a moderator

[Updated on: Thu, 18 November 2004 10:01]

Report message to a moderator

[Updated on: Thu, 18 November 2004 10:10]

Report message to a moderator

Report message to a moderator

[Updated on: Thu, 18 November 2004 22:02]

Report message to a moderator

Report message to a moderator