[Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability and Development]

[Andrew Sutton <ansutton@xxxxxxx>]

On Tuesday 04 December 2001 11:26 am, Reinier Post wrote:
> There are 2 approaches (if scripting runs in the server):
>
>  + extend the server command language to support scripting
>  + expose an API to the gameserver engine to an external scripting language

i'm starting to rethink the idea behind ruleset scripting... the motivation 
is good, but not really practical. the basic idea behind a ruleset is that it 
picks and chooses rules from a predefined set of capabilities. i don't think 
that should change. if you want to add something that introduces something 
completely new, it should be coded. since we're looking at modularity, new 
features shouldn't affect the existing codebase at all.

i think coding features and selecting rules would be a much cleaner 
implementation. besides, then features that want to be integrated into the 
base distribution have to be reviewed.

> If scripts can even introduce new objects, object fields, and associated
> behaviour, this would be very similar to what Andrew Sutton tries to do.

i'd rather do this with code :)

> The whole thing can assume a single-threaded server.
> Anything multithreaded can use the Freeciv network protocol.
>
> The same exercise can be done for the asynchronous, network-based
> interface that Freeciv offers to its clients.  This is what you need
> to do for client-based AIs.  This would mostly be mostly a matter of
> documenting the existing interface.

as a general rule i'd stay away from multithreading in the server/kernel. it 
won't gain any performance issues because there's so much shared data. you'd 
have to lock just about everything... threading also decreases portability.

anyway, it's not hard to write a completely async network layer without 
threads (its even easier with ACE - but i'll try to shut up about that now ;)

andy