Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2003:
[Freeciv-Dev] Re: (PR#4387) The Return of the Rand() Moves
Home

[Freeciv-Dev] Re: (PR#4387) The Return of the Rand() Moves

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: per@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#4387) The Return of the Rand() Moves
From: "ChrisK@xxxxxxxx" <ChrisK@xxxxxxxx>
Date: Wed, 11 Jun 2003 10:08:59 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Wed, Jun 11, 2003 at 09:46:15AM -0700, Per I. Mathisen wrote:
> 
> On Wed, 11 Jun 2003, Raimar Falke wrote:
> > Maybe you can give 2-3 short hints since the archives are big.
> 
> Ok:
>  - It is wrong in principle to have randomness in movement. Very frequent
> atomic actions should be reliable.
>  - You can reliably show in the client the number of turns a goto will
> take.
>  - If you move a "stack" of units, say a charge and a bodyguard, you may
> end up with one of them being allowed to move while the other won't, thus
> splitting the "stack".
>  - Unit rendezvous (eg charge & bodyguard) may fail.
>  - It becomes quite hard for an AI to plan coordinated attacks when the
> ETA of units is not known. A human player can easily improvise, an AI
> player cannot. For example, if the offensive units get there faster than
> the defensive units, you have a problem. This can happen with all of
> best-case, average-case and worst-case pf methods.

We have this move model with a lot of units with 1 MP, and we have roads.
The randomness is the answer to that problem.

So, if a musketeer with 2/3 MP sometimes reach the next tile and sometimes
not, I think its fair. For me, it need not be computable, it is just a game.

When all moves with 2/3 MP fail, this changes a lot in gameplay.

I think there are more things that come surprisingly. AI should be able to
react. When a unit lays back, the other units need to wait.

Stacks have more problems. This is another problem.

Christian

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.



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