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

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 3 Dec 2001, Andrew Sutton wrote:

> On Monday 03 December 2001 11:51 am, Daniel L Speyer wrote:
> > 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.
> 
> i agree. if we can find places for extensibility, then we should design 
> accordingly.
> 
> > 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.
> >
> > 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 is a tough problem but lets look at what's actually going be required to 
> implement a scriptable extension. the scripting language is going to have to 
> provide essentially unlimited access to some of the core api's in the game. 
> otherwise, we restrict the capabilities of the unit.
> 
> namely, what we're going to have to do is provide hooks to the map for 
> movement, construction and improvement. provide hooks to a city api for 
> things like stealing inciting revolt and sabotage. a generic player api for 
> things like establish embassy... a unit api for self modification, combat or 
> bribery. i don't think there's going to be anything self-preventative about 
> some of the issues that you describe - it IS a shortcoming of this model.
> 
> if we have to solve this problem, it sounds like we're going to have to 
> implement some kind of security permissions for these resources, and that's 
> not really something i'd like to do.
> 
> on the other hand, this IS the flexibility that we're looking for. it would 
> be nice to define units that have certain capabilities, like turning a land 
> tile into a river tile (canal development?). 

I think the only restriction we need is that connection data, ruler names,
player names, and city names should be inaccessible.  This means that no
unit can give preference to any player.  Writing all access relatively
would disable a few map-hacks, but would mainly be for the convenience of
configurers.

We might want to consider acts which a unit cannot perform (diplomacy?),
but I don't really see a need for restrictions.

> 
> > 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.
> 
> it should, but it might be self-defeating, and almost impossible to 
> implement. we'd have to sit down and figure out all the possible things that 
> we wouldn't like a unit to do and then build in artificial restrictions. 
> naturally some of this information will be limited by the interface design, 
> and i think that's sufficient.
> 
> maybe the thing to do is allow players subscribing to a game to see what's 
> been scripted inline. they can look to see what changes have been made to 
> unit capabilities to decide if this is the game they want to play.

Sure, configuration scripts could be viewable through the metaserver.

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


> 
> there's too many examples of potentially pathological capabilities being good 
> capabilities for other modules.
> 
> does that make any sense? or am i just full of crap :)
> 
> andy
> 
>