In the future I'd like to look at what would be involved in separating each LuaAI into its own CPU thread. This led me to consider the possibility of writing a new "Socket AI" interface.
The concept is that it uses the existing C++ AI interface but instead of providing an actual AI it just opens a listening socket (or connects to a server) and passes commands and data across it using some common protocol like SOAP or JSON. I could then spawn AI as processes written in any language and even running on different computers from the one running Spring. I'd then port my LuaAI to run in a real Lua interpreter and communicate over LuaSocket. This would give me multhreaded LuaAI without solving the "multiple lua states" issues in the engine.
Just wondering what people think of the idea. I'm certainly not rushing to implement it as I'm now working on a LuaAI and other projects. I'm just putting it out there for people to consider. I think it might be something AI researchers would be interested in since they could use traditional languages like lisp or prolog without a new AI interface being coded into Spring. It would also allow closed source AI since there would be no linking to GPL code.
Socket AI concept
Moderators: hoijui, Moderators
Re: Socket AI concept
This was one of the ideas i had when we first discussed the design of the new C AI Interface. As i was a noob back then, and AF a long time community member already, with SVN access, AFs approach was chosen. That makes this socket approach practically impossible, or very ugly, as each AI has to be physically available on the game host, with at least an AIInfo.lua.
With the other approach (AI Interface plugins supplying the list of available AIs), this could be constructed on top of the plugin stucture, and use the plugin structure, so it could be coded once in C(or C++), very efficiently, and supply the same versatility of plugins on the AI host like we have for spring. In other words: one plugin for socket-ification of all plugins, instead of how it is easier now: one plugin per plugin/language implementation.
Theres one guy who already coded such a thing for python, forgot his nick... he is from the US and hangs around in #ai a lot. you have to use a binary/very efficient protocol though. JSON or SOAP would be too inefficient, i am pretty sure. why:
the parsing/encoding would be way too CPU heavy for a decent AI to work efficiently. as an example, we had to move from JNA to JNI on the Java interface, because some calls were just way too inefficient. multiple AI implementations suffered from this, and it was not their fault. I am sure that JNA still is much more efficient then SOAP or JSON.
With the other approach (AI Interface plugins supplying the list of available AIs), this could be constructed on top of the plugin stucture, and use the plugin structure, so it could be coded once in C(or C++), very efficiently, and supply the same versatility of plugins on the AI host like we have for spring. In other words: one plugin for socket-ification of all plugins, instead of how it is easier now: one plugin per plugin/language implementation.
Theres one guy who already coded such a thing for python, forgot his nick... he is from the US and hangs around in #ai a lot. you have to use a binary/very efficient protocol though. JSON or SOAP would be too inefficient, i am pretty sure. why:
the parsing/encoding would be way too CPU heavy for a decent AI to work efficiently. as an example, we had to move from JNA to JNI on the Java interface, because some calls were just way too inefficient. multiple AI implementations suffered from this, and it was not their fault. I am sure that JNA still is much more efficient then SOAP or JSON.
Re: Socket AI concept
That still leaves us exactly where we are, afterall why not run the lua VM in an existing AI using a thread? e.g. Shard with some minor modifications and API extensions. It still poses the problem of how to communicate effectively with the spring gadgets.
Luckily, I am experimenting with such a solution. While it would involve a comms gadget being put into the game itself, it exposes the entire Spring API to Shards lua, allow me to simply copy paste gadget code directly into Shard. The only downside is that Spring API calls using the gadget API would be slower than calls in gadget land, which would be slower than API calls to the Shard native API. But still faster than a socket connection.
What I would like to see, is a way of packaging a tonne of values and code together, and saying to the engine 'execute this and notify me when your done for unsynced code, with perhaps a mechanism for saying 'I want this in 5 frames' for synced, that forces the engine to wait if its not ready in time.
Luckily, I am experimenting with such a solution. While it would involve a comms gadget being put into the game itself, it exposes the entire Spring API to Shards lua, allow me to simply copy paste gadget code directly into Shard. The only downside is that Spring API calls using the gadget API would be slower than calls in gadget land, which would be slower than API calls to the Shard native API. But still faster than a socket connection.
What I would like to see, is a way of packaging a tonne of values and code together, and saying to the engine 'execute this and notify me when your done for unsynced code, with perhaps a mechanism for saying 'I want this in 5 frames' for synced, that forces the engine to wait if its not ready in time.