AIs that require config files are serious usability problems
Moderator: Moderators
AIs that require config files are serious usability problems
Trying out a practice game vs bots is a serious challenge to new users.
For most users, their sole experience with AAI is to cause an instant crash during single player. They have no information about which AI is better, so they just pick the one at the top. Unless the mod ships a config file, they're doomed.
This seems like an easily solved problem. We could easily have a bit for "AI requires config file" and then teach unitsync how to check for that. Then the lobby could in turn hide all the AIs that would cause instant crashes upon startup.
Do this one simple thing and you make it about twice as likely that a new unguided user will become a regular Spring player.
For most users, their sole experience with AAI is to cause an instant crash during single player. They have no information about which AI is better, so they just pick the one at the top. Unless the mod ships a config file, they're doomed.
This seems like an easily solved problem. We could easily have a bit for "AI requires config file" and then teach unitsync how to check for that. Then the lobby could in turn hide all the AIs that would cause instant crashes upon startup.
Do this one simple thing and you make it about twice as likely that a new unguided user will become a regular Spring player.
Re: AIs that require config files are serious usability problems
Do any AIs legitimately need a config files? I believe AF has said that everything in the AAI config file is available from the interface, just no one has bothered to change AAI.
Re: AIs that require config files are serious usability problems
NTai needs a configuration file if I recall. AF said that about AAI to me as well, though, Lurker.
Re: AIs that require config files are serious usability problems
Not ALL that AAI needs is available from interface. Well, it may actually be all for BA, but surely not for (at least some) other games. For example, AAI will never use a unit that has workerTime>0 as an attacker unless told so through config. Or, if a game uses weapon range, cost or speed scales vastly different from those of TA, AAI will get seriously confused about unit roles.
Re: AIs that require config files are serious usability problems
Failing to fail gracefully.
If submarine had taken notice of my failing gracefully thread, then AAI would crash gracefully, and the problem of no config file or unsupported mod would be caught, AAI would tell the user the game was unplayable and perhaps displayed a countdown followed by a self destruct to prevent the player taking the game further, or even redisplaying the message at half minute intervals.
Sadly submarine isn't as active as he used ot be and can sometimes be ideologically opposed to say me or others, which is common in AI here, and can make thigns interesting.
In NTai I attempted to solve the no-config problem by testing if a configuration file existed, and providing a generic fall back configuration file. It may not have played as well as a specific configuration file, but it worked under some mods.
Regarding blacklists and whitelist:
They should not be absolutist. We should define what mods ( including version nubmers) definately work and which definately do not, but everything else should be a gray murky area. Sort fo like doesntwork/limited/normal/recommended, where normal is the default unless an AI dev specifies otherwise.
These should be AI side not mod side, for the following reasons:
Regarding AAI:
AAI configuration files have a number of values, not as many as other AIs, but some of these values can be ifnered or obtained directly fromt eh interface.
Examples include:
If submarine had taken notice of my failing gracefully thread, then AAI would crash gracefully, and the problem of no config file or unsupported mod would be caught, AAI would tell the user the game was unplayable and perhaps displayed a countdown followed by a self destruct to prevent the player taking the game further, or even redisplaying the message at half minute intervals.
Sadly submarine isn't as active as he used ot be and can sometimes be ideologically opposed to say me or others, which is common in AI here, and can make thigns interesting.
In NTai I attempted to solve the no-config problem by testing if a configuration file existed, and providing a generic fall back configuration file. It may not have played as well as a specific configuration file, but it worked under some mods.
Regarding blacklists and whitelist:
They should not be absolutist. We should define what mods ( including version nubmers) definately work and which definately do not, but everything else should be a gray murky area. Sort fo like doesntwork/limited/normal/recommended, where normal is the default unless an AI dev specifies otherwise.
These should be AI side not mod side, for the following reasons:
- Normally the AI developer knows which mods definately work
- AI projects have a faster turn around than mods. A mods black list si more likely to eb outdated by the time a new version is released than an AI
- Redistributing a mod every time an AI changes is problematic, redistributing an AI is nto as that update would likely include bugfixes due to the faster pace of AI development.
- It would be bad for a BA 9.06 9.061 9.062 9.063 where all of them do not sync, yet the only difference is a changed AI white/black/list. This would be chaotic and problematic
- Mods which do not update their blacklists are a headache
- AIs that change their blacklists are easier to distribute and maintain and do not need to be synced
Regarding AAI:
AAI configuration files have a number of values, not as many as other AIs, but some of these values can be ifnered or obtained directly fromt eh interface.
Examples include:
- How many factions a mod has
- What the commanders are called
Re: AIs that require config files are serious usability problems
Uh, I'd say the opposite, frankly.
I'd rather say, "these AIs are never, ever going to work with P.U.R.E. (i.e., all of them that aren't null, ATM), so dear end-user, don't even bother."
I mean... AI developers have faster turnaround times, sure. But it's meaningless.
The only active ones are only working on AIs that work with BA, other than C.R.A.I.G., which currently only works with S'44. I've given up trying to bitch about this, I will eventually find the time to write a general-purpose AI structure in Lua, and then completely forget about the C++ AI people, frankly.
It'd be much more honest if we just told end-users that they're hosed, instead of them having the "it just sits there" problem or insta-crash, which makes us all look like idiots... but mainly gets blamed on the game developer.
I was peeved enough about this issue that I just removed all of the non-null AIs from P.U.R.E. installers, frankly, rather than have somebody have a bad experience because of somebody else's incompetence. It does not take a lot, to write some logic where if it doesn't find Value A, it then politely terminates the software, with a message to end-users.
I'd rather say, "these AIs are never, ever going to work with P.U.R.E. (i.e., all of them that aren't null, ATM), so dear end-user, don't even bother."
I mean... AI developers have faster turnaround times, sure. But it's meaningless.
The only active ones are only working on AIs that work with BA, other than C.R.A.I.G., which currently only works with S'44. I've given up trying to bitch about this, I will eventually find the time to write a general-purpose AI structure in Lua, and then completely forget about the C++ AI people, frankly.
It'd be much more honest if we just told end-users that they're hosed, instead of them having the "it just sits there" problem or insta-crash, which makes us all look like idiots... but mainly gets blamed on the game developer.
I was peeved enough about this issue that I just removed all of the non-null AIs from P.U.R.E. installers, frankly, rather than have somebody have a bad experience because of somebody else's incompetence. It does not take a lot, to write some logic where if it doesn't find Value A, it then politely terminates the software, with a message to end-users.
Re: AIs that require config files are serious usability problems
The ingenuity of AI developers, and their capacity to keep trick cards up their sleeves is enormous argh. Ai development here has not long started firign up, the initial fruits have barely begun to show. Do not be so quick to judge generation C by generation Bs work beore they've come to fruition
Right now the only fruit that has been born of the new generation of AI development is E323AI, imbaczeks AI, and hugh perkins AI, both of which are in very early development stages, and their codebases are barely mature. There are many projects which have yet to even announce themselves and make a release.
Right now the only fruit that has been born of the new generation of AI development is E323AI, imbaczeks AI, and hugh perkins AI, both of which are in very early development stages, and their codebases are barely mature. There are many projects which have yet to even announce themselves and make a release.
Re: AIs that require config files are serious usability problems
I know that. But you've gotta understand... on this issue, all I can judge is past performance, and that's fairly sobering. 5 years of AI development, and for well over 90% of that entire time, every single game I have been building has been un-supported by every AI. There were about 6 months where RAI supported early versions of P.U.R.E., but it quit doing so.
So, instead of even having rudimentary AI support to do testing with, I have to use my Skirmish module, which is a piss-poor excuse for an "AI", but it doesn't just sit there or crash the engine.
Even NanoBlobs makes most AIs crash, on this engine atm. I'd rather that end-users didn't even see them as an option in the Lobby or in the engine.
So... if you're predicting that the situation's going to get better... well, we'll see. But for now... I'd rather see a blacklist implemented, and let AI developers contact game designers directly, should they wish to support their games, instead of the current situation, where game developers are basically supposed to chase AI guys around, if they're idiots and won't fix their AIs when they crash when tested... which is usually 100% futile, since they're building AIs for their own fun, for school, or whatever, and have almost zero reason to be helpful.
So, instead of even having rudimentary AI support to do testing with, I have to use my Skirmish module, which is a piss-poor excuse for an "AI", but it doesn't just sit there or crash the engine.
Even NanoBlobs makes most AIs crash, on this engine atm. I'd rather that end-users didn't even see them as an option in the Lobby or in the engine.
So... if you're predicting that the situation's going to get better... well, we'll see. But for now... I'd rather see a blacklist implemented, and let AI developers contact game designers directly, should they wish to support their games, instead of the current situation, where game developers are basically supposed to chase AI guys around, if they're idiots and won't fix their AIs when they crash when tested... which is usually 100% futile, since they're building AIs for their own fun, for school, or whatever, and have almost zero reason to be helpful.
Re: AIs that require config files are serious usability problems
NTai supported nanoblobz without crashing, though performance became the issue after a while ( but it was the same wether you had an AI running or not).

There was a time when almost all games in spring had support from AIs and the rest had partial support. Put simply, native AI development crashed and burned.
What we had is a long period of selective pressures against developing AI at all, which have now recently been lifted.
You cannot expect instant mix, for AIs to suddenly come out fo the woodwork all full developed and supporting every single game. That takes time, time that hasn't yet passed, and to say what your saying is counter-productive and shows just how little you've been paying attention to some of the projects that have not made releases yet, or even to my own plans.
There was a time when almost all games in spring had support from AIs and the rest had partial support. Put simply, native AI development crashed and burned.
What we had is a long period of selective pressures against developing AI at all, which have now recently been lifted.
You cannot expect instant mix, for AIs to suddenly come out fo the woodwork all full developed and supporting every single game. That takes time, time that hasn't yet passed, and to say what your saying is counter-productive and shows just how little you've been paying attention to some of the projects that have not made releases yet, or even to my own plans.
- Attachments
-
- screen061.jpg
- (109.07 KiB) Downloaded 193 times
Re: AIs that require config files are serious usability problems
Look, the problem with the whole, "stuff is coming" thing is that there's no proof on the table, vs. 5 years of AIs that behave badly with variant gametypes and completely arrogant or completely ignorant AI developers blithely ignoring the game developers, and basically creating an adversarial situation here.
And it's really stupid, putting game designers in a position where if an AI developer is screwing with them, or breaks AI support for their game next release because they're not bothering to test their product with anything but BA, they cannot fix the problems. Which has been the case for the last 5 years, with only the NullAIs allowing for Lua control (a fairly recent phenomenon) finally breaking the pattern.
One way to establish more trust and cooperation between the two camps right away would be to have AI developers write or port existing core modules for certain tasks, such as metal-analysis and terrain algorithms... and put them into an "AI support" DLL, where Lua AIs can use callouts that only work if those DLLs are present.
I.E., build an AI whose main logic is Lua, but whose analysis logic is compiled for speed. Then Lua AI development would be the norm, other than people wanting to work on the ultra-high-end stuff like pathfinding and analysis algorithms. Of couse, that would require AI developers working on such algorithms to work in an Open Source fashion, which some may not want to do, but they can just work on BA stuff or whatever.
Lastly, Tobi said he was going to refactor C.R.A.I.G. early this summer, and told me that I probably didn't want to sit down with it until it was done, but I haven't ever heard back from him about whether or not it got done, so I assume that it hasn't and that I'll just have to do it myself.
If I have to address this entirely myself, I'll do it, though. It's just like the graphics stuff- my frustration level's high enough that now that I'm not under deadline pressure, and the tools exist to address the problems... I'll find a way.
And it's really stupid, putting game designers in a position where if an AI developer is screwing with them, or breaks AI support for their game next release because they're not bothering to test their product with anything but BA, they cannot fix the problems. Which has been the case for the last 5 years, with only the NullAIs allowing for Lua control (a fairly recent phenomenon) finally breaking the pattern.
One way to establish more trust and cooperation between the two camps right away would be to have AI developers write or port existing core modules for certain tasks, such as metal-analysis and terrain algorithms... and put them into an "AI support" DLL, where Lua AIs can use callouts that only work if those DLLs are present.
I.E., build an AI whose main logic is Lua, but whose analysis logic is compiled for speed. Then Lua AI development would be the norm, other than people wanting to work on the ultra-high-end stuff like pathfinding and analysis algorithms. Of couse, that would require AI developers working on such algorithms to work in an Open Source fashion, which some may not want to do, but they can just work on BA stuff or whatever.
Lastly, Tobi said he was going to refactor C.R.A.I.G. early this summer, and told me that I probably didn't want to sit down with it until it was done, but I haven't ever heard back from him about whether or not it got done, so I assume that it hasn't and that I'll just have to do it myself.
If I have to address this entirely myself, I'll do it, though. It's just like the graphics stuff- my frustration level's high enough that now that I'm not under deadline pressure, and the tools exist to address the problems... I'll find a way.
Re: AIs that require config files are serious usability problems
Indeed it hasn't, can better just use current code I guess and fork it. (And/or rewrite your code if/when I get around to the major improvements I want to do some time.)
And it plays SWIW too btw, not only S44
And it plays SWIW too btw, not only S44

- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: AIs that require config files are serious usability problems
1. Re: initial post, re lobby should tell user which AIs will actually run in a game, agree lots, plus, generally what Scott says makes lots of sense.
One way of doing this could be that AIs provide a whitelist of supported maps, mods, factions, etc.
Any AI that doesn't include a map explicitly in its whitelist will not run on that map.
Any AI that doesn't even provide a whitelist will not be proposed ever. (we could have an option in the lobby like 'show hidden AIs', or something, to allow people to run legacy, pre-whitelist, AIs anyway).
The whitelist, well I'll leave the standard definition up to hoijui who seems pretty good at (a) defining standards and (b) getting others to follow them (which is 90% of the work..), but maybe something like, in AILua.lua:
... that would probably be a fairly completely specified whitelist, at 99% of cases or so (I bet one can find AIs for whom these lists are not purely orthogonal, but hence the 99%).
2. re Pure
Argh, as an AI developer, my feelings: much as I'd love to support every map and every mod, it's hard enough to get an AI to be a solid competitor on one map and one mod and one faction, so I'm going to focus on the most popular mods.
How did I pick the mod? I opened springlobby, clicked on 'multiplayer' and looked at what mod was the most popular at that moment, which was a random time on a random date.
If you want AI developers to support pure, a very available route would be to get pure to the top of the popularity list for person vs person games.
Otherwise, if there is something about pure which would make developing AIs particularly fun and rewarding compared to other mods then you might want to market that.
Otherwise, there's always financial rewards
One way of doing this could be that AIs provide a whitelist of supported maps, mods, factions, etc.
Any AI that doesn't include a map explicitly in its whitelist will not run on that map.
Any AI that doesn't even provide a whitelist will not be proposed ever. (we could have an option in the lobby like 'show hidden AIs', or something, to allow people to run legacy, pre-whitelist, AIs anyway).
The whitelist, well I'll leave the standard definition up to hoijui who seems pretty good at (a) defining standards and (b) getting others to follow them (which is 90% of the work..), but maybe something like, in AILua.lua:
Code: Select all
{ key = 'supportedmaps', type='list', items= { ... }, }
{ key = 'supportedmods', type='list', items= { ... }, }
{ key = 'supportedfactions', type='list', items= { ... }, } # core, arm, purefactionone, etc ...
2. re Pure
Argh, as an AI developer, my feelings: much as I'd love to support every map and every mod, it's hard enough to get an AI to be a solid competitor on one map and one mod and one faction, so I'm going to focus on the most popular mods.
How did I pick the mod? I opened springlobby, clicked on 'multiplayer' and looked at what mod was the most popular at that moment, which was a random time on a random date.
If you want AI developers to support pure, a very available route would be to get pure to the top of the popularity list for person vs person games.
Otherwise, if there is something about pure which would make developing AIs particularly fun and rewarding compared to other mods then you might want to market that.
Otherwise, there's always financial rewards

Last edited by hughperkins on 02 Oct 2009, 15:50, edited 1 time in total.
Re: AIs that require config files are serious usability problems
re P.U.R.E.:
The whole point of building an AI is for offline play, not Lobby play. The whole reason why P.U.R.E. went commercial is that I developed a lot of offline play, including full campaigns and a Skirmish module (although it is all still pretty crude, compared to a AAA game with millions of dollars for level design, et al).
In short... the "market" for AI developers is most emphatically *not* online players. If that's how you determine what's a useful project, then you're basically doing it wrong. If you want to be a really famous AI developer here... build AIs for games that need one.
I can't afford to pay you to work on P.U.R.E. atm- sales are still pretty slow, and as an Indie game, from what I've read, it's just going to take a while and a lot of patience, before I have any hope of seeing really big profits from the game. But there are plenty of other good games on this engine that probably would have much larger audiences (not necessarily online) if they had AI support.
The whole point of building an AI is for offline play, not Lobby play. The whole reason why P.U.R.E. went commercial is that I developed a lot of offline play, including full campaigns and a Skirmish module (although it is all still pretty crude, compared to a AAA game with millions of dollars for level design, et al).
In short... the "market" for AI developers is most emphatically *not* online players. If that's how you determine what's a useful project, then you're basically doing it wrong. If you want to be a really famous AI developer here... build AIs for games that need one.
I can't afford to pay you to work on P.U.R.E. atm- sales are still pretty slow, and as an Indie game, from what I've read, it's just going to take a while and a lot of patience, before I have any hope of seeing really big profits from the game. But there are plenty of other good games on this engine that probably would have much larger audiences (not necessarily online) if they had AI support.
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: AIs that require config files are serious usability problems
Oh I wasn't aware the pure was commercial, I just felt that maybe it's more efficient for you to do a few more hours in your day job, and use the revenue from that - where you are using your primary skills, and expertise - to pay someone else to use their primary skills and expertise.
Also, trying to put some perspective on the feeling that all the AI developers are out to get you!
> If you want to be a really famous AI developer here... build AIs for games that need one.
Nice try Arghhh
I can't speak for other AI developers but personally it's important to make my AI able to compete in the mods that other AIs can compete in, so they can play against each other, which is a big part of the fun for me.
Also, trying to put some perspective on the feeling that all the AI developers are out to get you!
> If you want to be a really famous AI developer here... build AIs for games that need one.
Nice try Arghhh

Re: AIs that require config files are serious usability problems
I never said they were, "out to get me", I said they were "out of touch", "refuse to look beyond BA", "do not partner with game developers when games are young and need AI support the most", and are "blithering idiots who think that the rest of us give a shit about them pitting their AIs against each other in sandboxes, when we have at least a dozen big games that have no AI support at all, or can barely be played against AIs, and thus cannot grow their offline playerbase, let alone online".Also, trying to put some perspective on the feeling that all the AI developers are out to get you!
In short... you're welcome to do whatever you want, but your attitude is typical of what's wrong with AI development on this engine, and I don't expect it to change until somebody gets serious about providing a credible alternative framework.
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: AIs that require config files are serious usability problems
Argh, what you say is nonsense.
I went out of my way to support as many games as I could in the earlydays of NTai, and various other AI developers did too. Not all of them, but for a longtime every game under spring had an AI. Remember me making a big fuss of nanoblobz support? Or the numerous tags and enhancements I implemented that you and others requested.
It's nice to know that all the work I did back then is being thrown out the window and forgotten about by you because right this moment you lack a working P.U.R.E AI.
I raise the following points:
It is most demoralizing and disruptive, which actually makes a P.U.R.E AI far less likely to occur.
Regarding black and white lists.
I went out of my way to support as many games as I could in the earlydays of NTai, and various other AI developers did too. Not all of them, but for a longtime every game under spring had an AI. Remember me making a big fuss of nanoblobz support? Or the numerous tags and enhancements I implemented that you and others requested.
It's nice to know that all the work I did back then is being thrown out the window and forgotten about by you because right this moment you lack a working P.U.R.E AI.
I raise the following points:
- AI development crashed and burned. Its not that AI developers don't care, or that AI devs are snotty and expect content devs. To be precise, there were no AI devs at all. Just because AI dev here ground to a halt doesn't mean we spent ages working on BA!!!
- We have just come out of what can be called the dark ages, where the only development environment for AIs that was in any way hospitable was lua gadgetry.
- Now us native guys are back! But we haven't finished our initial offerings in the current generation, so don't tell us we've failed when we havent even finished taking our steps
- A lot of the AI projects have yet to make releases and are fundamentally different in nature to past projects, and these AI devs are brand new, yet your judging them on the past 5 years, this is unfair.
It is most demoralizing and disruptive, which actually makes a P.U.R.E AI far less likely to occur.
Regarding black and white lists.
- AI based
- Guides not strict lists, it should be a this definitely works with x y and z, not a this only works with x y and z. Although the latter should be possible, its a rare case that it would be necessary.
- TheFatController
- Balanced Annihilation Developer
- Posts: 1177
- Joined: 10 Dec 2006, 18:46
Re: AIs that require config files are serious usability problems
Personally i'd assumed for months that AAI was broken/buggy and was confused why it continued to ship with the engine for the reason Yokozar stated.
It should really ship with configs for several major mods, whatever those may be...
It should really ship with configs for several major mods, whatever those may be...

Re: AIs that require config files are serious usability problems
Wait... people actually try to use Spring's AIs? I've just written them all off as hopelessly broken, as I'm sure most players have.
Re: AIs that require config files are serious usability problems
tbh its a sign of the whole problem with how spring is distributed as a whole. Games are more than an sdz or sd7, and AIs should be in game installers. The Spring Engine shouldn't distribute AIs with the intention of them being played unless its willing to selectively install AIs based on which games are installed.