Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2002:
[Freeciv-Dev] Re: Unit-vs-stack sim (was: Cache win_chance)
Home

[Freeciv-Dev] Re: Unit-vs-stack sim (was: Cache win_chance)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Unit-vs-stack sim (was: Cache win_chance)
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 23 Feb 2002 18:48:36 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sat, Feb 23, 2002 at 04:45:46PM +0000, Gregory Berkolaiko wrote:
>  --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
> > On Fri, Feb 22, 2002 at 11:00:45PM +0100, Raimar Falke wrote:
> > > There may be other cases. The function for each case have to answer:
> > >  - how are my chances of success
> > >  - what happens if I win (which units gets destroys, city captured)
> > >  - what happens if I loose (which units gets destroys, city captured)
> > > 
> > > IMHO the best and most flexible solution would be to design a
> > > combat_unit struct which holds the necessary information of a unit for
> > > the combat and use two lists of such pseudo units for simulation. So I
> > > would design something like:
> > >  result_list = simulate(struct combat_unit *attacker_list,
> > >                   int attacker_x, int attacker_y,
> > >                   struct combat_unit *defender_list,
> > >                   int defender_x, int defender_y);
> > > 
> > > and result_list would contain entries like:
> > >  chance=0.90, destroyed_attackers=[], destroyed_defenders=[combat_unit_1]
> > >  chance=0.12, destroyed_attackers=[combat_unit_2],
> > destroyed_defenders=[combat_unit_1]
> > > 
> > > Such detailed analyses is needed IMHO because it may happen that
> > > value(combat_unit_2) >> value(combat_unit_1). So that a chance of 12%
> > > for destroying a mech. inf. (combat_unit_2) with your archer
> > > (combat_unit_1) is very good.
> > 
> > The more I think about it the more I like it. In the following I tried
> > to write down the interface.
> 
> ow-wow-wow, let's calm down.
> First of all, we were talking about passing back an already computed and
> potentially useful value in a simple and straightforward manner.  But
> apperently it does not satisfies us since it too simple and straightforward.
> So the patch is going to be binned.  Fine, this one sorted.
> 
> Now we seem to be diverted to discussion of general unit-vs-stack simulation. 
> Let's change the subject first.... Done.

> Now let's identify the needs: precisely what information are we seeking from
> this potentially very complicated simulation?  How are we going to use it?
> [remains to be filled in]

I think I have described this.

> Now let's identify the potential difficulties:

> 1. Outcome of one attack is already a complicated thing: besides won/lost
> distribution we have a much wider distribution of the remaining health of the
> winner.  It is not hard to compute (it's done in win_chance) but should it be
> stored and used?  Or just a conditional mean(*) would do?

This simulation function will not anything in struct unit. It will
store things in the result structure (comres).

Yes the health loss of the units have to be considered. But I see no
problem in tracking them.

> 2. Outcome of one attack will be affecting the next attack.  If it ever
> happens, because we have one more branch here: what if the defender decides to
> attack us?
> 3. More branching will follow: what if reinforcements arrive to the city we
> are sacking?

We don't know what happens next (neither with the next packet of the
enemy to the server nor in the next turn). This is a simple
function. There will be no intelligence in it.

> What if we are awarded veteran status?

This also has to be considered. Veteran status and health loss effect
the next sub-combats and so needs to be tracked.

> I feel it's enough for now.

> (*) conditional mean: here average health of our unit provided it has won.

Yes something like this.

> The present AI follows a very simple (thus unsatisfactory for some of us)
> mathematical principle: step-by-step maximization.  AI takes an action if on
> average it would be better off after this action (apart from the broken
> auto-attack which I will fix as soon as Raahul supplies me with the promised
> savegame).

How well does it handle unit stacks? Example: pdef1 is a good
defender, pdef2 is an expensive unit, pdef3 is a cheap one. All in a
fortress. The attacker will likely destroy pdef1, will also destory
pdef2 and but will be destroyed by pdef3.

> Sometimes it fails to take into account side effects of the action
> and this should be fixed, but on a lesser scale than trying to 

> compute all possible outcomes for 10 moves ahead.

No. We are speaking about a one-time simulation where the attacker and
the defenders are fixed.

> But maybe we can come up with the algorithm which would go into sufficient
> depth for you and be sufficiently simple for my small brain.  So let's
> discuss.

I'm now not concerned about problems of the implementation (hp and
veteran tracking) but about the interface. The proposed interface
would wrt to my current knowledge be necessary to start coding any
military agents. But will this interface also be good enough to be a
help for the server AI?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We've all heard that a million monkeys banging on a million typewriters
  will eventually reproduce the entire works of Shakespeare.
  Now, thanks to the Internet, we know this is not true."


[Prev in Thread] Current Thread [Next in Thread]