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: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: Jules Bean <jules@xxxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: CSS was: Re: auto settlers rework
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 Jan 2002 09:22:46 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Jan 22, 2002 at 08:44:34PM -0500, Ross W. Wetmore wrote:
> 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.

Possible. My model is a bit different. Everything which can be
computed in a straighforward and deterministic way is computed. For
the rest (the SMA can for example not assess the value of a fortress)
the agent allows external requests with have to have artificial
benefits attached.

In my testing (cities produce only settlers and all settlers were put
under the SMA) the SMA performed quite good. And the integration of
the settler time should make it even better. We may should make a
comparison of an server-AI and the SMA which the constrains (cities
produce only settlers, all settlers were put under the auto-settler
and no enemy).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This message has been ROT-13 encrypted twice for extra security.


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