[Freeciv-Dev] Re: multiplayer mode is all that counts

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Thu, 20 Sep 2001, Reinier Post wrote:

> On Wed, Sep 19, 2001 at 10:25:54PM -0400, Daniel L Speyer wrote:
> 
> > I think the general environment might be a set of hooks and scripting
> > actions.
> 
> I'm curious to know what your 'actions' look like.  Before you know it
> they span multiplle client-server interactions, which have been
> stateless until now, and therefore, hard to track.  This is the problem
> Raimar's patches for attributes and 'brackets' try to address.  Do you
> intend to rely on them?

The action I'm presently testing with just gives the player a message
saying that enemy units are sighted.  I plan to write one that takes an
assigned unit, calculates battle percentages, compares them to its orders,
and possibly attacks.  Since the design is pretty extensible, it could
call a lisp or python interperator.

I haven't made any use of states and I don't see what good they'd do.  One
thing a script might do is write other scripts (this would be hidden from
the player, probably), but each script itself responds to one event.

There are potentially real co-ordination problems.  For example, I set my
legion to automatically attack where it can win.  My enemies knights come
by on a road under auto-goto.  My legion steps forth to do battle, and
finds them long gone.  I'm not sure what to do about this, especially
given the possibility of real network lags, but I don't think states would
help.

One possibility would be to put all this into the server, but there are a
couple of problems.  First, IMO, it is very inelegant -- these scripts are
to augment the players, they should be treated like players.  Second,
server-side would open the problems of security.  Auto-goto (a much
simpler routine) allows players to gain improper information.  It would be
very dificult to avoid that with full scripting.  And finally, servers nd
clients would have to hold very tight version coupling to maitain
compatibility.  This would be especially a problem with multi-player
games, which we'll need to do real-world testing.

I'll send out what code I've written as soon as I get it cleaned up enough
that I'm not embarresed to have other people see it :).  Of course, with
this restructuring, we'll probably throw it all out, but as Brooks
said, plan to throw one away, you will anyhow.

--Daniel Speyer
"May the /src be with you, always"


> 
> > I've been working on it for movement of enemy units.  The
> > archetechture I've built is a hooks list in the tile structure.  Whenever
> > the client receives a message that an enemy unit has moved onto a tile, it
> > looks at the tiles hooks and executes them (each hook consists of a
> > function pointer and a data pointer, though the function also receives the
> > co-ordinates of the tile and the unit the moved onto it).  This is a
> > pretty extendable system, and it seems similar to how humans play.
> 
> It seems better to me to create specific contexts for these hooks and
> the code executed on them: agents.  Agents would be created explicitly
> and explicitly subscribe to low-level events.  Low-level events such as
> tile hooks are simply passed on to the agents that are subscribed to them.
> 
> I think this is what Raimar is doing.
> 
> > I think most of client-side AI could be done this way.  There could be
> > hooks for science report, combat, turn start, etc.
> > 
> > What does everybody think?
> 
> I think AIs should be executed in the server to avoid the introduction
> of state into the protocol.  (But I'm not going to code it so don't
> listen to me.)
> 
> -- 
> Reinier
> 
>