Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: CSS was: Re: auto settlers rework
Home

[Freeciv-Dev] Re: CSS was: Re: auto settlers rework

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jules Bean <jules@xxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: CSS was: Re: auto settlers rework
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Tue, 22 Jan 2002 20:44:34 -0500

At 09:39 PM 02/01/22 +0000, Jules Bean wrote:
>On Tue, Jan 22, 2002 at 08:36:09PM +0100, Raimar Falke wrote:
>> > CSS is a step forward to client side translation, which is a good thing,
>> > too.
>> 
>> Agents won't have to be written in C. But the basic agents we discuss
>> now (CMA, SMA, goto agent, exploring agent,...) have to be written in
>> C or would else need a 10GHz CPU.
>
>I predict that 10 GHz CPUs will be common enough by the time we have
>client-side scripting ;-)
>
>Jules

I don't doubt it :-)

But a better way to go is probably somewhat the opposite of the prevailing
discussion, and maybe more in the line Christian is looking for.

If one worked a little bit on Jason's framework to get a general approach
outlined, but stopped him before he went O(macho x macho) ballistic trying
to get it right.

Then stubbed out a number of RequestEval(action,&time,&benefit,&subReq)
functions that basically just filled in guesstimate hard numbers based
on some quick playtesting no matter how much Raimar winced at the Syela
ugliness of something that is trivial enough not to require "C", or more 
important "C" written in a correct style.

And added a core library with a few information calls that returned game 
data, or perhaps trivially processed game stats (augmented as needed).

Then allowed Christian and his sibling clones to add their own scripted 
code to replace any or all of the stubbed out pieces.

You would probably have a workable prototype-system as good as the current
server AI, or at least with some more playtest optimization as good as. 

Christian and friends would then go ballistic playing with all the
different things they thought would make the RequestEvals more complete,
or more optimal in relation to others by fiddling with the basic weights
and effects scaling.

As long as you could tap in on the activity, you would have a fairly
interesting and steady supply of new techniques and tricks to evaluate
and add to the basic RequestEvals() on an ongoing basis, or hardcode into
rule selectable components that could provide interesting packaged play
styles, or modular sub-assemblies.

In such a system, the strategies and techniques would be developed by a
large number of imaginative minds more concerned with the practical 
results of producing winning strategies. While the more rigorous ones
could work at developing the framework to manage or efficiently exploit 
the various possibilities.

Cheers,
RossW
=====




[Prev in Thread] Current Thread [Next in Thread]