Spring RTS Engine

I'm currently in process of implementing matchmaking (queue protocol) in uberserver and chililobby: viewtopic.php?f=71&t=33072

The protocol assumes there will be third-party matchmaking bots that implement the specific matchmaking algorithms. Each bot also implements a part of the lobby protocol related to the queue protocol, but the actual matchmaking is left to the bot.

I'm currently also going to create an example matchmaking bot, and I'm wondering if this could be done easily with SPADS. I'd rather avoid maintaining it if anyone steps up, but in any case I do plan to create a proof of concept implementation.

My list of requirements is as follows:
1) Ability to extend SPADS with the new lobby commands (the actual commands are still WIP, the list posted on the forums is out of date)
2) Ability to use parse json strings (new lobby commands will be in json)
3) A way to spawn multiple spring dedicated instances. How is this usually done..? I'm not familiar with autohosts. Every once in a while, the bot needs to spawn a new Spring dedicated instance (doesn't have to connect to lobby server) and continue accepting new lobby commands.

Doable with SPADS? Any other thoughts? Thanks!

gajop wrote:My list of requirements is as follows:
1) Ability to extend SPADS with the new lobby commands (the actual commands are still WIP, the list posted on the forums is out of date)

Any new lobby command can easily be handled through SPADS plugin system, using the addLobbyCommandHandler function to receive new commands and queueLobbyCommand function to send new commands.

It would also be possible to update the Spring lobby interface module used by SPADS, so that it creates new lobby data structures related to queuing in memory.

gajop wrote:2) Ability to use parse json strings (new lobby commands will be in json)

The "JSON::PP" module is part of Perl core, so you can use it to parse JSON easily from any Perl program including SPADS. Actually this is already done in the SpringieExtension plugin for example, where SPADS parses the JSON data sent by Nightwatch.

gajop wrote:3) A way to spawn multiple spring dedicated instances. How is this usually done..? I'm not familiar with autohosts. Every once in a while, the bot needs to spawn a new Spring dedicated instance (doesn't have to connect to lobby server) and continue accepting new lobby commands.

SPADS default behavior is to handle only one battle lobby, hence only one spring dedicated instance at a time. However you are totally free to spawn and track any number of spring dedicated instances from plugins. You can easily launch external programs from SPADS in an asynchronous way, there is a function in the plugin API done just for that: forkProcess. It will track for you the state of the child process and call you back on completion, giving you the exit code. For example Jools did a plugin to spawn new instances of SPADS itself on demand using that here. SPADS still handles the lobby commands while running Spring dedicated instances of course.

gajop wrote:Doable with SPADS? Any other thoughts? Thanks!

It's definitely doable with SPADS, the biggest requirement here being learning Perl if you're not familiar with it... Now is it wise to do it with SPADS? It all depends on your Perl knowledge and the amount of SPADS features that you would be able to reuse in the MM/queue system. If you think most of SPADS features are useful and will be re-used by the MM/queue system then I guess it's worth it, otherwise you could also decide to use the RelayHost system as base for your developments for example if you're more familiar with Python (I don't know the relay host system very well though, I can't guarantee it makes sense to reuse this code). There is also Zydox's autohost in Python, but it seems not updated since 2012.

If you decide to go the SPADS way I will of course be available if you need any info, help, or small changes in SPADS logic to ease your developments.

Awesome, timely response, thanks!
Regarding my definite decision on whether to use SPADS or not, I think it's still a bit premature to decide this. SPADS looks good - it's the most maintained autohost software it seems, but there are other issues to consider (some of which will be mentioned below).

bibim wrote: Any new lobby command can easily be handled through SPADS plugin system, using the addLobbyCommandHandler function to receive new commands and queueLobbyCommand function to send new commands.

That seems to be a great start.

bibim wrote: It would also be possible to update the Spring lobby interface module used by SPADS, so that it creates new lobby data structures related to queuing in memory.

This seems a bit daunting for now, but I could do it maybe with some help

bibim wrote: The "JSON::PP" module is part of Perl core, so you can use it to parse JSON easily from any Perl program including SPADS. Actually this is already done in the SpringieExtension plugin for example, where SPADS parses the JSON data sent by Nightwatch.

Great

bibim wrote: SPADS default behavior is to handle only one battle lobby, hence only one spring dedicated instance at a time. However you are totally free to spawn and track any number of spring dedicated instances from plugins. You can easily launch external programs from SPADS in an asynchronous way, there is a function in the plugin API done just for that: forkProcess. It will track for you the state of the child process and call you back on completion, giving you the exit code.

Ideally I'd rather avoid using fork process directly - it seems too low level for what I'm trying to do -> generating startscripts, as well as finding the appropriate spring executable and handling its launch/finish (with results) is something I hoped SPADS could do for me. I worked on something like that in Python once (as part of the automated AI testing), and it's not really trivial as it might sound. I'd rather get access to the SPADS launchSpring function - is it possible to make/extract something like this from SPADS source?

bibim wrote: For example Jools did a plugin to spawn new instances of SPADS itself on demand using that here. SPADS still handles the lobby commands while running Spring dedicated instances of course.

In my case though, I need to have only one MM bot instance to handle its queues. Other SPADS instances could be used for launching dedicated games, but might as well just launch spring-dedicated directly I think (I assume each SPADS instance launched runs on the same machine?).

bibim wrote: It's definitely doable with SPADS, the biggest requirement here being learning Perl if you're not familiar with it... Now is it wise to do it with SPADS? It all depends on your Perl knowledge and the amount of SPADS features that you would be able to reuse in the MM/queue system. If you think most of SPADS features are useful and will be re-used by the MM/queue system then I guess it's worth it, otherwise you could also decide to use the RelayHost system as base for your developments for example if you're more familiar with Python (I don't know the relay host system very well though, I can't guarantee it makes sense to reuse this code). There is also Zydox's autohost in Python, but it seems not updated since 2012.

I haven't written a line of Perl in my life. Might be interesting
I've seen the Python projects, but they hardly seem active (RelayHost might be usable though). While it's not as important for proof-of-concept implementations, I'd rather create something that can be maintained in the future, and SPADS seems pretty active, extensible and well documented.
I'm not sure what SPADS features I really need (or what features it actually has). One major thing that's required is the properly implemented Spring lobby protocol and a way to launch Spring instances.

bibim wrote: If you decide to go the SPADS way I will of course be available if you need any info, help, or small changes in SPADS logic to ease your developments.

Thanks, appreciated.

You're welcome

gajop wrote:Ideally I'd rather avoid using fork process directly - it seems too low level for what I'm trying to do -> generating startscripts, as well as finding the appropriate spring executable and handling its launch/finish (with results) is something I hoped SPADS could do for me. I worked on something like that in Python once (as part of the automated AI testing), and it's not really trivial as it might sound. I'd rather get access to the SPADS launchSpring function - is it possible to make/extract something like this from SPADS source?

Forking a process to launch spring dedicated manually doesn't mean you have to handle startscript generation and find Spring executable location yourself. You can still access all SPADS configuration and functions to reuse the appropriate info/code of course. For example you would instantiate a SpringAutoHostInterface object for each of the spring-dedicated instances launched, which would already manage all the spring-dedicated <-> SPADS communication for you.
SPADS indeed has a "launchGame" function, but this function is heavily coupled with the lobby interface module for startscript generation based on battle lobby state for example. I don't know how much this is relevant in the context of MM.
The main problem here is that lots of SPADS data structures are made to handle one battle lobby and only one (vote management, startscript generation, spring-dedicated interface etc.). That's why you wouldn't be able to call the highest level SPADS functions and would have to code the multi-queue handling yourself, reusing lower level SPADS functions when possible.

gajop wrote:

bibim wrote:For example Jools did a plugin to spawn new instances of SPADS itself on demand using that here. SPADS still handles the lobby commands while running Spring dedicated instances of course.

In my case though, I need to have only one MM bot instance to handle its queues. Other SPADS instances could be used for launching dedicated games, but might as well just launch spring-dedicated directly I think

Yes of course, I was just giving this as an already existing usage example of the forkProcess plugin API function.

gajop wrote:I assume each SPADS instance launched runs on the same machine?

With Jools' plugin? Yes I guess, but you can do about anything you want. You could also send a message to another server running SPADS with a plugin listening for requests to launch spring-dedicated instances for example...

gajop wrote:I haven't written a line of Perl in my life. Might be interesting

It sure is! 2 small advices if you decide to learn Perl though:
- be sure to spend enough time at start to learn and master the basics or you will lose more time later trying to fix obscure bugs than you saved initially by shortening the learning stage (yes, one could say this for most languages, but I find this especially true for Perl for various reasons)
- avoid outdated Perl documentation/tutorials, which are very common online unfortunately. They describe how Perl code looked like in the 90s, which can be a bit deterring xD.

I would say a brief introduction and overview of Perl and a very short tutorial about references are the very minimal knowledge to write code for SPADS. Modern Perl and/or Impatient Perl might be useful to go further.

The !setengine and !spawn command that I and Turboss worked together to implement in spads spawn a new spads instance on the same machine yes, but a dedicated process consumes almost no resources (bandwidth, cpu) on the machine, and I suppose you could have like 100 of these without any problems.

I tried to run one on my old Ferrari 3400 Laptop (it has technology from the 90's) over a wlan connection, and the hosting was just fine. This is a machine where the fan becomes loud just because you open a new tab in the browser, but hosting spring had no influence on temperature graph.

The plugin we wrote uses pre-defined startscripts as well as pre-defined accounts to connect to the lobby. When you set a new engine spads also has to regenerate the unitsync perl interface, after which the autohost has to be restarted to apply the new settings. I worked a bit trying to just put the new settings in the spads while running but it I could not get it to load new unitsync setting without restarting, and therefore needing the config files as files on the computer.

So the plugin we wrote works with already defined hosts but can not procedurally make a new one.

Feel free to correct whatever I may have gotten wrong, I wrote it as I understand it works.

Edit: I also talked with SWL about how they work with springie autohosts to spawn new instances: it seems they load everything from a server without using unitsync at all, or very rarely.

Excellent, my plan to get gajop hacking Perl is succeeding... (helps that bibim writes such great software)

http://qntm.org/files/perl/perl.html is also a pretty widely recommended "quick intro to perl for programmers" text. I'm also happy to lend a hand directly, so feel free to highlight me in #sy whenever the sigils start getting to be too much.

Jools wrote:The plugin we wrote uses pre-defined startscripts as well as pre-defined accounts to connect to the lobby.

I guess by "startscripts" you mean the scripts you use to launch SPADS? (I'm just asking because when speaking about autohosts and Spring, what we call "startscript" is usually the file generated by the autohost and given as parameter to spring-dedicated to launch the Spring server).

Jools wrote:When you set a new engine spads also has to regenerate the unitsync perl interface, after which the autohost has to be restarted to apply the new settings. I worked a bit trying to just put the new settings in the spads while running but it I could not get it to load new unitsync setting without restarting, and therefore needing the config files as files on the computer.

Yeah, SPADS has been designed originally to only use one unitsync library at a time. Getting it to work with a different unitsync library without restarting would be a bit tricky. It would be much easier to change SPADS architecture a bit to use some sort of dedicated proxy application for unitsync instead.

bibim wrote: I guess by "startscripts" you mean the scripts you use to launch SPADS? (I'm just asking because when speaking about autohosts and Spring, what we call "startscript" is usually the file generated by the autohost and given as parameter to spring-dedicated to launch the Spring server).

Yes.

I should first start with a sanity check:
Come to think of it, the MM bot itself shouldn't really be an autohost in the traditional sense. It shouldn't constantly be hosting a battle people can join like SPADS does now.

Itself, it doesn't even need to host any battles. All it needs to do is handle lobby (queue) commands and organize matches. When certain conditions are met, it should conclude that a new match can be started for a given game, map and engine (could support multiple maps/games/engines in the same queue, as well as multiple queues).
Then, it can either host a game itself or delegate that responsibility to some other third party. The hosting could be done in the form of a battle with FORCEJOIN or directly by just using the CONNECT command.

The way I see it, there are two options:
1) Hack/change SPADS so it doesn't automatically host battles.
2) Create a new program that will just handle lobby queue commands and matchmaking. In this case, although this option exists https://github.com/Yaribz/SpringLobbyInterface , I could just as well copy code from Python's relayhost + uberserver testclient. What are the benefits of the SLI to consider?

With both options, I could host games locally or delegate such requests to a third party (like SPADS or something new, based on https://github.com/Yaribz/SpringAutoHostInterface or similar).

What does SPADS do for me that these two interfaces don't?

bibim wrote: With Jools' plugin? Yes I guess, but you can do about anything you want. You could also send a message to another server running SPADS with a plugin listening for requests to launch spring-dedicated instances for example...

This would be one option as mentioned above, although ideally in that case the message would contain the gameName, mapName, and engine. Can SPADS handle this?

PS: Thanks for the Perl tutorials everyone!

gajop wrote:Come to think of it, the MM bot itself shouldn't really be an autohost in the traditional sense. It shouldn't constantly be hosting a battle people can join like SPADS does now.

Yes, but it should constantly be "hosting" queues that people can join... I guess queues would have quite a lot of similarities with battle lobbies: each queue would be for specific game(s)/mod(s), each queue would use a map list, each queue would limit battle sizes to some values, each queue could have some specific modoptions, each queue could balance battles respecting clans or not, using and updating TrueSKill or not etc...
So the data structure would be different in SPADS internals, but I think lots of characteristics/functionalities are similar and could be transposed/reused.

gajop wrote:The way I see it, there are two options:
1) Hack/change SPADS so it doesn't automatically host battles.
2) Create a new program that will just handle lobby queue commands and matchmaking. In this case, although this option exists https://github.com/Yaribz/SpringLobbyInterface , I could just as well copy code from Python's relayhost + uberserver testclient. What are the benefits of the SLI to consider?

I can't say what benefits the SLI module has or has not compared to the solutions you listed, as I don't really know them. All I can say is that SLI is a Perl module which handles lobby commands parsing/serializing and automatically abstracts all lobby data into simple Perl data structures. It is callback based and also offers some higher level functionalities such as automatic server startscript generation based on current battle lobby status.

However, if you consider the option where you would create a new Perl program using SLI, I would strongly suggest using SpringLobbyBot as a base. It is the template which I have used to build all my lobby bots (SPADS, IRC bridge, SLDB, Stats bot etc.). It is functional as it is from scratch, connecting to lobby server and maintaining connection using PING commands. It offers a configuration system, a log system, flood protections and a commands system with user rights management.

gajop wrote:With both options, I could host games locally or delegate such requests to a third party (like SPADS or something new, based on https://github.com/Yaribz/SpringAutoHostInterface or similar).

What does SPADS do for me that these two interfaces don't?

SPADS itself brings tons of things, I can't be exhaustive but here is what comes to my mind right now: dynamic configuration system with presets, automatic configurable battle handling (autobalance, auto fix colors, autostart, autospec), commands system with user rights management, ban system, SLDB and TrueSkill support, vote system, persistent lobby connection, auto-update functionality, flood protections, automatic replay upload, mid-game joining, plugins, unitsync caching...

gajop wrote:

bibim wrote:You could also send a message to another server running SPADS with a plugin listening for requests to launch spring-dedicated instances for example...

This would be one option as mentioned above, although ideally in that case the message would contain the gameName, mapName, and engine. Can SPADS handle this?

What do you mean by "handle this"? It sure wouldn't be hard to modify the startscript generation part in order to have gameName, mapName and engine as dynamic values chosen on the fly instead of getting them from battle lobby if that's what you mean. However I think other things should be sent too, such as the list of players allowed to connect etc.

gajop wrote:

bibim wrote: With Jools' plugin? Yes I guess, but you can do about anything you want. You could also send a message to another server running SPADS with a plugin listening for requests to launch spring-dedicated instances for example...

This would be one option as mentioned above, although ideally in that case the message would contain the gameName, mapName, and engine. Can SPADS handle this?

Yes, that's already possible by receiving the message, saving the parameters in a config file, restarting spads and then sending message back like "game is ready you can join". That's how springie does it.

bibim wrote:Yes, but it should constantly be "hosting" queues that people can join... I guess queues would have quite a lot of similarities with battle lobbies: each queue would be for specific game(s)/mod(s), each queue would use a map list, each queue would limit battle sizes to some values, each queue could have some specific modoptions, each queue could balance battles respecting clans or not, using and updating TrueSKill or not etc...
So the data structure would be different in SPADS internals, but I think lots of characteristics/functionalities are similar and could be transposed/reused.

Your observations are mostly correct with the only difference that this would allow multiple games in one queue, so as to have mission support.
You just haven't answered one of my questions directly yet. Would it be possible to disable (as configuration option if you will) SPADS from automatically hosting battles, and instead have it hosting queues?

bibim wrote: However, if you consider the option where you would create a new Perl program using SLI, I would strongly suggest using SpringLobbyBot as a base. It is the template which I have used to build all my lobby bots (SPADS, IRC bridge, SLDB, Stats bot etc.). It is functional as it is from scratch, connecting to lobby server and maintaining connection using PING commands. It offers a configuration system, a log system, flood protections and a commands system with user rights management.

This definitely makes it (SpringLobbyBot) a far better option than the alternatives imo.

bibim wrote:SPADS itself brings tons of things, I can't be exhaustive but here is what comes to my mind right now: dynamic configuration system with presets, automatic configurable battle handling (autobalance, auto fix colors, autostart, autospec), commands system with user rights management, ban system, SLDB and TrueSkill support, vote system, persistent lobby connection, auto-update functionality, flood protections, automatic replay upload, mid-game joining, plugins, unitsync caching...

That's also quite a lot indeed. I'm not sure what's usable in the queue system without major changes, but some features such as TS support seem critical for a proper matchmaking system.

bibim wrote:

gajop wrote:

bibim wrote:You could also send a message to another server running SPADS with a plugin listening for requests to launch spring-dedicated instances for example...

This would be one option as mentioned above, although ideally in that case the message would contain the gameName, mapName, and engine. Can SPADS handle this?

What do you mean by "handle this"? It sure wouldn't be hard to modify the startscript generation part in order to have gameName, mapName and engine as dynamic values chosen on the fly instead of getting them from battle lobby if that's what you mean. However I think other things should be sent too, such as the list of players allowed to connect etc.

The question was if SPADS could take messages with the above mentioned parameters and host games (or whether it would always read them from the battleroom). This post as well as Jools' answered it.

We'll see how it goes with SPADS, but you have me convinced that either SPADS or the SpringLobbyBot are the way to go.

What's wrong with my answer?

Jools wrote:What's wrong with my answer?

It's OK.

gajop wrote:Your observations are mostly correct with the only difference that this would allow multiple games in one queue, so as to have mission support.

Hmmm I think that's what I meant with "game(s)/mod(s)", but I'm not sure actually as I don't see how it's related to missions. What do you mean by "games" exactly here?

gajop wrote:You just haven't answered one of my questions directly yet. Would it be possible to disable (as configuration option if you will) SPADS from automatically hosting battles, and instead have it hosting queues?

Yes of course, actually there is already a !closeBattle command to close the battle lobby on request, so currently SPADS can already run without hosting any battle and can be made to do so by default easily.

bibim wrote: Hmmm I think that's what I meant with "game(s)/mod(s)", but I'm not sure actually as I don't see how it's related to missions. What do you mean by "games" exactly here?

In Spring, missions are sometimes represented as games. That's the most likely use case I see for allowing multiple games in a single queue.

bibim wrote: Yes of course, actually there is already a !closeBattle command to close the battle lobby on request, so currently SPADS can already run without hosting any battle and can be made to do so by default easily.

Cool, I think this answers all questions I have before starting. I'll go with SPADS, and report on my progress as I go.