In solution number 1 I set out a modular system that would require the involvement of content developers, but would provide a meaningful structured way for AIs and content to coexist in a lua world. Now I’m about to throw that out the window by presenting solution number 2.
Solution number 2 builds on the variety of pseudo proposals being hinted at by other AI developers, and the general neglect of AI by content developers who would rather do nothing than advertise for an extra person to help with AI (a blogpost detailing this why its happening, and what should be done should be here soon). This solution is that of extreme generics.
For a long time AI developers seem to have thought that the best way was to build algorithms that did all the work. Content developers never got involved and it was all the AI developers responsibility. Since most of the game mechanics were the same they were able to build generic(ish) systems that would manage economy and attacking. These would provide some flexibility and required a lot of effort. They also had an upper limit to their difficulty, a limit one could extend but onyl by improving the algorithms at which point it gets harder and harder.
While NTai and OTAI benefited from strategies that humans thought up that would require a hugely complex algorithm to figure out for itself, the generic AIs were somewhat held back by their lack of generics, because of the consistent game mechanics. Because of this the amount of effort required was scaled back by several orders of magnitude.
So how will solution #2 work?
Here the content developer exposes lists. These lists detail actions that can be taken by a unit, commands, such as change weapon, attack, repair, build, teleport etc. Attatched to these entries are generic identifiers that indicate what kind of command it is, be it an offensive or a defensive or a utilitarian or all 3. A list of things such as resources is also maintained, along with identifiers such as you should have as much of this resource as possible or this resource should be used up as quickly as possible, always keep it at low values.
The AI then attempts to figure out how to use these commands and when they are appropriate. This will require highly generic algorithms that will take a lot of effort. As few assumptions are to be made as possible, and any assumptions that are to be made should be defined using the lists defined by content developers.
These AIs will be very stupid, and will need training to reach a basic level, but I can see that this could be done without content developers lifting a finger. After countless hours of training and additional startegic algorithms to help improve the AIs usage of what it has learnt about the game mechanics, the AIs will finally start to work well, possibly very well. And it is my guess that AI developers will bear the full force of the sheer amount of time and effort required. Should they do this it will be a mighty achievement that will gleam and glitter on their resume.
On the other hand solution 1 would give results much much quicker using far less effort and thus would be a huge competitor at the early stages of such an AI project. As of yet no AI has anywhere near the flexibility to handle this sort of solution. None of the AIs have integrated a ‘concept of command’ that goes beyond the basic error checking, timeout, and caching/buffering that current AIs do to prevent errors and crashes.
Perhaps spring AI developers have been hinting at this and refuse to outright say it. I say they’re somewhat deluded and haven’t really thought it through, but they cant think of anything else at first hand so they are grasping for straws.
This type of AI also appears to be something that would be of great academic interest if written and proven successful. I wish anyone who attempts it good luck, and I end this blog post by pointing out that any concerted effort to build an AI like this would yield lots of generic algorithms to be taken and reused in other AIs and even the spring engine itself.