This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: AI (very long)
Hans Ronne wrote:
Pathfinding is a good example. Sure you can do a maze-solver, but
terrain can be slow and/or use up fuel - how do you weigh those
consideration against each other when doing A*?
The problem is that the AI can't do basic maze-solving even if these
additional considerations are disregarded. It can't figure out how to walk
around a simple obstruction like a small lake. So I agree with Lincoln that
even a very simple path-finding algorithm would improve AI performance a
lot.
Right now it's supposed to try moving to the side and then going forward
again,
basically a 1-level-of-recursion solution. This is good enough to
handle most
situations, but of course breaks down if you have a long narrow peninsula.
One of the things that dissuaded me about doing full maze-solving but
disregarding the additional considerations is that you could get into a
situation where each unit confidently strides around the shores of a lake
in the desert, and each starves at the same place.
I think the generic AI is always going to be disappointing; it needs
to do rather deep analysis of game designs just to decide how to use
different units (should a floating city with weapons go into combat?
Maybe so, or maybe not). Once you've got past that, then you've
got to do all the usual strategizing algorithms, but parametrized.
So the task is harder than has ever been done for any game system,
but there's no team of a dozen hackers working fulltime for a year
on it.
A key problem is making good estimates of unit values in specific games. It
would be very difficult to write unit worth functions that cover all games
and variants. On the other hand, the game designer usually has a fairly
good idea of what these values should be. So I think the possibility of
using pre-assigned unit worths has some potential. Sort of moving part of
the AI to the game file.
The trick, as we know from the extant experiments, is to know how the
numbers
will affect the AI's behavior! :-) I think it's a bit of a slippery
slope too, because you could have a game where a unit's "construction
worth" should be low early in the game, but higher later on. For
instance, infantry building bases in the standard game works that
way - early on, you don't want to cut into exploration time, but
later you're likely to want bases for repair and resupply. It
really is easier to represent that in executable code than in
integer tables. (GDL could be extended into a full executable
language...)
I think that of the two, it is really the strategy code that is in most
urgent need of improvement. The basic problem, as I mentioned in a post
last week, is that it is very static and fails to reassign units or change
directions of attack quickly enough. One measure of how inefficient the
strategy code is, is that the mplayer frequently looses against its own
lobotomized clone (the iplayer) which contains no strategy code at all.
It would be pretty easy to move theater boundaries just by reassigning
cells from one theater to an adjacent one, although I'm not sure of a
good algorithm for deciding which to shift.
Iplayer wins against mplayer don't necessarily mean that the mplayer
is inefficient, but they do point to limitations. For instance,
the mplayer knows how to explore the world, but once it finds the
iplayer, the iplayer's "mindless" reaction combined with the usual
flow of combat will lead it to the mplayer's home base more quickly
than it would have found it on its own - sounds like a Simons-wandering-ant
situation in fact.
So the useful thought exercise is - when the two sides are deep
into combat, what it is that an mplayer could do to get an advantage
over the iplayer's semi-intelligent but uncoordinated units?
Stan