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 19:45:10 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sat, Feb 23, 2002 at 06:29:10PM +0000, Gregory Berkolaiko wrote:
>  --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
> > On Sat, Feb 23, 2002 at 04:45:46PM +0000, Gregory Berkolaiko wrote:
> > 
> > > 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.
> 
> Mmm, not well enough I am afraid
> 
> > > 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).
> 
> I am not sure why you say this...  Isn't it obvious?
> 
> > Yes the health loss of the units have to be considered. But I see no
> > problem in tracking them.

> On the average -- no problem.  But is average good enough for you?

It has to be since there isn't a feasible alternative.

> And you didn't take it into account in the example you considered

I described the outcome. How the caller will see it. Yes I assumed
that the caller doesn't want to know the hp loss. It has to be
exported if there are caller which want to know the hp loss.

> > > 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.
> 
> but you did multiple attacks.  for most units you'd need more than one turn to
> do that.

Yes it is an extrem case. But this is necessary to show what is
intended.

> > > 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.
> 
> What is your question here?

Will the AI correctly attack even if it knows that the attacker will
be destoryed but has killed pdef2 before?

> > > 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?
> 
> the simulation that IMO is useful to AI is:  what will happen between now and
> next turn.  The decision tree (can be much expanded).
> 
> (1)     attack
>        /      \
>     died      alive
>                 |
>               has moves?
>              /         \
>         goto end        what will we do next?
>                      /         |        |      \      
>                  run away    attack    rest    occupy city
>                     |          |        |          |
>                  goto end    goto(1)  goto end  goto end
> 
> (end) consider possible enemy reprisals until the next turn comes
> 
> The end result would be sturcture with all branches and their probs, list of
> dead units and cities and the resulting HP and status alterations.
> So very much like yours :)
> 
> But I don't think it will be very practical.

Such a tree could be constructed but this is IMHO a layer on top of
the thing I described.

> Ufff, art is so demanding...

;)

> P.S. I think I misunderstood your proposal.  I thought you want to simulate
> further than one turn.

Two or three layers on top of this one: yes.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "Windows is the one true OS. MS invented the GUI. MS invented 
   the 32 bit OS. MS is open and standard. MS loves you. We have 
   always been at war with Oceana."


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