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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Dec 03, 2001 at 11:51:50AM -0500, Daniel L Speyer wrote:
> 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.  

There is a patch and it _will_ be included before the next version. If
we run out of flags (currently 28) we will expand it to 64 or 128.

Also note:
1.16         (freeciv  30-Jan-99):   F_CARAVAN=0,
1.16         (freeciv  30-Jan-99):   F_MISSILE,
1.16         (freeciv  30-Jan-99):   F_IGZOC,
1.16         (freeciv  30-Jan-99):   F_NONMIL,
1.16         (freeciv  30-Jan-99):   F_IGTER,
1.16         (freeciv  30-Jan-99):   F_CARRIER,
1.16         (freeciv  30-Jan-99):   F_ONEATTACK,
1.16         (freeciv  30-Jan-99):   F_PIKEMEN,
1.16         (freeciv  30-Jan-99):   F_HORSE,
1.16         (freeciv  30-Jan-99):   F_IGWALL,
1.16         (freeciv  30-Jan-99):   F_FIELDUNIT,
1.16         (freeciv  30-Jan-99):   F_AEGIS,
1.16         (freeciv  30-Jan-99):   F_FIGHTER,
1.16         (freeciv  30-Jan-99):   F_MARINES,
1.53         (dwp      06-May-00):   F_PARTIAL_INVIS,    /* Invisibile except 
when adjacent (Submarine) */
1.42         (jjm      27-Dec-99):   F_SETTLERS,         /* Does not include 
ability to found cities */
1.16         (freeciv  30-Jan-99):   F_DIPLOMAT,
1.16         (freeciv  30-Jan-99):   F_TRIREME,          /* Trireme sinking 
effect */
1.16         (freeciv  30-Jan-99):   F_NUCLEAR,          /* Nuclear attack 
effect */
1.16         (freeciv  30-Jan-99):   F_SPY,              /* Enhanced spy 
abilities */
1.18         (freeciv  12-Feb-99):   F_TRANSFORM,        /* Can transform 
terrain types (Engineers) */
1.34         (sebauer  12-Sep-99):   F_PARATROOPERS,
1.39         (sebauer  20-Sep-99):   F_AIRBASE,          /* Can build Airbases 
*/
1.42         (jjm      27-Dec-99):   F_CITIES,           /* Can build cities */
1.44         (jjm      10-Mar-00):   F_IGTIRED,          /* Ignore tired 
negative bonus when attacking */
1.53         (dwp      06-May-00):   F_MISSILE_CARRIER,  /* Like F_CARRIER, but 
missiles only (Submarine) */
1.53         (dwp      06-May-00):   F_NO_LAND_ATTACK,   /* Cannot attack vs 
land squares (Submarine) */
1.4          (rfalke   28-Aug-01):   F_ADD_TO_CITY,      /* unit can add to 
city population */
1.5          (rfalke   08-Sep-01):   F_FANATIC,          /* Only Fundamentalist 
government can build

So it looks like there are 3 flags added per year. I wonder why this
should change suddenly.

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

Multi threading or will the interpreter provide this feature?

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

So we agree that there is no general technical solution. Think about

"if(path_gone==[n,n,s,s]){ give_super_power}" or 

"if(get_tile(nw).has_road() and 
    get_tile(ne).has_road() and 
    get_tile(s).has_road() and 
    get_tile(n).has_a_city())
  { give_super_power}"

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "brand memory are for windows users that think their stability
   problems come from the memory"
    -- bomek in #freeciv