Spring RTS Engine

AIs can come with widgets that show data (eg a thread-map) to the user (AI host), or that let the host manipulate the AI, for example switching between aggressive or defensive through the push of a button at runtime. This kind of stuff would be most interesting for debugging and generally experimental AIs, not so much for AIs used by end-users, probably.

slind, synced Lua can not be supplied by AIs without modifying the game.
synced means, ti can directly alter the game state, so in other words, the game would be a different one. this means, that everyone would have to have that Lua, not just the AI host, and game devs would not want it... and probably other stuff
-> not possible.

+1 AI debugging widgets would be a MASSIVE help, anything that can eb done to facilitate them should be done.

Lua can serialise tables using lua code, google it and you'll see hundreds of examples

hoijui wrote:slind, synced Lua can not be supplied by AIs without modifying the game.
synced means, ti can directly alter the game state, so in other words, the game would be a different one. this means, that everyone would have to have that Lua, not just the AI host, and game devs would not want it... and probably other stuff
-> not possible.

The purpose of having a specification is to require(force) games to adhere to a certain set of standards regardless of if they want to or not. The reason generalised AI is difficult to implement is that games do not have a standard they must support if they want generalised AI.

The point of a specification is requiring games to change and adhere to it.

AF wrote:Lua can serialise tables using lua code, google it and you'll see hundreds of examples

-_-

So we return to my original question/suggestion:

How do you want to serialise the tables? I suggest(ed) the use of a dictionary string similar to the bencode that bittorrent uses to pass data. It supports a simple to understand format that supports all data formats (including Lua data) and is easy to implement and pass. A dictionary string is easily extensible for future extension. A simple minimal set can be implemented and subsequent versions can support more.

Hoijui said that it is not a valid solution to modify the engine so the other solution i suggested isn't an option.

Do you have any other suggestions on implementation?

I agree per message should be a dictionary but, we have to consider these need batching together too. We should also add values specifying the number of messages etc for debugging purposes.

AF wrote:I agree per message should be a dictionary but, we have to consider these need batching together too. We should also add values specifying the number of messages etc for debugging purposes.

A dictionary string has no limit to the number of messages per string.

Not sure you understand what I mean.

Standard message format discussion moved here:

http://springrts.com/phpbb/viewtopic.php?f=15&t=26195