[freeciv-ai] Re: New settler code

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

Mike Kaufman wrote:
> On Mon, Apr 14, 2003 at 01:09:12PM +0000, Per I. Mathisen wrote:
[...]
> > I find arguments like "gee, it would be nice if it wasn't omniscient"
> > totally unconvincing, since this would require a totally different and
> > much more complex settler code, require big changes to the explorer code,
> > and would give dramatically _worse_ results than the current AI.
> >
> > However, if splitting the map will give new features, like supplying
> > explorers with information about city radiuses, then I can be convinced to
> > do so.
> this is kinda what I'm hearing:
>
> Alice: Eventually making AIs for client-side is a laudable goal (and code
>        reuse is a great thing).
> Bob: Well, in principle, yes, but that's a long ways in the future. And 
>      here's some code I wrote that will make continue the trend of making
>      it much harder to reach that goal by giving us a code base that's
>      totally unusable for that goal, and also has tremendous inertia: it'll
>      take 10x the effort to remove it later than to put it in now.
> Alice: Uh, this is not good design principles.
> Bob: That's a totally unconvincing argument.
That's a totally unconvincing scenario ...

But it does show Alice as a pretentious religious bigot with no practical
flexibility or understanding of what she is saying or the impact it has.

And it does portray Bob as trying really hard to do the opposite and make
sure it gets rubbed in, just for the sake of irritating Alice rather than
for any real coding need.

> I'm seeing a "hear no evil, see no evil" mentality regarding client-side
> AI. I'll say it again. I know that server AI will be with us for a long
> while, but that is no excuse whatsoever for writing new code that makes it
> harder and harder to reuse all this work for extending the AI. This is not
> about it being "nice" if it weren't omnicient, this is about a principle of
> a non-omnicient AI.
It would be useful for the server AI to get all its data from a call that
could be made by a client. Indirecting through such a call rather than
directly looking things up in server data structures should be the sort
of incremental change rule that would over time prepare for a real change.

The server should have control over its responses to such calls just as it
does now when it filters client data through the known & seen bits that
implement Fow and basically caused this problem in thge first place.

Beyond this, there is no reason why having the server AI get data from the
real source or some intermediate computation should in any way really change
the basic algorithms it executes. The trick is probably to start making sure
that AI code is robust enough to function in the presences of faulty or
missing data and that this does not seriously impact its overall skill.

Until this is all cleaned up, don't worry about the fact that the AI gets
its data directly from the source and not through a complex and yet-to-be-
developed neural engine with explorer and other unit strategies to improve
its accuracy or some equivalent process.

> of course, I got no response about this. I am wrong? Do you think that
> client-side AI is a pointless goal?
At the moment, it is a project-in-progress and may never bear any practical
fruit. Until it produces something comparable to the serverside AI it will
always be lower in priority, lower in quality and in my opinion higher in
effort required for even low quality behaviour.

Frankly, if I want a playable opponent, I really don't care about how it
does most things at the nitty gritty level, and I'm not willing to wait
ten years for it to happen.

> And let me add that I find the idea of _explorer_ code that requires
> omnicience to be a quite baffling concept.
>
> -mike
The problem is not so much "omniscience" is a sin as the fact that in
applying FoW to make it hard for humans, and not dealing with the
limitations this rule imposed on the AI, one severely unbalanced the game
play and made it totally unchallenging (as well as producing segfaults
in AI code and other minor irritations).

The AI cannot move to a tile it knows is there until it knows the tile
which it needs to move next to to know. This level of abstract thought
and problem solving is trivial for humans but blocked by a lot of the
protections in the code to stop the AI from segfaulting on unknown or
missing data.

Even when you unblock some of the simple mechanical things there is still
a massive effort to develop "memory" in the AI that humans come pre-wired
with. This is because the FoW says you forget you know things by next turn.
That is really hard for an AI that can't make simple assumptions based on
what used to be there because even that is unknown.

There are two fixes. Develop a human level of AI with memory and abstract
fuzzy logic abilities to deal with the FoW problem complete with strategies
to uncover missing data, or provide a practical solution to simulate the
output of this process without getting hung up on just how this output is
obtained.

There are several practical approaches to evolving the AI, i.e. the latter.
The client AI folks should consider how they plan to address the former.
If they come up with a solution it can be rolled back into the server code.


Currently the simulation is to ignore FoW and treat the data as always
accessible, i.e. AI memory and analysis skills are transparently perfect
and it is not particularly limited by FoW..

It would not be hard to add a FoW fuzzy scale that returned results that
were occasionally incorrect, all the way down to the current case for
humans of returning no result, or perhaps more interestingly, random
results, sort of like the rumours that seem to fly in the real world.

If this were a per player scale factor set by the server, then there is
no difference in AI "omniscence" or human "omniscence", i.e. it could be
a parameter assigned equivalently to either as an assistance factor or
reduction of the FoW penalty.

There are other ways to provide such information such as random "news"
events from foreign travellers, possibly with an enhanced refresh cycle
from terrain previously visited or "discovered". Everyone or everyone
through some gossip weighting factor could have access to such common
memory.

What is needed for this sort of AI solution is relatively minimal. It
just needs a mask/weight function in the server code not much more than
the current known & seen bits that the client or AI request for information
is filtered through. In time this function could be replaced or augmented
with caching memory and analysis functionality located at any point along
the data stream. The server could limit an AI visibility to a range around
known territory as part of the fuzz factor as an intermediate solution to
fully-fledged explorer algorithms. As AI sophistication in memory, analysis
and strategies improve the fuzz can go up to human levels.

Anyway, there are solutions, but I suspect that until the problem is
viewed as a practical one (how to achieve a desired effect) and not a
religious one (doing it this way is a sin), this debate will rage on with
its two solitudes never really communicating anything useful to one another.

Cheers,
RossW
=====