AIs and Universal Mod Support
Moderators: hoijui, Moderators
-
tow_dragon
- Posts: 45
- Joined: 05 May 2006, 13:53
AIs and Universal Mod Support
AFAIK all currently developed AIs are trying to support as much mods as possible. Support for mods is reached by simple files with different units lists and numbers. But I realized, that making AI supporting mods with so different playstyles like BA and EE is VERY hard to reach. It will consume significantly more CPU power and memory than AI dedicated for one mod, on similar game level (in other words first AI is as hard to defeat as the second). Afterwards, I made a question: So why to make AI with Universal Mod Support? The only answer I've found is because they are more convenient to use. Next, I looked into TSI 0.12 source. I looked for functions with hardcoded unit names. I found only 5. So, next qestion is: why don't move this functions to another dll, or make more sophisticated configuration files with scripting language. Answer for the second part of the qestion was simple: It consumes much CPU and memory and is difficult. But making additional dll for every mod isn't very difficult AFAIK, and not too expensive. So, why nobody tried to do that?
Not all AI's use config-files to achieve universal support, eg. KAI builds tables on the fly each time it's loaded, as does RAI.
Writing one dedicated AI for each major mod would be logistically more difficult (n times as much debugging/testing/maintaining even if individual differences were small) and there'd always be some unsupported mod or other, plus it would tie specific AI versions to specific mod versions, creating a chaos for users and making the idea generally infeasible.
Writing one dedicated AI for each major mod would be logistically more difficult (n times as much debugging/testing/maintaining even if individual differences were small) and there'd always be some unsupported mod or other, plus it would tie specific AI versions to specific mod versions, creating a chaos for users and making the idea generally infeasible.
-
tow_dragon
- Posts: 45
- Joined: 05 May 2006, 13:53
Making unit tables eats CPU and memory, also. Anyway, I didn't think about making completely new AI for every mod, but only moving some functions (ie. for choosing buildings to build or units for factories) to dll, that would be loaded with AI (Spring loaded helper AIs every time any unit was selected till the newest verion, so it must be cheap). Most of code would be common. And unsupported mods are normal, ie. RAI don't support mods with hubs and comm shooters.
I remember first versions of TSI, that have a lot of code common with SAI. It usually won with any other AI. I think it is the best proof, that hardcoded names could make AI more difficult to beat.
I remember first versions of TSI, that have a lot of code common with SAI. It usually won with any other AI. I think it is the best proof, that hardcoded names could make AI more difficult to beat.
Sounds that could much easier be done by inheritance hardlinked into the AI (as opposed to DLL hell). Scripting or config files would be even better of course, but if you don't want a full scripting solution and still want for example totally different GetNextBuildingLocation() implementation for e.g. E&E and XTA, inheritance is the way to go.
-
tow_dragon
- Posts: 45
- Joined: 05 May 2006, 13:53
Inheritance would be good too, but a small upgrade or bugfix or next release of mod with deleted one unit would push us to release new version of AI (due to static linking of course) instead of few times smaller additional dll. And making dll that loads dll would be a nice lesson for me (I have never done it, only read an article about it).
And one good ai for BA could be reached by recompiling TSI 0.12, for example
.
And one good ai for BA could be reached by recompiling TSI 0.12, for example
.
This is what closestBuildSite() should do. Infact if it worked as it was intended there should be no need for seperate build placement algorithms for XTA and EE style games.still want for example totally different GetNextBuildingLocation() implementation for e.g. E&E and XTA, inheritance is the way to go.
The reason such a distinction has been made is because of a failure to fix a gigantic bug in spring that me and zwzsg have been complaining about for a year and a half that ahs since been noticed as the cause fo a huge list of by product bugs, bugs that ahve interfered with AIs and mods, Arghs also complained about it, and one of [tow] has complained recently in Help & Bugs, Veylon had tow rite long checking routines to prevent OTAI building in factories, and players have long complained to me, krogothe, and veylon about AIs building things in factories, and we tell them its not our fault its a spring bug.
Because of this bug I've had to build my own building placement algorithm just so I can get the proper functionality without closestbuildsite()crippling NTai, and even now I'm encountering issues with lack of AI event support thatll need me to write patches for spring. I need to researc into threading now to prevent huge lagspikes anyway. Any quick links on crossplatform threading? Like the boost threading libraries?
As for universal mod support.
I think dlls is a huge no no. No modder will bother with it. They're already unlikely to fire up notepad and change a few tags in a config thats autogenerated for them. Hence NTai Toolkit.
Universal mod support is perfectly possible. Stuff like buildtables may reduce performance but that doesnt mater because they're only autognerated once when the AI starts. And lets face it, there're other autogenerated files that HAVE to be autogenerated if not already cached at startup that take time. For example KAIs prepathing to generate chokepoints.
So Universal build routines are possible, infact I have a nice class that does a lot of the menial work of picking units form a build tree from generic tags like B_MEX -> armmex thats not very hard to port should anyone want it.
However, configs should exist too. Universal build routines arent always choosing the optimum choices though, and sometimes a human can provide knowledge for the AI. As such the user should be able to configure the AI as bet as possible.
Configurability is the gospel of Argh that got him flamed in the AI forum. Its the stuff that makes NTai as powerful as it is, and whats causes me to get pms at users surprised at just how configurable NTai is.
The issue AI makers have is that everyone seems to pick one or the other rather than a mix of the two.
To that end XE10 will be totally scriptable in lua. Keywords can be created and bound to lua scripts, tasklists can be bound to lua scripts rather than lists of keywords for different types of behaviours, and behaviour models specified, with mix and match behaviours like Dgunning and offensive reclaiming or running away, and even entire modules for controlling things such as custom attack systems. And I hope other AIs follow me in that direction.
Glad you said that. XE9.5 and above use the following generic object type, which will be bound to lua in due time.Kloot wrote:Then why don't you?
Also, an AI that dynamically loaded 'plugins' for each mod defining its behavior would be very interesting, but I still don't think those plugins would be as small as you propose unless you made its design extremely modular (to a degree not yet seen in any existing AI).
Code: Select all
class IModule {
public:
IModule();
IModule(Global* GL);
virtual ~IModule();
virtual void RecieveMessage(CMessage &message)=0;
virtual bool Init(boost::shared_ptr<IModule> me)=0;
bool IsValid();
bool SetValid(bool isvalid);
void AddListener(boost::shared_ptr<IModule> module);
void RemoveListener(boost::shared_ptr<IModule> module);
void FireEventListener(CMessage &message);
};KAI and AAI though have stuck to fairly rigid structures and designs, peefering appending rather than inheritance.
You know better then that...
(Otherwise you would have asked politely whether we knew about it, for example, instead of just spamming the bug report in every thread remotely related to the subject. Or you would have actually put the report in our bug tracker, instead of dumping the same data in random threads like this one.)
Remember that the chance something is fixed is inversely proportional to the amount you whine about it.
Anyway, back on topic.
(Otherwise you would have asked politely whether we knew about it, for example, instead of just spamming the bug report in every thread remotely related to the subject. Or you would have actually put the report in our bug tracker, instead of dumping the same data in random threads like this one.)
Remember that the chance something is fixed is inversely proportional to the amount you whine about it.
Anyway, back on topic.
Since AI's can do it themselfs, it can be said that ClosestBuildSite shouldn't even be in the interface. Every AI has its own small variations in definition of what a good buildsite actually is, and if to take features into account etc. So lets just say its in the interface for backwards compatibility sake and drop the complaining.
