request for new patch: an ai that can learn

[lch]

I seriously doubt that JK would allow any external library linking for security reasons alone. And this would only be for the real cracks that know how to use it. AI's that can be scripted were already on my wish list, too - just so that people realize that developing an AI is really hard work.

Seriously, somebody who suggests learning AI's and thinks that they'll be going to outperform specifically designed AI's probably doesn't have much experience in that field. The idea does look nice on paper, but already for simple games the training of the AI takes considerable time. Thousands or ten thousand games at minimum to have a somewhat bearable AI that probably still sucks and isn't very competitive. Even if the whole Dom3 fan base would submit their entire games this would take dozens of years. And don't forget that this game is far away from being simple. There are so many shortcuts in the game and combos that depend on details which a statistical model would either ignore as singular peaks or try to use them in situations where they do not work for it. A statistical model would probably go for the "good for most situations" choice which usually is quite poor in a specific situation.

Giving the AI some ideas what would be best to build, cast, etc., some sort of "sugar", would probably be the easiest to achieve and the most effective. The format could be somewhat similar to what the RanDom project is using for provinces.

[Gandalf Parker]

I hope I didnt give the impression that edit of trn/2h was my preference. I was only saying that its closer to a possibility than many think.

Id just rather that the game allowed a full text mode for play. That just means that for every non-text input (such as mouse selection) there is a matching text input. And that all actions have a text output. 80% of it is already in place.

That would allow the most options for AI thru the most methods (the most OS's, and the most scripting ot programming languages) including someone developing a dll, or a lib, or a api, etc.

[Taqwus]

There are fairly obvious data protection issues -- notably, providing an object that encapsulates *just* the information 'legally' accessible to the AI; and which provides no write-access, just a structure for queuing orders (incl. 'instant' orders like equipment moves or alchemy). It would be up to the implementation to cache historical data.

As for complexity, it would be incredibly complicated given the sheer variety of options.

Example domain where traditional AI techniques can work pretty well: driving on an empty road, maintaining lane position. The input (typically low-resolution imagery) is relatively constrained; edge-detection for the lines is reasonably well-understood; the state does not normally radically shift due to previously hidden information; and the controls (actuators) are relatively few -- steering, accelerating, breaking, shifting -- and responsive (less need for long-term planning). Credit assignment problems are usually minor.

Complex multi-player games with vast amounts of hidden information, mandatory long-term planning as some things take a long time to pay off, high randomness and configurability, and a ridiculous number of options are not easy to automate. It's difficult when it's not even obvious -why- one won or lost (credit assignment). This why AIs for even simpler games like GalCiv cheat like hell.

(Ex -- GalCiv knows where all the yellow suns are. These have the best colonization opportunies, thus eliminating much of the exploration problem. The game also cheats by biasing "random" events against the leaders. This is despite the far lower complexity. The whole Civ series is notorious for AI cheating -- ex. AIs trading tech with each other for a pittance compared to what they'll accept from any human, knowing where you are, knowing exactly what tech you have, etc -- and, if memory serves, punish-the-leader adjustments. And so forth.)

[Gandalf Parker]

Taqwus said:
There are fairly obvious data protection issues -- notably, providing an object that encapsulates *just* the information 'legally' accessible to the AI; and which provides no write-access, just a structure for queuing orders (incl. 'instant' orders like equipment moves or alchemy). It would be up to the implementation to cache historical data.

Ive seen mud-bots do a really decent job. Almost Turing level.

If a game can provide and receive information in text mode then a bot can be programmed to play. It is a program, playing as though its a human player. It gets no info that a human wouldnt get, and has no actions that a human doesnt have. Im not sure how well it can be made to play but at least it would toss the AI problem into many hands who could collectively decide that AI's for Dominions is not as easy as some make it sound

[MaxWilson]

Gandalf Parker said:
Id just rather that the game allowed a full text mode for play. That just means that for every non-text input (such as mouse selection) there is a matching text input. And that all actions have a text output. 80% of it is already in place.

That would be really nice for reasons which have nothing to do with AI. A lot of the pain of scrolling long spell lists or message lists would be alleviated if you could just remember that Communion Master, for example, is four PageDowns into the spell list, instead of grabbing the scroll and sliding it down. (Of course it depends upon paths and current research level.)

-Max