Re: [Freeciv-Dev] Adding scripting language

[Artur Biesiadowski <abies@xxxxxxxxx>]

Jules Bean wrote:

> > My proposition is to add can_build array to city and send it with city
> > data - filling on server with results of all can_build routines. It
> > shouldn't be problem for network traffic (bitfield will maybe 20-30
> > bytes and city packet is few times larger), but I'm not sure how it will
> > affect cpu usage - after all a lot of scripts will have to be run every
> > turn for every thing that changes state.
> 
> True.  It is for this reason that I favour a 'partially compiled'
> language - like perl or java - since they tend to run faster.

AFAIK, guile also compiles every function to fast bytecode or even
native code after first run. But sure java can be faster with all these
modern jits etc.

As far as footprint is concerned, guile uses about 2M of memory. I think
that it is reasonable amount - server in late game uses as much as
10-14M alone.
I'll check few java vms without awt, to see how mych mem they do use.



> # Phalanx again
> getDefenceStrength(Opponent o,Terrain t) {
>     if (t == mountains) {
>         return 6;
>     }
>     if (t == forest) {
>         return 4;
>     }
>     return 2;
> }

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();



> 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:)

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 :)

Artur