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

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Sun, 2 Dec 2001, Raimar Falke wrote:

> On Sun, Dec 02, 2001 at 03:35:49PM -0500, Daniel L Speyer wrote:
> > On Sun, 2 Dec 2001, Andrew Sutton wrote:
> > 
> > > On Saturday 01 December 2001 07:39 pm, Daniel L Speyer wrote:
> > > > Remember that java can be compiled to native object code (on GNU/Linux, 
> > > > at
> > > > least, using gjc).  I don't know how its performance is that way.
> > > >
> > > > If we look at that sort of massive changes, though, I think we should 
> > > > push
> > > > toward customizability.  It seems to me that units' special powers in
> > > > config files are a pretty ugly setup.  Basically, every special power
> > > > (paradrop, build fortresses...) is written in c, then specified to a 
> > > > unit
> > > > in config.  This makes it impossible for ruleset designers to add or 
> > > > edit
> > > > powers.
> > > >
> > > > I'd like to see a design with the most core/time-critical code in C/C++
> > > > but the bulk of it in freeciv-definition language -- sort of like how
> > > > emacs and mathematica work.
> > > 
> > > i gotta take a break from the language talk :)
> > > 
> > > i think you're right - to some degree. clearly there's got to be a 
> > > separation 
> > > of declaration and instantiation. the declaration defines the 
> > > capabilities 
> > > and the instantiation defines how they're used in a game. i've been 
> > > mulling 
> > > this over for some time, and came to this solution:
> > > 
> > > declaration is performed in modules. for example, unit capabilities are 
> > > written as code and have a couple of associated parameters. each 
> > > capability 
> > > is type static - that is to say that all units of a certain type have 
> > > that 
> > > capability (e.g. setters build cities). parameters come in two flavors: 
> > > type 
> > > static (like before) and instance value. type static parameters define a 
> > > parameter of a capability that is general to all units of a certain type. 
> > > instance value parameters are specific to the units themselves. a good 
> > > example of this is movement. all armor units can move 3 tiles. each unit 
> > > keeps track of how many moves it has left. another good example is ranged 
> > > flight and the dependancy on fuel.
> > > 
> > > this basically means that the data of capabilities is completely 
> > > separated 
> > > from the capability itself, meaning that it is just an interface.
> > > 
> > > there's an option for extending this architecture to allow individual 
> > > units 
> > > to acquire capabilties (instance capability?). this would provide an 
> > > interesting hook for extension. however, as far as i know, nothing in the 
> > > civ 
> > > games does this, so i didn't spend time figuring it out.
> > > 
> > > instantiation comes in the form of a ruleset. a ruleset applies 
> > > capabilities 
> > > and parameters to units. this is actually pretty similar to freeciv1, but 
> > > generalized.
> > > 
> > > for a ruleset to include new capabilities, there will have to be 
> > > supporting 
> > > code. i know, it's not much fun, but that's currently the way it is.
> > > 
> > > 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 last feature is exactly what I was thinking of, though.  Modules move
> > toward it, but think how many cool things could happen (for
> > multiplayer) if it were really easy to write really interesting
> > units.  This would mean interpereted unit capability definitions.
> > 
> 
> > I think the answer is to move all the unit handling code except for
> > the low-level map support into the rulesets.  Each unit would
> > provide its own goto, for example (there would have to be an easy
> > way to assign a standard one to ordinary units),
> 
> I'm still not convinced that this is necessary. Not every user has to
> define another capability. There is no new Civ game every month which
> can provide us with inspiration. IMHO this whole issue is much more
> static that you think.

I've thought of a great number of worlds I'd like to build rulesets for,
but I don't want to go through the work of writing the actions as server
alterations.  There's nothing all that complicated, but learning the
server code and writing in C make it a lot of work.  I'm thinking of
things like Khazad-dum (increases production of all hill and mountain
squares), healer (restores full health to self and all unit on the same
square at the end of the turn), or Avalon Priestess (can paradrop three
squares from a swamp -- OK, so that's a gross misreading of the book, so
what?).

Most of my ideas come from fantasy novels (there *is* another one of those
every month ;) ), but other people could be interested in historical eras
or theoretical devices.  You don't need a new version of enslavedciv to
get ideas from.

I think a lot of people might write interesting rulesets if it were easier
to develop really different units.  When emacs was expandable in TECO, it
was just a text editor.  When RMS expanded it to use Lisp, it became the
mail-reader/adventure-game/psychoanalyst/etc. that we know today.

> 
> Have you looked at how powerful the current ruleset grammar for
> improvements is? The problem here is that these definitions aren't
> interpreted by the code.
> 
> > and we wouldn't have such bug-prone ugliness to handle triremes,
> > planes
> 
> The code has to be somewhere. And especially for goto you want fast
> execution.
> 
> > , etc. (no offense intended toward whoever wrote
> > that code).  For something like this, we would probably want to include a
> > pre-existing language (we'll need real power, in any case).  I would
> > probably recomend python, even though I havn't used it, because it seems
> > to handle dynamicism almost as well as Lisp but has a syntax that's very
> > newbie-friendly.
> > 
> > Another thought is the simkin library (simkin.co.uk) that Gregor
> > mentioned.  It looks really cool, though I haven't had time to really
> > learn it yet.  Admittedly, it would require a switch to either C++ or
> > Java.
> 
>       Raimar
> 
> -- 
>  email: rf13@xxxxxxxxxxxxxxxxx
>  "Your mail could not be delivered to the following Address:
>   VTCMC.VTLPR@xxxxxxxxxxxxx        ** Unassigned error message **"
> 
>