[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets

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

At 12:25 AM 01/12/04 +0100, Ed Hunter wrote:
>Pasky wrote:
>
>>>well, in the past we would be happy with AI actually relying even on units'
>>>capabs, not on units' types itselves. we successfully have done it, so
>>>well, why don't take another step further, i just wonder how. let's have
>>>e.g. unit Teleporters with A:3 D:1 which is able to teleport anywhere in
>>>range of 5 squares, and it takes it 1/3 of HP. now tell me how to describe
>>>such a capability universally to the AI using rulesets (as i see no other
>>>way how would ai learn about it automagically itself). or if it's too big,
>>>let's take plain goto for plain unit. you didn't listed it in your basic
>>>capabilities, so how you would describe it to "reasonably ideal" ai?
>
>
>Hmm, you would define something like CAP_TELEPORT and make a module for 
>AI to work with it. Since it's a new thing, new part of AI is required.
>
>Jarda Benkovsky

Or you just define your movement system in a sufficiently generalized
way that this is just one parameterization/specialization. The ruleset
just defines the appropriate parameters.

Currently units are constrained (==hardcoded) to only be able to move
to squares that are a distance of 1 away from their current location,
i.e. to adjacent squares. If the system understood a radius parameter
that you set to 5 for Teleporters, they are just IGTER units with a move
radius of 5.

An advanced movement system might consider the current direction units
were facing by remembering the way they entered the square and have an
additional filter that blocked all but the 3 forward directions. There
could be a number of filter shapes. Filters could handle the teleport
case above as well as its shape is a square of dimension 9.

Magic systems, might have a "known location" filter that blocked all
map tiles except those the unit had memorized previously by executing
the memorize location command when they were there.

Basic filter mechanics are pretty simple, i.e. iterating over the 
valid tiles as seen through a filter, the complexity comes in the
types of filters the ruleset might select. 

The AI currently iterates over all possible move destinations, so the
current AI already understands how to use these units once the move
iteration is generalized and moved to a common module or macro rather 
than being hardcoded in various ways throughout the codebase. MAP_STEP 
is a partial attempt in this direction in the current code.

I'm sure that inventive peole can come up with an equal number of
creative solutions to the problem once they learn how to figure out
what the problem is, rather than what the problem with the current 
solution is.

Cheers,
RossW
=====