ValidAIs.lua
Moderator: Moderators
Re: ValidAIs.lua
i personally think it should be up to the game-devs to have an up-to date ValidAIs.lua... fetching this information from an ai imo is much more complicated. also there should be some setting to use all ais in the lobby and ignore that file.
(added my thoughts to the feature request: http://springrts.com/mantis/view.php?id=2923)
(added my thoughts to the feature request: http://springrts.com/mantis/view.php?id=2923)
Re: ValidAIs.lua
I've added my own suggestion, basically extends what Abma proposes with a validgames.lua that provides a default for if validAIs.lua doesn't mention anything. That way I can still add support for games with no maintainer or mid-release cycle, but a game dev can still say No as validAIs.lua has the final say
Re: ValidAIs.lua
if validAIs.lua has the final say, and doesn't include your AI, how does validGames.lua help you?
edit: nvm skimread and missed 'deafult if validais doesn't provide anything'
That seems to assume validAIs includes a blacklist as well as whitelist?
edit: nvm skimread and missed 'deafult if validais doesn't provide anything'
That seems to assume validAIs includes a blacklist as well as whitelist?
Last edited by FLOZi on 24 Jul 2012, 23:45, edited 1 time in total.
Re: ValidAIs.lua
Validai for a dated project can be covered with a mutator. That is of course presuming the project still works.
Re: ValidAIs.lua
@Flozi yeah, a blacklist would also save the game dev the testing hassle. By default if an AI is not mentioned in the game, and the AI makes no attempt to declare support, then no support of any kind should be assumed.
Indeed, but for bleeding edge "Smoth hasn't woken up yet" or "I have 100 mutators because AF was rather prolific one week", it lets AI devs iterate fast.
Mutators and validGames.lua are a more permanent thing since releasing and installing a new game then distributing it amongst all players is more hassle than me pressing rebuild and hosting a game.
Mutators also induce coupling. My AI now has a proto-game to go with it, though that could be useful in its own right on some occasions
Indeed, but for bleeding edge "Smoth hasn't woken up yet" or "I have 100 mutators because AF was rather prolific one week", it lets AI devs iterate fast.
Mutators and validGames.lua are a more permanent thing since releasing and installing a new game then distributing it amongst all players is more hassle than me pressing rebuild and hosting a game.
Mutators also induce coupling. My AI now has a proto-game to go with it, though that could be useful in its own right on some occasions
Re: ValidAIs.lua
ValidAIs.lua is mainly intented to prevent newb from accidentally adding non-working AI.
I wouldn't want extra complication and multiple files of conflicting shades of grey for cases that don't even happen.
Also, if you're devving, you probably know how to unpack mods and edit configs
I wouldn't want extra complication and multiple files of conflicting shades of grey for cases that don't even happen.
Also, if you're devving, you probably know how to unpack mods and edit configs
Re: ValidAIs.lua
zwzsg wrote:ValidAIs.lua is mainly intented to prevent newb from accidentally adding non-working AI.
I wouldn't want extra complication and multiple files of conflicting shades of grey for cases that don't even happen.
Also, if you're devving, you probably know how to unpack mods and edit configs
If you're a content dev you need only ever concern yourself with validAIs.lua, validGames.lua is an AI developer thing, and I'd much prefer to have a flag in settings saying "ignore both on this machine"
Re: ValidAIs.lua
continued from https://springrts.com/mantis/view.php?id=2923
what about a complete different apporach:
the lobby allows to select some predefined AI's: "easy, normal, hard" and the game then loads the ai via an unsynced lua gadget for the player?
not sure if thats possible but that would make it much easier to implement + allows the game developer to select the correct ai.
still for ai development a specific ai should be selectable, but IMO a player has no clue what KAIK / AAI / ... is.
IMO this basicly is a feature request to lobbies and not to the engine.
what about a complete different apporach:
the lobby allows to select some predefined AI's: "easy, normal, hard" and the game then loads the ai via an unsynced lua gadget for the player?
not sure if thats possible but that would make it much easier to implement + allows the game developer to select the correct ai.
still for ai development a specific ai should be selectable, but IMO a player has no clue what KAIK / AAI / ... is.
IMO this basicly is a feature request to lobbies and not to the engine.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: ValidAIs.lua
I agree with the intent of abmas suggestion. AI selection should have an understandable UI for the average user. However, I don't see how an unsynced gadget is going to load the correct AIs as AIs are already selected and loaded by the time lua gets to do anything.
Re: ValidAIs.lua
atm the commands aikill / aiload ... could be abused to do so.Google_Frog wrote:However, I don't see how an unsynced gadget is going to load the correct AIs as AIs are already selected and loaded by the time lua gets to do anything.
thats basicly the same idea as suggested in viewtopic.php?f=15&t=36176
Re: ValidAIs.lua
AIs should specify what games they can play => so AI devs can develop and distribute independently of game devs.
Games should have a list of AIs that are explicitly supported, integrated and perhaps even distributed with the game => so players have a good default UI.
Games should have a list of AIs that are explicitly supported, integrated and perhaps even distributed with the game => so players have a good default UI.
Re: ValidAIs.lua
how should the game specified list look like?gajop wrote:Games should have a list of AIs that are explicitly supported, integrated and perhaps even distributed with the game => so players have a good default UI.
how to override the list? (needed for ai devs / new ais)
Re: ValidAIs.lua
And what happens when the game moves on and the AI doesn't? c.f. AAI & S44.gajop wrote:AIs should specify what games they can play => so AI devs can develop and distribute independently of game devs.
Games should have a list of AIs that are explicitly supported, integrated and perhaps even distributed with the game => so players have a good default UI.
Game based white listing is the only option that makes sense and the only option that ever made sense.
It all boils down to the simple fact that Spring is a product for game designers. I cannot believe that after all this time some people still seem unwilling to accept the (to me obvious) ramifications of that;
Games should have total control over maps, AIs and anything and everything else if Spring is ever to be taken seriously as an engine.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: ValidAIs.lua
That's exactly correct. AF even accidentally demonstrated that by linking to an age old video where I lost to shard.
Sure, shard could play fine back when Evo was no more complex than a *a game, but Evo is so much more complex now. Native Shard does not know about supply, doesn't understand how to prioritize energy because units cost so much to fire. Doesn't know how to prioritize based upon supply. Doesn't know about control points. Doesn't understand teching or upgrading.
Here is the hilarious thing... Shard is so dependent on mexes for expansion that there is literally no fallback. Evo metal comes in increments, so shard with no expansion mechanic will leave the builder in one spot and try to do it's entire queue all around the builder. And because the main builder has 800 buildrange, it builds a prison.
Sure, shard could play fine back when Evo was no more complex than a *a game, but Evo is so much more complex now. Native Shard does not know about supply, doesn't understand how to prioritize energy because units cost so much to fire. Doesn't know how to prioritize based upon supply. Doesn't know about control points. Doesn't understand teching or upgrading.
Here is the hilarious thing... Shard is so dependent on mexes for expansion that there is literally no fallback. Evo metal comes in increments, so shard with no expansion mechanic will leave the builder in one spot and try to do it's entire queue all around the builder. And because the main builder has 800 buildrange, it builds a prison.
Re: ValidAIs.lua
Default AIs should be distributed with the game, along with default maps, lobby client, engine and similar.
Games should have control over their distribution, either directly (by supplying installers) or indirectly (by specifying everything in config files). I would opt for the indirect approach since this involves less work for the game devs, but we don't have the infrastructure setup for that. The current pr-downloader/rapid way of distributing games only gives us the game archive, and nothing else.
Keep in mind that this level of control should only be there for components distributed by default. There shouldn't be a whitelist preventing people from creating their own components (maps, lobby clients, AIs, new engine versions, and even game mods/mutators). We are an open source community and we should encourage new/independent projects and modding - it is how new stuff is created.
I haven't really outlined any specifics on purpose, as the intention is the most important element here -> if people disagree with the approach, it doesn't matter what system you specify, as it won't be used consistently.
But to give examples:
All AIs are distributed over the infrastructure (even those that are default for some games) and they contain name, version and list of game capability options, specifying which games they can play, something like: gameName, gameVersion, aiHumanName
The point is that all this belongs in the infra, and game devs should have control over it, but it should also be possible to customize things however you see fit, without having to go and modify game archive files.
Lastly, I think people should check out how GoogleFrog designed game customization/configurability with Chobby: https://github.com/ZeroK-RTS/Chobby/tre ... gameConfig . While this is a "low-hanging fruit" approach, since it's done only for a single lobby, in code, and really only created as the needs arose (instead of being designed to be a general purpose infrastructure API), it gets the job done and provides pretty powerful level of customization.
Games should have control over their distribution, either directly (by supplying installers) or indirectly (by specifying everything in config files). I would opt for the indirect approach since this involves less work for the game devs, but we don't have the infrastructure setup for that. The current pr-downloader/rapid way of distributing games only gives us the game archive, and nothing else.
Keep in mind that this level of control should only be there for components distributed by default. There shouldn't be a whitelist preventing people from creating their own components (maps, lobby clients, AIs, new engine versions, and even game mods/mutators). We are an open source community and we should encourage new/independent projects and modding - it is how new stuff is created.
I haven't really outlined any specifics on purpose, as the intention is the most important element here -> if people disagree with the approach, it doesn't matter what system you specify, as it won't be used consistently.
But to give examples:
Each game has a list of AIs (AI name, version, humanName and perhaps OS-specific download URLs) that is distributed with the game. The list is contained in the infrastructure and game devs have control over updating it.abma wrote:how should the game specified list look like?
how to override the list? (needed for ai devs / new ais)
All AIs are distributed over the infrastructure (even those that are default for some games) and they contain name, version and list of game capability options, specifying which games they can play, something like: gameName, gameVersion, aiHumanName
Games can specify whether their non-default components need to satisfy gameVersion matching. This can be done with a something like a parameter field, with values like "exact", "major", "none", determining exact gameVersion matching, matching only the major number, and not requiring the gameVersion to match.FLOZi wrote: And what happens when the game moves on and the AI doesn't? c.f. AAI & S44.
The point is that all this belongs in the infra, and game devs should have control over it, but it should also be possible to customize things however you see fit, without having to go and modify game archive files.
Lastly, I think people should check out how GoogleFrog designed game customization/configurability with Chobby: https://github.com/ZeroK-RTS/Chobby/tre ... gameConfig . While this is a "low-hanging fruit" approach, since it's done only for a single lobby, in code, and really only created as the needs arose (instead of being designed to be a general purpose infrastructure API), it gets the job done and provides pretty powerful level of customization.
Re: ValidAIs.lua
Then we use the tried and tested method everybody else uses outside our community and attach version numbers to stuff.
E.g. Instead of an AI saying it supports EvoRTS, it says it supports EvoRTS <= 5.0 or something to that effect. Then if the game moves on, fine, the AI dev tests and updates to 6.0.
Similarly the same problem is true of AIs. Evo might have said it supported Shard, then Shard 0.5 comes out with Evo support removed. At which point does Evo say Shard supports it? What if you have multiple versions of Shard and 0.4 supports it but 0.5 doesn't?
The argument works both ways, a simple list isn't enough wether it's in the AI or game. Version control is needed.
-------
I'd also like to note that while a game dev should have full control over their game, for a lot of the AI devs who've worked with this engine, and in academia or hobbyist, AIs are not a part of the game. Sure a game might have an official AI bundled with the game, but their AI was not such a thing. IMO it should be easy to build and install such AIs. If that weren't the case, then AI here would have taken a very different and much diminished route.
But it's because installing them is so difficult that they're bundled with the engine. Solve that problem, remove them from engine installer, and most of these problems go away automatically.
Flozi, AAI is not a part of S44, nor is Shard a part of EvoRTS. Keep that in mind when making points.
E.g. Instead of an AI saying it supports EvoRTS, it says it supports EvoRTS <= 5.0 or something to that effect. Then if the game moves on, fine, the AI dev tests and updates to 6.0.
Similarly the same problem is true of AIs. Evo might have said it supported Shard, then Shard 0.5 comes out with Evo support removed. At which point does Evo say Shard supports it? What if you have multiple versions of Shard and 0.4 supports it but 0.5 doesn't?
The argument works both ways, a simple list isn't enough wether it's in the AI or game. Version control is needed.
-------
I'd also like to note that while a game dev should have full control over their game, for a lot of the AI devs who've worked with this engine, and in academia or hobbyist, AIs are not a part of the game. Sure a game might have an official AI bundled with the game, but their AI was not such a thing. IMO it should be easy to build and install such AIs. If that weren't the case, then AI here would have taken a very different and much diminished route.
But it's because installing them is so difficult that they're bundled with the engine. Solve that problem, remove them from engine installer, and most of these problems go away automatically.
Flozi, AAI is not a part of S44, nor is Shard a part of EvoRTS. Keep that in mind when making points.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: ValidAIs.lua
If a player goes into the lobby or into spring.exe directly, goes to choose an AI and an AI appears on that list, from the player perspective, the AI is indeed a part of the game. That's the problem.
Re: ValidAIs.lua
Evo says that X <= Shard <= 0.4 supports it.AF wrote:Similarly the same problem is true of AIs. Evo might have said it supported Shard, then Shard 0.5 comes out with Evo support removed. At which point does Evo say Shard supports it? What if you have multiple versions of Shard and 0.4 supports it but 0.5 doesn't?
You can host your own mutators that support your AI, name them "Evo with Shard AI" or something and take the support burden onto yourself. There is absolutely no need to expose the already small number of newbies we get to crashy AIs (that happen to be at the top of the AI list) and then for Forb to have to deal with the mess.AF wrote:
I'd also like to note that while a game dev should have full control over their game, for a lot of the AI devs who've worked with this engine, and in academia or hobbyist, AIs are not a part of the game. Sure a game might have an official AI bundled with the game, but their AI was not such a thing. IMO it should be easy to build and install such AIs. If that weren't the case, then AI here would have taken a very different and much diminished route.