Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2002:
[freeciv-ai] Re: [Freeciv-Dev] Re: [RFC][Patch] AI can fly v2 (fwd)

[freeciv-ai] Re: [Freeciv-Dev] Re: [RFC][Patch] AI can fly v2 (fwd)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: [Freeciv-Dev] Re: [RFC][Patch] AI can fly v2 (fwd)
From: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 11 Apr 2002 23:32:40 -0500

On Thu, Apr 11, 2002 at 11:35:42PM -0400, Ross W. Wetmore wrote:
> At 08:11 PM 02/04/11 -0500, Mike Kaufman wrote:
> >Ccing freeciv-dev for now until I know core AI group is 'scribed
> >
> >On Thu, Apr 11, 2002 at 07:26:49PM -0400, Ross W. Wetmore wrote:
> >> At 01:07 PM 02/04/11 -0500, Mike Kaufman wrote:
> >> >On Thu, Apr 11, 2002 at 07:36:51PM +0200, per@xxxxxxxxxxx wrote:
> >> >> On Sun, 7 Apr 2002, Gregory Berkolaiko wrote:
> >> The AI program to mimic this is probably a few decades out even at rates
> >> like Moores's Law.
> >> 
> >> Even caching past information is expensive.
> >
> >a possibility would be to give the ai a second map and game struct,
> >which houses educated guesses, about troop concentrations in enemy
> >cities for example. Another example would be seeing an enemy unit coming
> >out of unknown territory and then assigning probabilities about the
> >terrain type (!ocean) to the unknown tiles.
> This is what I call expensive, and a few years out in complexity to be
> of any real utility.

hmmph. Are there any less expensive alternatives besides your "let's
help people cheat" flag? see below :)

> >> A reasonable compromise is to allow the AI to "see" the real map but 
> >> add an error or ai_fuzzy() factor that makes this information less
> >> reliable in locations that are unknown or fogged. For a difficulty
> >> factor you can have the AI fuzz run from 0% (i.e. Mike's favorite
> >> level) to 100% accuracy reflecting a more sophisticated cognitive
> >> ability in a human.
> >yes, yes, but I'm looking at a point in time where the AI doesn't have
> >any choice because it ain't connected to the server. It can only see
> >what it sees. Coding new stuff that takes advantage of the current
> >omniscient ability is not a good plan.
> The server contains a set of model data and some sort of per player
> state (know and seen bits for instance). It sends only certain data
> to the player filtered by these bits. This is the only source of
> player data.
> Toggle an AI flag and the filter bits become fuzzy. 
> Limit AI flag toggling by server control or to players at the end of
> localhost connections only. There are any number of "solutions" to the
> list of followup problems that people that don't like losing arguments
> will probably throw up.

hmm, you mean people like me? Let's not sugar coat the thing here. You
mean to have a flag/command/whatever that lets a client in on the
goodies (meaning server map/game data), right?

If I remember correctly, there has been semi-extensive discussion on the
idea of giving a remote client information like this. I foresee a world
thusly: A machine for a server that controls AI that could very well sit
on another machine[s] to reduce computation load for the server. You
want to demand that we set of some kind of (certainly encrypted)
connection to protect priveleged data from being snooped. I do not like
this Sam I Am. (wait! how about the "honor" rule, we give everybody all
the server data, but trust the non-AI's not to peak ;)

How about instead, we operate under the assumption that the AI has just
as much information that a human player has, and then work on the AI's
strengths, like (ideal): it is always able to look at _all_ the 
information it has. It should be able to coordinate construction better 
than the average human, because it has easy access to completion times.
It shouldn't ever accidently move to the wrong tile (I hate doing that)
and thus lose two turns. It should always pick optimal paths to go
places. Basically it can handle minutiae better than the average human.

> In other words, your point is has validity only as far as you wish to 
> limit the options :-).

I've always disliked games where the AI cheat.

> >> >> - Also in the same savegame, why doesn't solomon invade sooner? It
> cruises
> >> >> around with dozens of transports with units in for dozens of turns
> before
> >> >> it finally decides to land them. Drives me crazy. pille's cities are
> empty
> >> >> and deserted!
> >> >
> >> >yes, I noticed this when I looked at the original patch. AI doesn't
> seem to 
> >> >know when to pull the trigger.
> >> 
> >> You are supposed to be able to determine "flag" presence, so the AI should
> >> know when a town is empty and change its attack computation accordingly.
> >> This should not be a big deal if someone is playing in that code area. It
> >> may be as simple as it never targets towns, just units in find something to
> >> kill, so empty towns are 100% safe if they don't have units as bait :-)
> >
> >whatever it is, the its_time_to_invade() function should be on the
> >todo list.
> >
> >-mike
> Here are some code fragments from advmilitary.c and aiunit.c. I 
> suspect without really having had time to check under the debugger
> that the want "e" is pretty low for empty cities, and kill_desire 
> scales rapidly with heavy defender counts, making heavily defended 
> city targets much more interesting to the braindead AI as Gregory
> partially pointes out :-). 
> The ai.f, ai.a, ai.invasion values do prove interesting as well
> as they are the totals of surrounding unit build_cost and belligerence
> of which there are likely none.

all I can say here is: Petr, Raahul: save me from see damned one letter
variable names, especially ai.a and ai.f!


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