Unsynced Lua AIs

[AF]

The native AIs are unsynced, which was great! The native AI interface is unfinished and undocumented however, but there is a documented and actively used API sitting in lua land.

I propose that I be able to write an unsynced lua AI, using the same setup as AIs such as C.R.A.I.G and CAI, but placed in the AI folder independently from the game archive, and ran on a single players machine rather than all machines. These AIs can be packaged or unpackaged in archives and distributed via RAPID etc

Aside from this they would be written and used the same way synced lua AIs are currently used.

This would:

• Provide a mechanism for Academia to start doing AI work on the engine again
• Simplify the testing and development process for AIs
• Allow the decoupling of AI release cycles from those of the games they support
• Provide a known and standardised AI interface by using the API most of us already know
• Allow fast iterative multiplayer testing without the hassle of repackaging and redistributing to private testers for experimental builds
• The ability to test older AIs against newer versions without needing a game to contain every version of an AI
• Improved multiplayer AI performance for players not hosting the AI
• Dramatic reduction in maintenance cost for the AI interface

[Silentwings]

+1, excellent idea.

To me the gain here is that the Lua API is much better condition than the myriad of AI interfaces. I interpret kloots comments here http://springrts.com/phpbb/viewtopic.ph ... 33#p556230 to mean that the "traditional" AI interfaces are for all practicle purposes unmaintainable.

As far as I can see, such an AI could be implemented as an unsynced-only mutator that contained some widgets along with an "AIinfo.lua" to supply info to the lobby. Once recognized as an AI, lobbies can already create a player+team for it, and the engine would need to be set up to have the AI hoster with a seperate unsynced lua state (I guess) for each such AI that it hosted.

Slight downside is that such AIs could only have access to the same data that a human player would have access too (or else, unless it was disallowed to have a team containing both humans and AIs, they would be an open door to cheating).

[FLOZi]

You are asking for two things here:

1. Ability to write lua AIs that are purely unsynced (if you had bothered to look, CRAIG runs as much in unsynced as is currently possible)

2. Ability to distribute all (native + lua) AIs via rapid etc.

[PicassoCT]

I still dont get how the Game should abstract its inner mechanics away from the General Purpose AI..

[AF]

You are asking for two things here:

1. Ability to write lua AIs that are purely unsynced (if you had bothered to look, CRAIG runs as much in unsynced as is currently possible)

2. Ability to distribute all (native + lua) AIs via rapid etc.

I didn't request number 2, but I feel it would be an inevitability if number 1 was implemented. C.R.A.I.G also has synced components, the point of everything being unsynced is that it can then be distributed and worked on in the way the native AIs are, without any involvement necessary from the game developers.

If this is already possible using some lua trickery to load in code from the AI folder unsynced and pass it data and events, I'd be interested in discussing that further

[knorke]

As far as I can see, such an AI could be implemented as an unsynced-only mutator that contained some widgets along with an "AIinfo.lua" to supply info to the lobby. Once recognized as an AI, lobbies can already create a player+team for it, and the engine would need to be set up to have the AI hoster with a seperate unsynced lua state (I guess) for each such AI that it hosted.

That sounds like it might work.
Especially the seperate unsynced Lua states for each such AI might be good, because currently Lua-AI-makers have to watch out not to accidently controll enemy units.

[gajop]

AIs as mutators are an awful idea.
How would you make a BA game of: Human vs KAIK vs AAI vs E323AI if they were written in mutators?

[Silentwings]

You are misunderstanding the idea. "mutator" is meant in the sense of the effect of the code, not the effect of the way the code is packaged.

You would simply pick the AIs you wanted from the list the lobby offered you. If you added an AI in this form, you (and only you) would end up with an extra unsynced (widget) lua state in which the AI ran, and only that state would load the AI as though it were a mutator.

[AF]

AIs as mutators are an awful idea.
How would you make a BA game of: Human vs KAIK vs AAI vs E323AI if they were written in mutators?

+1

[knorke]

...wat?
Read what is written: "an unsynced-only mutator that contained some widgets along with an "AIinfo.lua" to supply info to the lobby"

How else do you want to package the AI?
Keep in mind the AI will be *at least* two files:
1) the AI-wupdget itself
2) some AIinfo.lua or other file that tells the lobby "this is an AI"
Those files must be in some .sdz.
This .sdz would work like an "unsynced-only mutator", in that it can either be present or not.

It is NOT the same as BA chickendefense or the example posted here http://springrts.com/phpbb/viewtopic.ph ... 72#p559172

[FLOZi]

the point of everything being unsynced is that it can then be distributed and worked on in the way the native AIs are, without any involvement necessary from the game developers.

Honestly sounds like you don't understand lua synced/unsynced states at all. What difference does it make to distribution? Unless you mean a purely widget based AI, which is also silly as some games ban userland widgets (which were trepan's greatest mistake).

If this is already possible using some lua trickery to load in code from the AI folder unsynced and pass it data and events, I'd be interested in discussing that further

This is what CRAIG does...

[Silentwings]

As I understand AF does mean a "purely widget" AI - and the difference to distribution is that, as a seperate "unsynced-only mutator" (i.e. collection of widget code + info file), the AI could be developed independently of the game and a new version of the AI could be released/distributed without the need for a new game version. This is sensible for games with fairly stable synced code.

Games that ban userland widgets would not matter - since each such AI would need to have its own unsynced widget lua state, running only on its host, and would not be part of anyones userland widgets.

[Anarchid]

I fully approve of the original post.

[AF]

My understanding is if I make a mutator for BA with a lua AI, and host a battle with it, people who don't have that mutator are flagged as red in the lobby or unable to join without the mutator as it's essentially a new game, so even though the AI is in its own archive depending on the game, and runs only on one machine, it is still a requirement for all players involved. It also requires me to keep updating the BA dependency as new versions of BA are released. This is not what I had in mind

[Silentwings]

You are misunderstanding what I've said in same way as gajop. I am suggesting a practical way of implementing your idea.

"mutator" is meant in the sense of the effect of the code, not the effect of the way the code is packaged.

As knorke said, the point of using the words unsynced mutator is to define a new object that would not need to be regarded by lobbies as a different game, only as a package of widget-style code that ran entirely inside of its own unsynced lua state.

[Google_Frog]

The predominate LuaAI suggestion seems to be to run widgets in their own lua state. These widgets would be like player widgets but without the player. Widgets can see a lot of what goes on in a game and as far as I am aware they can do any player action.

There will be people who want to make cheating AI. This could be done by letting the widgets access information as if they were being run by a spectator.

[Silentwings]

That's a good point - they would have to be prevented/deactived from spectating.

[knorke]

I think cheating via an AI that somehow relays information to human players is not big issue.
Such cheat would already be possible anyway.
Anybody can see what bots are added by whom in lobby, if you do not trust them then do not play with them.

What those "external Lua-AIs" should be able to access is good question though. For example full LOS or limited LOS? With current Lua-AIs one must watch out a bit not to accidently make a cheating AI.

[Anarchid]

I presume that maybe "people who would want to make cheating AI" means those people that write AIs that cheats - such as CRAIG, E232AI, Shard... and not players who want a maphack.

For those people, being able to cheat is a feature.

[AF]

Being able to cheat in LOS etc is an important feature, it can help you build an AI by getting a working AI prior to implementing scouting, it may intentionally cheat, etc

Currently native AIs can do what players do, they cant send commands to enemy units, etc