Tachyon Autohosts

[Jazcash]

Let's talk about how we want new tachyon autohosts to work.

My proposal is we have two types of autohost software: dedicated and slaved, similiar to spring-headless.exe and spring-dedicated.exe respectively. Dedicated autohosts will be SPADS-like, and should be fully autonomous, implementing their own commands or whatever systems they want. Slaved autohosts will be a new kind of autohost, fully controlled by the Tachyon server.

The way I envision these both being applied is using slaved autohosts for matchmaking (where no user commands should be necessary), and dedicated autohosts for custom battles (what we currently have).

For dedicated autohosts, I think it makes sense for the Tachyon server to still broker all communication between the autohost and the users, but I don't think it makes sense for the server to actually interefere with the battle. This implies all the current server-commands such as $minRating, $joinq etc should be implemented in the dedicated autohost. They will still be applicable to the Tachyon server in the case where we might want to use slaved autohosts for custom battles, but they should work the same way as all the other server commands and the lobby app can implement them as desired.

Thoughts?

[Teifion]

I think it makes sense to have everything be like SPADS but then implement a version of that where it knows not to execute commands. I've linked el_barto to this so he can chime in too.

The server should still broker communication between the two, it allows for server-based features to be applied (meaning a feature can exist on the autohost or the server).

[BAR-eL-bArTo]

I was thinking why not just have a single autohost type that can handle both matchmaking and normal hosting? My first thought is that having 2 autohosts could result in duplication of effort, even if they have any common code shared among them it would still require extra effort and coordination.

[Teifion]

I'll have a go at writing that up

[BAR-eL-bArTo]

If I'm understanding correctly, that means you have the same view as me?

Yeah I think I might have missread both your messages earlier. It sounds like we all agree on the same thing.

My concern was with keeping the load on the Tachyon server light instead of every command from every battle being sent through it

Yeah I've been thinking about how to minimize the load on the server as much as possible too. I guess all the server would be concerned with would be the player and spec list, what map is being played, type of game and whether or not it's running (and probably a few other things I haven't considered). Other then that it makes sense that the clients talk directly to the autohost instance that's hosting that particular game.

The main thing I want to get away from is players communicating with the autohost via chat commands and the autohost effectively defining its own protocol.

Yeah I agree this will make everyone's lives easier.

I'm currently going through a lenghty refactoring of the autohost and getting bogged down when I should probably focus on start looking at how spads talks to spring and actually begin working out how to start laying the groundwork for the protocol.

[Teifion]

Server load for this sort of stuff is incredibly low, it might not even save anything since the server needs to be aware of the changing state anyway. I think having the ability for the autohost to expose info about the state of an ongoing game is very good, we can do that directly or via the server.

[Jazcash]

If server load is low then fully slaved autohosts might be the first way to go? By this I mean autohosts effectively being as dumb as possible, not knowing anything about the state of the lobby at all. The only response they would receive from the server would be the full script.txt to launch (or equivalent JSON that can be converted to script.txt format).

[Teifion]

I'm 100% happy to defer to @BAR-eL-bArTo in terms of just how much the server takes on compared to SPADs