Propagating game server process events to Agones system

[markmandel]

Moving relevant items from #277 so they can be tackled separately

Another cool feature would be complting fleet allocation (through setting it status to Ready or smth like this) only after dedicated server loaded level and is fully ready to accept players' connections. Agones SDK could be extended with Loaded() method for this.

we were thinking that the game server should also be able answer back to let know that it is ready, let's say it will load a new map and we want to receive player only when the map is loaded.

I'm letting this peculate in my head a little before driving towards a opinion on a solution, but some initial thoughts and concerns:

1. This could possibly be a job for a SDK integrate that lets you set game specific Status key-value pairs. Then you could use the K8s watch api to look for these events. Then we aren't tied to just one event (like "map loaded", etc), and it can be specifically tailored to just about any game. the downside here, would be this pushes some work up to the layer that integrated into Agones for the sake of flexibility. But it would be super easy to do.
2. It's possible that we may have another replicated GameServer control plane other than Fleets at some point in the future (not sure what this would look like , but maybe something more MMO focused?) - I'm a little hesitant to tie the SDK to Fleet specific things (which would be Allocated state), at least right now for this reason, but maybe I'm being overtly cautious. Entirely possible -- maybe a solution here is to work out a way to have an optional blocking callback on any status change, although actually not 100% on how to do this technologically. I also get scared of "what happens if the callback fails somewhere".
3. I'm hesitant to block on a gameserver process on letting the GameServer move to Allocated, just because the MutationWebhook means there is a hard 30s timeout on the work that it does -- and if we hit that, weird stuff could potentially start to happen. Hence I would lead more towards option No.1.

Outside of "wait until a map is loaded before letting players join" - are there any other scenarios that you would want to wait for certain things to happen? Exploring this space a bit more may open up more flexible solutions.

[markmandel]

/cc @Kuqd @EricFortin @defat - for your input please.

[EricFortin]

I would lean more to a callback being called when the server is Ready(). This way it can be used for other use cases like a connection to a company game service, runtime configuration or matchmaking related communications.

[defat]

Completing fleet allocation process with a callback from dedicated server looks more simple, but technical restriction to do this in 30s time interval seems to unable this option, map loading can take more time.
Approach with dedicated server sending events through an SDK method and listening it with k8s watch API seems to fit most of needs.

[markmandel]

@EricFortin I think that sort of use case should be manageable by the design in #277 - please let me know if it doesn't.

[cyriltovena]

Ready() from the SDK is already propagating readyness to k8s, what we're lacking is a way to received data from the matchmaker prior being READY(Accept players). Do we have any timeout restriction currently on the Ready(), for me having timeout is important but should be configurable ?

Also I think this only within the GameServer scope (Not Fleet or Allocation).

[markmandel]

@Kuqd I think #277 should solve this problem too - the matchmaker could set labels/annotations on the gameserver prior to it being ready, this would fire the callback on data change on the GameServer - and then the game server process could read those annotations/labels and mark itself as Ready whenever it would like. That way it can pass data down into the GameServer - and also have that data be readable by K8s tooling.

As long as health checks are being sent, a game server process doesn't have to be Ready within any kind of timeframe.

Does that work/make sense?

[cyriltovena]

yes it works.

[markmandel]

So @EricFortin and @Kuqd had a bit of a chat about this, and these are the conclusions we ended up drawing (lemme know if I got any of this wrong):

1. Have an SDK function to be able to set a Status.GameState value on the owning GameServer (unless someone has a better name?), which can be any string value, and will be separate from the Agones specific Status.State.

This will also propagate through to the GameServer event log, so it becomes part of the resource's history, and can be used for debugging.

This will allow developers to look for this change through the K8s watch API, and react accordingly. For example this could be used to know when a game specific state has been reached once players are allowed to connect to the game server (such as a map has been loaded)

2. Have SDK functions that allow you add/edit/delete labels and annotations on the owning GameServer. This will be restricted to only labels/annotations with the prefix stable.agones.dev/sdk-.

This will allow the game server to pass back out, and edit more complex data than just GameState as well as needed. Since labels are also searchable, this can mean the GameServer can make itself visible or invisible to external process (such as matchmakers) as needed by changing its own labels.

I think this will handle the above requirements quite well, but if you have thought and/or feeling on the above - definitely please share. Feedback always appreciated.

[cyriltovena]

I could cover 1. with 2. by using my own state properties within annotations no ?

[markmandel]

That is a very good point. Sounds like we don't need #1 - the GameServerState - just label and annotation editing from within the SDK.

At the very least, we should build #2 first, and then see if there is extra need for anything else.

[EricFortin]

SGTM

…

On Thu, Jul 19, 2018 at 12:49 PM Mark Mandel ***@***.***> wrote: That is a very good point. Sounds like we don't need #1 <#1> - the GameServerState - just label and annotation editing from within the SDK. At the very least, we should build #2 <#2> first, and then see if there is extra need for anything else. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#279 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlWtdqaT3pQwMq-rB6r1CGfi832Mijeks5uILiggaJpZM4U99RE> .

[markmandel]

Work happening on SDK label + annotation editing via the SDK here:
https://github.com/markmandel/agones/tree/feature/sdk-metadata