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

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 05:26 PM 01/12/04 +0100, 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
>
>For the first you'd need to have a clearly defined API anyway, but we
>already discussed some of that in the syntax discussion.
>
>For the second, the details of interfacing to a specific language vary,
>but again, you'd start with a functional specification of how the game
>engine is exposed to scripts, which would hopefully be language independent.

Yes, this is the appropriate solution path and it is not that difficult.
Some implementations might give you this for free.

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

You should differentiate between creating new objects and new instances of
currently possible objects, maybe.

The former is tricky, because usually a new object requires some new
feature processing code that you would need as well. The latter implies
all the processing capability is there, and you are just providing a
different arrangement of the available features.

So the question is, where do you expect to find/locate any new object 
type feature handling code if you do the former?

>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.
>
>-- 
>Reinier

Cheers,
RossW
=====