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

[Andrew Sutton <ansutton@xxxxxxx>]

On Monday 03 December 2001 09:31 am, Gregor Zeitlinger wrote:
> yes, thats the where I came to as well:
> So what is it really. Some features which woulde be nice are:
>
> 1) XML embeddable although I think all are if you use CDATA includes
> 2) access to XML values (simkin has already done that, but others could
> access those after they're parsed with DOM or JDOM or whatever)
> 3) cleanliness of syntax
> 4) performance
> 5) ability to extend other modules like classes (I think this would be
> really useful since it would enable you to make cusomized games by writing
> difference rules rather than copying others and then modifying them)
> 6) ease to access the kernel API
> 7) scripting language=kernel implementation language would be useful so
> that modules can be easily in or outsourced for performance or flexibility
> respectively. This is something BeanShell would do, AFAIK
> 8) debuggablity (this is probably a very hairy feature)
>
> There probably more I didn't think of yet and other which will become
> obvious during implementation :)

i'm still not entirely certain we need scripting. i think the requirement 
would be that a scripting engine would have to instantiate objects in such a 
way that the kernel could deal with them without having to call back to the 
scripting language.

for example, if i script a module to register a bombard capability, that 
should be the end of it. the scripting language should create the object or 
whatever data needs to be created and register it. the kernel should never 
call back to the scripting language during game play. this would be a sort of 
fire and forget type language. the problem is, i'm not sure if scripting 
languages can do this... i think the closest we can get is a configuration 
language for runtime attribution of game rules and possibly a buildtime 
descriptor language for building module code that can be built separately. 
i'm probably going to end up being wrong :)

lets get rid of requirements 1 and 2 for right now as those specify a 
particular implementation.

actually, lets talk about a formalization of modules. we could define the 
formal, approved modules to be in c++/java (whichever we choose for 
language), but allow the configuration language to do inline scripting of new 
extensions.

this defines a development process for the introduction of approved 
extensions (something ross wetmore mentioned earlier). so, we can hardcode a 
couple really basic capabilities into a core module and then allow a really 
flexible extension mechanism for the rest.

here's the general development process for module extensions:
1. inline implementation in the scripting language
2. playtest
3. submit
4. approve
5. hardcode feature into a module

this will allow novice users to increment the feature set without having to 
patch the game, while tested and good features slowly (or quickly) make their 
way into the base distribution, allowing other rulesets to incorporate their 
capabilities.

andy