How GameLift Local works with game sessions

Hi @REDACTEDUSER

Could you please help me understand how you were able to reproduce this? Specifically, I don't understand what you meant by "log in" and "log out", since GameLift has no concepts of authentication. From your description, I'm guesting this was what you did, could you confirm?

1. java -jar GameLiftLocal.jar -p <MySdkEndpointPort>
2. Run server
3. Server was able to connect to GameLiftLocal and start heartbeating
4. `aws gamelift create-game-session --endpoint-url http://localhost:<MySdkEndpointPort> --maximum-player-session-count 2 --fleet-******
5. aws gamelift create-player-sessions --endpoint-url http://localhost:<MySdkEndpointPort> ...
6. A game session successfully created, and you passed the connection info to your client, and client was able to connect
7. You terminated connection with the server, the player session was able to terminate (?)

Next, you called aws gamelift create-game-session... again but it says No available process?

You misunderstood the post.

I am using my own game client in this phase. So the log in and the log out means the process, when you get through the Game Client to game server and then you just log out through it.

Which is in basic nothing more, then then running this cycle in game client: create game session -> create player session -> accept player session on game server and when you log out: remove player session on game server.

This process should be 1:1 to your mentioned AWS commands.

If the above case is true, then that error is expected.

Each server process (i.e. the executable that you run to connect to GameLiftLocal) in its lifetime should only host a single game session*. Once the game session is completed (e.g. game ended, or all players left), you should call GameLiftServerSDK::ProcessEnding and promptly exit the process, e.g. exit(0). The GameLift onbox process manager will see that the process has been terminated, and active # of processes is less than desired, and start another process for you.

In the case of GameLiftLocal, you can start multiple server processes, and they'll all connect to GameLiftLocal. Then, you can create N game sessions with N equal to the number of processes that you started. Once game session is ended, your server process should exit, and you could manually start a new one since there is no process manager to automatically do this for you.

* There is a way to re-use the same process, via GameLiftServerSDK::TerminateGameSession, but it is not recommended and has since been deprecated in SDK 4.x. We recommend to always start new processes because it doesn't really cost you anything (unless your process startup is very time-consuming or computationally intensive), and has the added benefit of starting the memory from fresh

You should start with this... Then I don't understand the game session concept...

Why the game session is dependent on the gameserver lifetime? I though I can create how many game session I want on the server (of course, there should be some limitations). But why the game session is dependent on the fact I have to close the server? Basically restart it?

I was thinking about game session like FPS matches or so, so one server can handle a bunch of them.

Yes, you can create as many game sessions you want on the instance. (There is a limitation of 50 concurrent game sessions at the time of this writing. See my answer here for more details: https://forums.awsgametech.com/t/server-with-multiple-rooms/11089/5)

I think there is a bit of confusion on the term, "Server". I understand that it is a very overloaded word.

Whenever we say "Server Process", it means the executable (e.g. an .exe file) that you run which opens up a port and handles player traffic.

The hardware on which "Server Process" are run, is called an "Instance" or "Fleet Instance", see https://docs.aws.amazon.com/gamelift/latest/apireference/API_Instance.html

In this case, we are not restarting the hardware, we are simply restarting the executable.

Oh yea, that's the problem here... The "server" in terms of GameLift is not the physical machine, but the "software process".

So if I understood correctly: On physical instance, you can host as many "servers" as you can, which means you can start the server instance as many times you want? So the "Game Session" in GameLift terminology is just another server process?

Then I understand why the GameLift Local does not allow another game session. I was supposing I can host a bunch of session on single server process. The GameLift Docs should really need some updates about these terms. I was rereading the docs whole weeks, but this fact I couldn't tell from them.

Ok, now I am happy again 😄

I am understanding the ProcessEnding part, I have also this implemented as it should be. But there was missing the knowledge, that game session is hosted per SW instance.

I mostly alright with the docs, this was the only main problem with this fact. As I am not greatly involved in the techniques of hosting the game servers, I couldn't tell by my own there is something like multiple processes of GameServer. And in case of GameLift, thats the crucial information I think.

My another remark is only about the GameLift SDK for Client. I was searching about an hour till I figured out, I need to clone GitHub repo and build custom dll for Unity. There are some mentions about it, but nothing useful. Mostly only the deprecated Unity mobile SDK.

And of course, if the Server API could be in NuGet... And compatiible with .NET 5 :slight_smile: ... I needed to rewrite BeginInvoke/EndInvoke methods as they are not supported in this version.

It's kinda weird, when the GameLift client is in NuGet (which you cannot use with Unity), but for custom .net server, there is no SDK in NuGet, and you have to download the project by yourself.

Great, thanks for your feedback. I'll take this up to the team.

Nice! Thanks for your time! :slight_smile:

Yes, your understanding is correct now :slight_smile:

Here is an example of how to call ProcessEnding in Unity: https://github.com/aws-samples/aws-gamelift-and-serverless-backend-sample/blob/master/GameLiftExampleUnityProject/Assets/Scripts/Server/GameLift.cs#L141

I'll work with our technical writers to make these more clear in the doc. Do you have any suggestions on which docs we could focus on clarifying? E.g. which doc(s) do you think should have explained this concept? This can really help us facilitate the update.

[quote="JamesM_Aws, post:10, topic:11113"] However, we found a lot of customers are not optimizing correctly, e.g. memory leak, and having a long running process introduces a lot of pain. Therefore we deprecated the “TerminateGameSession” API and encourage everyone to restart their processes after each game session ends. [/quote]

Hi @REDACTEDUSER

The API is deprecated, it means it gonna be removed at some point? I just realize this feature is necessary to support multiple game sessions per game process. Of course with the trade-off to manage memory footprint right yourself.

It will not be removed in 3.x or 4.x for backwards compatibility reasons; however, if we launch a new major version of the SDK, it's possible that it might be removed. We'll consider your use case and determine if we should continue to support this API or come up with a better alternative.