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

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

This whole discussion is basically about the fallacy of the typical
"C" programming environment vs other languages that encapsulate data
in an interface that governs how you can change it, i.e. you normally
would not just reach over the fence and update a program game element.

In this case, the game that had rules about when people could receive
cash infusions, or required them to transfer the cash via appropriate
method from an existing protected game source would probably not have 
the problem that a game would where players could manufacture money by 
updating random game data storage.

In fact the Freeciv network protocol is pretty much an implementation 
of the sort of interface that one might consider a reasonable barrier
to such things. In a sense its packets are the assembler representation
of a Freeciv Game language with the packet handler the game interpreter
or method interface to the protected server game data.

There are stupid implementations and reasonable ones. Just because
only the stupid ones seem to be obvious doesn't mean that the problems
have not already been solved to produce the reasonable ones.

Cheers,
RossW
=====

At 08:34 PM 01/12/09 -0500, Andrew Sutton wrote:
>On Sunday 09 December 2001 06:41 pm, Kevin Brown wrote:
>> Reinier Post <rp@xxxxxxxxxx> wrote:
>> > On Sun, Dec 09, 2001 at 02:40:40PM -0800, Kevin Brown wrote:
>> > > My question is: with respect to limiting what the scripting language
>> > > that would be used on the server can do, why do we care?
>> >
>> > You don't want anyone to be able to change the rules of the game without
>> > anyone else knowing.  A scripting language that enables the user to
>> > set his money to 10000 is too powerful.
>> >
>> > > 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.
>> >
>> > No, it won't.  What about a script that makes all units of player Foo
>> > 50% harder to beat 50% of the time?  You don't want to allow rules like
>> > that (not in a ruleset, either).
>>
>> Perhaps, but the language is just a tool that can be used for good or
>> "evil" and the power of the language will affect the abilities of both
>> equally.  So you can reduce the power of the language and make it
>> impossible for, e.g., the unit to set the user's money at 10000 (or,
>> more appropriately, add 10000 to the player's bank), but now you've
>> made it impossible to build a "gold miner" unit, as an example.
>
>i think i'd agree with kevin on this point. the whole point of allowing 
>server-side scripting is to allow a wider range of games - not really 
>dynamically script the modification of rules at run time - that would be 
>disasterous. besides, who would really need to do that anyway? IMO if a 
>scripting language is used, it should ONLY be used to inline extensions in 
>the ruleset configuration.
>
>the "simple" solution to the entire problem would be something along the 
>lines of a ruleset/configuration negotiation phase of the client/server 
>protocol. the client connects to the server. the server transmits the rules. 
>the user sees either the complete ruleset (a la online civilopedia) or maybe 
>just the pieces that have been scripted as a summary of extensions to the 
>game (assuming that official stuff has been compiled).
>
>anyway, if the player sees some configurations he/she doesn't like, they 
>don't have to play on that server.
>
>does that seem like a reasonable solution?
>
>andy
>
>