Nostalgia - Page 9

Nostalgia

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderator: Moderators

Locked
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Nostalgia

Post by zwzsg »

Silentwings wrote:Alternatively, you could make a widget AI.
Really? I have not heard of that.

You could port most of a Lua AI gadget into a widget, but it wouldn't act as an AI, it would act as a super powerful widget. Like a widget that helps so much it basically plays the entire game for the player. But would still require a player to be playing watching the AI orders his units around.

Is such "autopilot widget" what your are talking about? Or are there some mysterious widget-AI thingy I have never heard about?
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nostalgia

Post by knorke »

CRAIG in S1944 mod is example of partly unsynced AI. But:
You could port most of a Lua AI gadget into a widget, but it wouldn't act as an AI, it would act as a super powerful widget.
Yes, it is not possible to make a widget show up in the "add Bot" menu and make lobby create a team for it. So such widget-AI would be limited to controll one team per client.
As for why native AI development died, it didn't die because of how they were distributed, they managed to flourish fine with it in place
Think distribution was a factor: imo for players the distribution of native AIs was always confusing.
There was always questions (forum+lobby) about "which AI works?" and "what bot to use with mod XY?"
And the answers were, if by humans or the AIs themselfs were mostly only vague: "...should work with most mods.."
Even if the AIs themselves had been superperfect: having to look around forum or third-party sites for config files or new versions, that was just not userfriendly.
If such techy things are required to play then it puts low limit on how popular such AI/game can possible become.
And AIs were not superperfect, was it not you who made a thread about how AIs should "fail gracefully" instead of crashing when they encounter something unknown in a mod?
It was important period for spring but those problems were never solved and until today are serious shortcomings. If a native AI was more actively developed there would still be no better way for updating than asking players to manually download some strange files into their spring folder.
Personally I am glad that the days of manually downloading stuff (maps, widgets, mods,..engine) are over!
to suggest that native AIs failed because they weren't a synced gadget inside a game archive is naive
I did not say that.
Neither do I think gadget-AIs are solution to all problems. But to some :-)
it doesn't explain why we had a thriving AA/BA ecosystem of native AIs back then, but not today, even though there's no special reason BA or XTA can't be played via those AIs.
Didn't we just discuss reasons for that?
But I thought of another reason that probally plays a role too:
For a long time there were only two ways to have singleplayer:
1) The random-spawner (something in engine that simply spawns random units. not comperable to chickendefense)
2) Native AIs
Today it is possible to make singleplayer content of different kinds: missions, chickendefense, high-score challenges and so on. So the effort spent on singleplayer is no longer concentrated on skirmish-AIs: instead it is spread over different areas.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Nostalgia

Post by AF »

Indeed I did make a thread about failing gracefully, and that lesson applies to everyone, AI devs and gadget writers too.

I made it because KAIK crashed out when it ran into a situation it didn't expect, and Kloot believed it was better to fail hard and force the user to file a bug report than to catch the crash and attempt to salvage the situation ( my approach ). If NTai code threw an exception or crashed, it would log an error to infolog and try to wind down, KAI would crash the engine, ruining any multiplayer games in the process.

This lesson applies to lua code just as much, if not all code written.

I also fixed the config issue and what can go where by distributing installers for NTai, and adding genericised config files as a universal fallback. In its prime my AI worked with everything, the question was rather would it work well. I would note that this problem is not unique to the native AIs, and to an extent impacts widgets and maps to lesser degrees. Attempts to fix this were derailed by differences in opinion, not that it matters anymore, the native AI interface is unstable and undocumented, nobody new would touch it with a barge pole.

But should I have an unsynced gadget AI as I described, and I wish to publicly distribute it, why wouldn't I be able to do it the same way as maps? Bundle in a lua file saying which games it supports and filter the AI list handed to the lobby.

Hey presto, problem solved, people can write AIs in lua, no more compiling native AIs to get unsynced AI code, full 1st class access to the spring lua APIs, a means of contacting synced code the way widgets do it, an independent release cycle, the ability to support more than 1 game without forking the codebase for each game, and an easier way to test and distribute AIs

I'd also note that with Shard, I was able to host multiplayer compstomps, quickly make adjustments, then restart the game. This isn't possible with a synced AI.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nostalgia

Post by knorke »

I also fixed the config issue and what can go where by distributing installers for NTai, and adding genericised config files as a universal fallback.
But also you mention: "releasing NTai multiple times in a single day at one point."
Downloading new configs/installer is still by hand, we hopefully agree that is at best suitable for experimenting, not for real players.
Imo that could only be solved with some native-AI-updater-system, which is as science-fiction as spherical maps.
In its prime my AI worked with everything, the question was rather would it work well.
If in some mods the AI just stands still or aimlessly moves units around, that is not "working." There have *always* been mods that AIs did not know how to play. Such combinations simply must be blocked, for players sake.
If the AI outright crashes or goes into some fallback-do-nothing-useful mode, that is only of interesst to developers: Either to get feedback or to be happy to have created non-crashing AI.
For players "the AI in this game works" means more than "it does not crash", to them an AI that does crash is equally useless as an AI that just stands still.
I would note that this problem is not unique to the native AIs, and to an extent impacts widgets and maps to lesser degrees.
Usage of widgets and maps can (more or less) be controlled, was discussed often in forum. As last resort it is always possible to have a "can not play on this map!" message. Native AIs are harder to limit, in worst case the AI hangs spring right at start before any "incompatible AI detected!" message can be displayed.
I'd also note that with Shard, I was able to host multiplayer compstomps, quickly make adjustments, then restart the game. This isn't possible with a synced AI.
Yes, that is possible. From commit to downloading and hosting the new module-version in lobby it is few seconds.
Not every commit to mod (or AI-archive or whatever way you make it) creates a new stableversion, but all versions are playable in lobby. If an AI-dev is hosting compstomps while making adjustments to the AI, that is more a testsaison anyway so things like using a forked game and similiar are imo also acceptable, should it be nessecary.

Your idea would need:
-new AI-interface (like exists for c++, java, python, c#) but this time, for Lua
-downloader-thing extened to download not only maps&mods but also AIs
I see no real advantages to normal gadget-AIs, they can already all the things you listed. (using Spring. API, integration with LuaRules)
"independent release cycle, the ability to support more than 1 game without forking the codebase for each game": spring's module systemblablub already allows for that, at least in a "close enought" way.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Nostalgia

Post by Silentwings »

zwzsg wrote:it would act as a super powerful widget. Like a widget that helps so much it basically plays the entire game for the player. But would still require a player to be playing watching the AI orders his units around. Is such "autopilot widget" what your are talking about? Or are there some mysterious widget-AI thingy I have never heard about?
Yes, I just mean an "autopilot" widget. As far as I know all current Lua AIs run in gadgetland but there's no reason (apart from the inability to cheat) that they couldn't run in widgetland - and it would largely solve AFs question of how to distribute them.

As AF points out here http://springrts.com/phpbb/viewtopic.php?f=21&t=32274, there are some issues to solve before it would be properly an "AI" and not just a helper. But this approach does have one big advantage - the lua API is in much better condition and much more widely undestood than the AI interfaces.

I confess to not reading all the posts between my last and this so sorry if I repeated something.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Nostalgia

Post by AF »

No, there was a long period during which NTai played everything, and i'm not talking about an idle commander, I mean moving units, construction, etc. For some games with no deliberate support it played the game but was easy to defeat but it still played a passable game, and one that could defeat complete noobs

I doubt that's possible today at all, if only because game rules aren't available in a readable format without some level of sentient understanding, but it was possible back then, and it still is with some kinds of games.

Also, I was able to make realtime changes at some points to configs mid game that had immediate changes in the AI. I've never heard of a gadget AI in a game archive being updated mid-game with said changes applied to an actively running instance of the game

Also no new AI interface is necessary, we have an API built already used by every person who's written a gadget or widget, with synced AIs written for it. Implementing a brand new API in lua for unsynced lua AIs would be a massive mistake and isn't what i'm advocating at all. These AIs would be near identical to the synced lua AIs we already have, they would simply exist in a different folder unsynced.

the lua API is in much better condition and much more widely undestood than the AI interfaces
My point exactly. I would rather work on a compatibility layer to allow lua Gadget AIs to talk to native code, than implement a whole new lua universe yet again in a native AI, or re-implement the existing native AI interface.

People want they heyday of native AIs, I think that's a reasonable request, I just don't think the answer is yet another new native API. It'd be nice to be able to use any programming language, but right now the developer interest to maintain an API just isn't there, and we have a perfectly good API sitting there already. Lets use it.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nostalgia

Post by knorke »

As example of LuaAI-in-dependency-arcive here comes:
The NoobyMetalHeckler AI for BA 8.00
This guy is a total noob! He places mexes randomly, so best likes to play MetalHeck.
There he can really shine with his awesome strategy of building handfull of windmills and peewees while randomly walking around. ONLY PLAYS ARM!

The AI itself is horrible hackcopypaste, do not look at it. (there are better examples in forum)
It was meant to show how with AI-mutator one can make Lua-AI independently from mod etc but then noticed it is stupid to make example for that when one already exists:
BA Chickendefense has been doing the same since years. So ignore just said everything and look at BA Chickendefense.

One thing was not mentioned yet:
Replays with native AIs always work, even if the AI was changed inbetween because replay only stores the AI's orders. With gadget-AIs, the replays only continue to work with stable/commited module-versions, if one keeps tinkering with an .sdd file all the time, then none of the replays work afterwards. (imo not really bad but small annoyance still)
Attachments
BAmutatorAINoobyMetalHeckler.sdz
(6.55 KiB) Downloaded 21 times
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Nostalgia

Post by AF »

Which is a non-issue if the AI is completely unsynced and separate from the game, because in the process of playing the replay, the AI is simply not ran, which is why native AIs can change dramatically yet the replays still work.

And as gajop mentioned, how do I take my AI and test it against other rival AIs? It'd require a complete repackaging, changes to version control, redistribution, etc If my AI is a WIP and unready for public consumption I can't use the existing toolchain to do tests and have to resort to packaging it up manually and sending it to everyone involved, which is a faff. Such a scenario is irrelevant with separate unsynced lua AIs as I'm the one running the AI so I'm the only one who needs a copy
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nostalgia

Post by knorke »

The replay-thing is excatly what I said...?
And as gajop mentioned, how do I take my AI and test it against other rival AIs? It'd require a complete repackaging, changes to version control, redistribution
Worst case you make a new archive with depend = {"AI-1","AI-2","AI-3"} which is not much work.
Try it with the NoobyMetalHeckler VS Chickendefense or something.
Less work than a botrunner-springgrid ladder ;)
One might end up with many relays that only work with special-silly versions of archive-tangle-mess: but that is not really different from games like zero-K where each week (or day) you need to download new game-version to watch recent replays. With how downloading works now, it is okayish.
If my AI is a WIP and unready for public consumption I can't use the existing toolchain to do tests and have to resort to packaging it up manually and sending it to everyone involved, which is a faff.
Imo unlikely case that AI is unready for public but still want to send it to others. Just put it on rapid, like dozen of other "unready" mods do, too. Without advertising stuff on rapid is hidden enough in file-mess that players will never find it. It would again only be problem if AI-code must be absolutely secret (reasons for that are rare) and well, if one has such strange use-case then one has to live with some faff.
Do not/want not use the existing infrastructure and tools - then to fumble around one has.

Don't misunderstand:
"game-seperate Lua-AIs" like that would be cool - But so would be dozen of other things in feature-request forum.
Since the wish-to-feature-converters require lots of energy, I think in meantime it is good to be aware of alternatives that work *right now.*
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Nostalgia

Post by AF »

Unready AIs may be unready precisely because they can't be public and must be privately distributed. In such a scenario uploading to Rapid where everybody can grab it could be enough to get a student or researcher into trouble. It's not uncommon for materials to not be released in full until findings are ready and a report is written. Such is academia, but there are plenty of other reasons for wanting privacy.

As for the mutator nooby metalheckler thing, I don't see what in that archive enables me to run that on one machine, independent of the game archive. I can happily see having 10 of those on my hard drive each representing slightly differently tweaked versions of my AI, and a very very game list when I open a lobby. What if somebody else makes their own version? A special horse edition? Is it better than the version I made? Do I really want to copy paste 5 or so different versions of an AI into an archive, adjust ot relevant version, zip it up, host a game, send a copy of said zip to everybody else who wants to watch, or commit all the changes and push over RAPID?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Nostalgia

Post by smoth »

Several people raise the point that the independent ais find it troublesome that they would have to be distributed WITH the game if they were a lua ai.

Again, this is a problem with the entire spring community mentality. The ai belongs with the game. Writing generalized AIs only works in games that have similar economies. EE when it added the hubs no longer worked with AIs. Gundam When it added it's own economy no longer worked with AIs. EVO when it added it's power system, no longer worked with AIs.

I am not going to get into this debate again as you all just ignore my points because *a is fine with it.

This is all about the pride of an ai developer, who sees their project as their own. Well that is all well and good, they can do that develop these vanity projects. It is part of why spring and it's included games suck so bad. Until you get everyone under one banner(outside of *A) ONLY *A projects will do well. The ais will only work well with *A. This is part of why spring's leading projects will always be *A.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Nostalgia

Post by gajop »

If an AI is distributed independent of the game, it does not imply that it isn't made with the intent to be used on a single game or few very similar ones.
The point of having independent AIs is in the freedom to make them without any communication or consent by the game dev, as well as being able to compete with other people who make AIs for the same game(s).
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Nostalgia

Post by AF »

NTai played Expand and Exterminate once support for Hub style building was added. It didn't take long, and most of the changes necessary were already in there for nanoturret support. It also adapted without any concerted effort to a number of other games once that change was made. When I say it played everything, I mean, it played everything, even games with no structures at all and units building units, it wasn't a *A only party.

Only Lua Rules broke that, specifically the ability to Morph, I knew how to make a unit Morph, but unlike construction, there was no means of determining what a unit could morph into.

As for non *A games, they arose after the AI interface went tits up, nobody made AIs for them because there was nobody to make them. AIs were maintained for *A because AIs existed for *A and it was easier to stop them breaking than write new ones. Coupled with game devs either not caring about implementing AI ( GundamRTS ), building their own lua AIs ( C.R.A.I.G derivatives and CAI ), or outright refusing ( SWTA/Starwars ), it's not hard to see why AI development hasn't recovered.

Your pride theory also ignores the changing of hands of KAI from Krogothe to Firenu and Tournesol, then back to Krogothe, then over to Kloot, or the people who ported RAI to java, the team who built the AI with all the polish class names, or the myriad of people who contributed to Shard and NTai development.

Nevermind the Academic interest and research done on Spring AIs, and the people who graduated from play AI development to engine Dev. Our first project lead after SJ stepped down was an AI dev.

I can see the wisdom of having a dedicated officially sanctioned AI that comes bundled with a game, but independent AIs allow experimentation and rivalry. Without that, there is no competition, and without competition, AIs will never be more than 'good enough' for the average noob who plays offline. That won't get us super fun AIs, challenging AIs, or hook new developers who then make their own games or contribute elsewhere
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nostalgia

Post by knorke »

There might be reasons for AI-code-privacy but all that I can think of are somewhat far-stretched edgecases. (Academia is imo such edgecase, too). Maybe in some cases it really is a blocker, in such case (honestly) "too bad" but I think in most cases it is not an issue. I am not against it, just think it is not so important.
As for the mutator nooby metalheckler thing, I don't see what in that archive enables me to run that on one machine, independent of the game archive.
Not possible with how NoobyMetalHeckler thing is made, and afaik being independent of the game archive is not possible with how depencies work.

BUT I guess question is "how to make multiple such AIs play against each other, without too much hassle?"
This is setup that AI-devs might use, not players.

Have some AIs, they depend on nothing like this:
NoobyMetalHeckler-AI's modinfo.lua wrote:depends={}
PorcMaster-AI's modinfo.lua wrote:depends={}
PorcMaster-AI-v2's modinfo.lua wrote:depends={}
Then instead of each AI depending on a game-file, you have another module:
For example a package of all AI's for Balanced Anni might look like:
BA-AI-package's modinfo.lua wrote:depends={Balanced Annihilation}
These AI-packages would include all the AIs for one game.
Note: Did not test whether AI can have its own LuaAI.lua or if there must be a combined file in the AI-package.
This allows all AIs to be downloaded, updated and used (for playing) together.
If you want the AIs to play a different game, then just change the depends= entry in the AI-package module or make a new AI-package.
So there is no need to copypaste files around, just editing entries in one file.

Think with proper use of github/svn blub maintaining such AI-package would be possible without being superannoying. Similiar to how it was planned to have for example chili-UI's git project to be included as subproject-thing in some mods.

Simple version might even be to have one SVN-project and just different folders for each AI.
If someone wants a new AI, he creates a new folder and adds an entry in LuaAI.lua.
Requires some coordination but if there are so many AI-devs that coordination becomes impossible than that would be a success in itself ;)
Not perfect, but a way that technically seems possible and managable?

Or start even smaller. Post your Lua-AI with note "copy this into BA\LuarRules\Gadgets\" and if someone wants to challenge it, then he also posts his AI. And then both peoplepersons widly copy files around and if that has been going for a while THEN start looking at better solutions. (like the one above perhaps)
Otherwise seems a bit like solution ("how to manage AI vs AI") looking for a problem. ("who even wants to make AIs? this way")
Though it is hen-egg situation, maybe if solution is there then the problems will appear.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nostalgia

Post by knorke »

Speaking about AI competion, its on! :shock:
http://springrts.com/phpbb/viewtopic.php?f=23&t=32284
As test how many problems appear.
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Nostalgia

Post by Google_Frog »

AF wrote:NTai played Expand and Exterminate once support for Hub style building was added. It didn't take long, and most of the changes necessary were already in there for nanoturret support. It also adapted without any concerted effort to a number of other games once that change was made. When I say it played everything, I mean, it played everything, even games with no structures at all and units building units, it wasn't a *A only party.

Only Lua Rules broke that, specifically the ability to Morph, I knew how to make a unit Morph, but unlike construction, there was no means of determining what a unit could morph into.
Playing everything in 2007 is nothing compared to the AI I just wrote. This AI play every Spring game released in 1995 and is unbeatable.

I like the idea of Lua AIs which are packaged in a similar way to native AI because it will let people develop AIs without anything to do with the game developers. It lets them set the pace of their own development and they can test them on real players without requiring them to transfer files. I don't expect these native-like Lua AIs to be generic AIs because lua can implement very diverse game rules.

As for the morph problem a LuaAI can do Spring.GetUnitCmdDescs.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Nostalgia

Post by gajop »

Google_Frog wrote:I don't expect these native-like Lua AIs to be generic AIs because lua can implement very diverse game rules.
While I agree this assertion will likely be true in most cases, it entirely depends on the AI developer's goals. You can have at least three different goals when writing AIs:
1. Create decent playing AIs that play like humans. This is actually what most players and game developers want. AIs that fall in this category will usually build a wide variety of units and have a bunch of different strategies to utilize it, but will also have weak micro. In games with diplomacy options, these AIs tend to be more stable.
2. Create highly competitive AIs that have winning as it's only goal. These AIs will be highly optimized for a small set of strategies that they utilize really well, usually with extreme micro. It is not fun to play against these AIs, but AI devs really love making these.
3. Create generic AIs that can play a large variety of games, maps and missions. While this is the least likely type of AIs that people will make in Spring, it's still a valid field of research in AI. The goal of these AIs is in improving the ability to understand game rules specified by a predefined ruleset and operate with a certain efficiency.
Manmax
Posts: 78
Joined: 19 May 2011, 13:57

Re: Nostalgia

Post by Manmax »

So who is still alive and kicking in 2016?
User avatar
Jools
XTA Developer
Posts: 2816
Joined: 23 Feb 2009, 16:29

Re: Nostalgia

Post by Jools »

Ah, nostalgia is not what it used to be.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Nostalgia

Post by abma »

please don't bump such old threads.

locked
Locked

Return to “General Discussion”