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

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

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


-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.