Re: [Freeciv-Dev] Adding scripting language

[Jules Bean <jmlb2@xxxxxxxxxxxxxxxx>]

On Wed, 1 Sep 1999, Artur Biesiadowski wrote:
> Just as a note, to avoid passing many things that might be useful, you
> can retrieve terrain from other source
> - for example
> 
> terrain t = map.getTile(this.x,this.y).getType();

Of course.  That's the conflict between tightly regulated code fragments
with a well-defined interface to the outside world, and totally
interlinked code, where each fragment can potentially access the whole
world state.

I have a personal preference for code fragments with well defined input
and output.  I might not want the getDefenceStrength() routine to have
access to the map object, since that might allow it to things it should
never do.  But I admit my approach is less flexible.

> 
> 
> 
> > But then we have horrible code duplication between units, which makes
> > the ruleset file hard to work with.  Which is where the compiler comes
> > in.  I envisage the compiler meaning that rules files look more like:
> [...]
> I doubt if getDefenceStrength/getOffeceStrength are best places for
> adding scriptin language. I would rather see it as method for executing
> queries (canAttack(Opponent o)), (canSee(Unit u)) and for performing
> actions - like resolveCombat(Attacker a, Defender d).
> Of course there is a problem with making resolveCombat a property of
> unit - because of problems when two units with different non-standard
> routines will fight. This could be solved by either using always
> attacker routine, or giving every such script importance rating - so one
> with higher number will prevail (for example nuke will get higher number
> than anything else - it is not important if you know gerrilla tactics
> against it:)

I'd personally rather see resolveCombat an external function (either in
the C code, or possibly in the scripting language, but certainly not a
method on a unit object).  resolveCombat should call well-defined hooks on
both the attacker and defender object.

> 
> Generally problem of deciding between canSee(Unit u) or canBeSeenBy(Unit
> u) is not so easy. For general OO programming I'll recomend canSee(u) as
> it is active use, but here I'm not sure - from one side superspy is
> easier to implement by canBeSeenBy, but AWACS/spotter better by
> canSee(u)... maybe we will stay with flags for visibility instead of
> scripts :)

That's why I favour another layer of indirection - the compiler.  The
compiler will allow you to describe visibility in the most intuitive way,
and it will generate all the necessary (possibly ugly) code to implement
it.

In a situation like that you describe, I'd bve inclined to make the method
not belong to either object.  So you have canSee(subject s, object o).  In
the bytecode, the code will be an ugly serious of ifs:

if subject is any unit && object is normal unit
  return true;
if subject is normal unit && object is stealth unit
  return false;
if subject is stealth unit && object is stealth unit
  return true;
if subject is normal unit && object is submarine
  return false;
... and so on.

But, in the uncompiled language, we can make this (slightly) more
convenient.

Jules

/----------------+-------------------------------+---------------------\
|  Jelibean aka  | jules@xxxxxxxxxxxxxxx         |  6 Evelyn Rd        |
|  Jules aka     | jules@xxxxxxxxxx              |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@xxxxxxxxxxxxxxxx        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/