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

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 10 Dec 2001, Raimar Falke wrote:

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

I definitely think the code should be changable from the client, to the
fullest extent.  This would include, considering the recent discussion on
handicaps, giving a player an advantage.  Consider: three top ranked
players and one newbie find themselves on the same civserver.  This is
possible, but unpredictible until it happens.  At this time, the advanced
players may decide to give the newbie double firepower.  This is a
legitimate use we should allow, and if we allow this, we should allow
anything.

I would seriously argue that informing all players of rule-changes is
adequate protection.  You can always leave a game if you oponent is too
obnoxious, and there's nothing all that major riding on the games.  I
suppose we might make civserver rankings only effected by games with a
fairly standard ruleset (this might be a good idea anyway).

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


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