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

[Andrew Sutton <ansutton@xxxxxxx>]

On Sunday 02 December 2001 03:27 pm, Gregor Zeitlinger wrote:
> On Sun, 2 Dec 2001, Andrew Sutton wrote:
> > an alternative would be to define a separate language that allowed the
> > specification of the extensions and would compile directly into code.
> > however, capabilties are pretty unique and it would probably be pretty
> > hard to generalize. if you think you can figure out how to do it though,
> > i won't complain ;)
>
> This is what I meant with Simkin (simkin.co.uk). It's embeddable in XML
> and has acces to your C++ or Java API.
>
> Founding a city would be something like:
> Here init_unit would be a callbackfunction.
>
> <unit name=settler>
> <snip>
> </unit>

> <unit name=setter>
>   <capabilities>
>     <found_city/>
>   </capabilities>
> </unit>

now that is interesting... i like that idea alot. question: does that build 
into source code or is it somehow interpretted run-time?

either way, using that would provide all the modularistic capabilities we'd 
need. you could use it do define a default catalogue of capabilities, and 
each unit would subscribe to them. alternatively, if you wanted to define a 
completely new capability solely dedicated to a single unit type you could 
inline it in the unit specification, or introduce a new capability for your 
module. i like that alot. good suggestion. this might be the way to go... is 
this the kind of extensibility you're looking for daniel?

the only problem i'm seeing is that the unit to capability mapping is a many 
to many relationship (it always has been). assigning each unit to reference 
its supported capabilities causes a really big memory footprint. the answer, 
then, is to make the mapping of units to capabilities external with a two 
phase lookup (both done in constant time using a map).

i'd like to hear some comments on some other design issues involving units 
and capabilities. so far, here are our basic requirements:
        - a capability is an interface to some unit function
        - a capability is associated with one or more unit types
        - a capability has two types of parameters
        - type parameters are associated with the unit type (e.g. available 
fuel)
        - instance parameters are associated with a unit (e.g. remaining fuel)
        - having each unit maintain its own capability list causes bloat
        - external association of capabilities and type parameters is a two 
step 
constant time lookup
        - units must contain instance parameters as they apply specifically to 
the 
unit.
        - capabilities shall be identified by a unique value.
        - the unique value shall have a constant name, but the actual value is 
of no 
consequence (except that it must be unique).

we have optional requirements (do we want to consider these?)
        - a capability can be associated with a unit (as opposed to unit type)

given these basic features of a capability, lets see if we can't refine the 
framework a little bit and define a nice OO api for allowing a unit to handle 
them. once we have the api, we can throw together a prototype and use the 
simken stuff to see if we can't actuall instantiate some units using the 
extensible capabilities framework.

NOTE: the last two requirements allow a flexible unique identifier 
registration system for capabilities. this allows us to simply define names 
for capabilities in code without having to work with a global capability 
list. it's just as fast and provides dynamic capability/identifier binding at 
run time.

andy