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

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 3 Dec 2001, Raimar Falke wrote:

> On Mon, Dec 03, 2001 at 09:42:10AM -0500, Daniel L Speyer wrote:
> > On Mon, 3 Dec 2001, Raimar Falke wrote:
> > 
> > > On Sun, Dec 02, 2001 at 06:18:47PM -0500, Daniel L Speyer wrote:
> > > > 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.
> > > 
> > > Ok. So there is some creative power ;)
> > > 
> > > To the implementation: this requires work (you have to teach the AI
> > > about the healer) and IMHO it makes no real difference where and how
> > > you write the code. You may however say that you don't provide AI
> > > support. Than it will become much easier. So easy that you can write a
> > > straight forward <100 lines patch to the current code.
> > 
> > That's not so easy.  Ignoring AI, here is my lisp code for a healer:
> > 
> > (setq healer (make-object 'attack 0 
> >                           'defend 1 
> >                       'move 2 
> >                       'ignore-zoc t 
> >                       'max-health 10))
> > (setf (get-object healer 'done-hook)
> >       #'(lambda (me)
> >       (mapcar 
> >        #'(lambda (x) (setf (get-object x 'health) 
> >                            (get-object x 'max-health)))
> >        (get-unit-list (get-tile me)))))
> > (create-unit healer)
> > 
> > Now that's pretty short and easy (took me <5 minutes), and it handles (I
> > think) all cases.  Plus, it can be written in a config file and loaded at
> > runtime -- no downloading sources, no recompilation.
> > 
> > Now suppose I had written this is in C/config-file like is done now.  I'd
> > have had to add a flag 
> 
> > (how many of those do we have left anyway?)
> 
> Yes we may run out, but this isn't and shouldn't be the problem.

Hinging a potential customizability on a limited resource is not good
design.  We don't want to run up against this just as custom rulesets get
popular.  We've already run into this with nations (which we allow far
more of, IIRC), and (I suspect) are losing potential developers beause
their work can't be included.  

> 
> > and then written code that looped through all units at the end of
> > each turn checking for the flag and doing the same logic -- except
> > that I'd have to constantly watch for bounds overflows, null
> > pointers, and general low-level bugs.  I tried briefly to write the
> > relevant C, but realized I would have to look up to many
> > header-files and gave up.
> 
> About lisp vs c: the lisp solution isn't this easy: when will it be
> called? 

There can be a small list of hooks, such as move, turnDone, attacking,
attacked...

> How do you prevent that somebody doesn't to an endless loop
> there? 

Well, with a good enough forall, a non-infinite-looping language might be
adequate here (it's very theoretically limited, but I don't think we need
that much power).  Alternatively, kill the script if it doesn't terminate
within some time limit.

>How do you prevent somebody from manipulation? Consider this
> under the situation where server variables and rulesets are unified
> and every player can enter extra code for certain units. And there is
> a "if(player_name=='foobar'){hp*=1000;}" well hidden in a 30 line code
> fragment.

Hmm, this is a difficult problem.  I don't think checking all modules
through a central maintainer is the right approach, though.  There should
be some sort of sandboxing.

Now we want to allow things like 
waterElemental.moveHook={if isRiver(getMyTile()) fp=2; else fp=1;}
but we don't want to allow your example.  The first thing to do is to
disallow access to player names.  There are ays around this, though, so
let's see:

Disallow all player info -- unit scripts can't access names, IPs,
cmdlevels, etc.

Make everything relative to the unit (i.e. set the map-grid to 0,0 at the
unit, players are simply 'self', 'allied', 'neutral', 'war', or 'no
contact'...)

Disallow access to easily alterable data (e.g city names)

This should cut out straightforwardly dishonest scripts.  Now it's still
possible to set up some unintuitive key to increase power, but this really
blurs into legitimately weird setups.  If we use a highly newbie-readable
language (I guess not lisp) and let any player read any script, we can
highly disourage dishonestly pathological scripts.

--Daniel Speyer
"May the /src be with you, always"

> 
> This is nothing against this in general. I want to just point out that
> it isn't _this_ easy. And yes you can write shorter programs in other
> languages.
> 
> > Would you have accepted such a patch anyway (seeing as it would slow
> > things done, maybe have bugs, use up a flag, and only benefit
> > players of a couple of rulesets)?
> 
> Good question. Try it out.
> 
> > We all know that C is a slow language for development, and getting into
> > the guts of freeciv with no abstraction slows things down too.  For
> > players with no local tree full of .o files, it's a twenty-minute
> > recompile, as well.  To get general usability, it's a several day
> > clean-up/submission/waiting-for-acceptance process, followed by a
> > several month waiting-for-others-to-upgrade-process.
> > 
> > This is why language matters.
> > 
> > P.S. I made up the lisp object syntax.  There's a real one out there, but
> > I figured we're probably not using lisp, so it doesn't really matter.
> 
>       Raimar
> 
> -- 
>  email: rf13@xxxxxxxxxxxxxxxxx
>     1) Customers cause problems.
>     2) Marketing is trying to create more customers.
>   Therefore:
>     3) Marketing is evil.
>