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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Dec 09, 2001 at 02:40:40PM -0800, Kevin Brown wrote:
> Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, Dec 04, 2001 at 11:01:54AM +0200, Petrus Viljoen wrote:
> > > > > > 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?
> > > >
> > > 
> > > Don't think the current scripting engines support time-outs etc..
> > > You will most likely end up with depleted memory or a thrashing garbage 
> > > collector.
> > 
> > Well at least the lpmud engine had such an feature. CPU time was
> > limited as well as array size.
> > 
> > > Why do you want to make the rulesets & units extensible via scripts.
> > > 1. You are asking for someone to hack/cheat
> > 
> > > 2. If you have a script to configure a unit you can just as well
> > > have C code in the server to configure the unit (This will be safer
> > > and better controlled)
> > 
> > Ack.
> > 
> > > 3. I for one am not going to check all the Scripts before I start a
> > > Game.
> > 
> > This would be the conclusion. I see a server command which prints the
> > md5 of the whole ruleset used ;)
> > 
> > > Data driven configuration is
> > > 1. Safer
> > > 2. Easier to manage.
> > 
> > Ack.
> > 
> > > IMHO the only place scripts make sense is personalized customization
> > > of clients (agents, unit, city behavior/management).
> > 
> > Ack everything at the client side is uncritical in this respect.
> 
> I'm a little late to this discussion, and may not be as familiar with
> some of the problems as others, so please slap me if I'm full of shit.
> 
> My question is: with respect to limiting what the scripting language
> that would be used on the server can do, why do we care?
> 
> I mean, this is the *server* we're talking about here.  If someone
> decides to run a server that includes units that favor one player over
> another (as an example), that server will become unpopular very
> quickly.  Problem solved.
> 
> What I'm getting at is that it DOESN'T MATTER if people egregiously
> hack on the unit code, because 

> they can't submit it remotely to the server anyway

And that is true today but maybe not in the future. There are people
which what to unify the ruleset and server commands. This plan
includes the ability to change unit data (which may include code)
remotely from the client.

> -- they have to actually be in control of the server,
> and if that's already the case then no amount of protection in the
> scripting language is going to help.
> 
> So we're a lot better off making the server-side scripting language as
> flexible as possible.  That means exposing all information available
> in the game to the unit code.  Just because you can't envision a need
> for some information to be available to the unit doesn't mean that it
> won't be legitimately useful to someone writing a unit's code later
> on.
> 
> 
> So what's left?  The client: which is a completely separate problem.
> So separate, in fact, that the only thing that matters is that the
> client and server agree with each other on how to refer to the various
> game elements.  In short, once they're talking the same "language" to
> each other, anything goes.
> 
> And yes, the AI should be a pure client in theory.  Problem is, I
> don't know how challenging you can make the AI if it's limited to
> seeing what a normal player would see.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  What's nice about GUI is that you see what you manipulate.
  What's bad about GUI is that you can only manipulate what you see.