Sessions can be used to separate groups of players into different 'instances' of the game. For example, in a 4-player game sessions could be used to make sure each group only sees each other, and nobody else. Another use-case is separating players into different 'worlds', where each world is user-generated.

Each session has 3 attributes: an ID, type and a tag.

  • ID: The primary way to identify a session. It's unique and will never change.

  • Type: A way to 'group' sessions. For example, the type can be used to differentiate between a lobby (where other players can still join), and the game in progress (where players can no longer join). A type can be any number between 0 and 255

  • Tag: Introduced in version 2.0, the tag can carry additional information about the session in a single string. For example, the tag might contain a user-friendly name for the session, or information about which world is played in the sesson.

You can create or join sessions at any point. However, you should always check whether the session ID is still valid before joining a session, since the server can delete empty sessions at any point.

Default login location

By default, all players will log in to any session with type 0. When connecting, the server will look through all sessions and find a session that has type 0. The player will be put into this session directly after logging in. You should not use type 0 for sessions where you want to fully control who enters the session.

Note: The VS mode will interfere with normal session usage. If you're using the VS mode, you cannot use session functions.

Communication between sessions

The following things are shared between sessions:

  • PlayerINIs

  • GameINIs

  • Binary Data Blocks

  • p2p messages sent with gms_p2p_all_in_game

  • p2p messages sent to a player in a different session

Anything else (player variables, global variables, instances) is separate for each session. If possible, you should try to use p2p messages for communication between sessions. If p2p messages do not fit your use case, you should use either the GameINI or binary data blocks for communication.

Asynchronous behaviour

When you call gms_session_join or gms_session_create, the player will not immediately move to the session. It takes some time for the command to be sent to the server, and for the server to send back the response (or an error). You cannot make any assumptions about how long this takes. Instead, you should set a script using gms_script_set_session_change. The script will be called every time a session change is finished. When the script is called, player information, global variables and synced instances will already have been updated.

Deciding which session to join

The server will decide what ID to give to any session, so you cannot use the ID to determine which session to join. A simple way to choose, is to use types. For example, if your game has 3 different 'modes' you could give each mode a different type. A script to join a session with a certain type might look something like this:


var type = argument0;
for(var i = 0; i < gms_session_count(); i++)
    if gms_session_type(gms_session_id(i)) == type
        return 0;

You can then use this script like this (where st_* are macros with values 1, 2, 3, etc.):

// Click 'Play normal mode'

// Click 'Play slow mode'

// Click 'Play fast mode'


If it's important for your game to wait until the join is successful before moving to the next room, you can add something like this to your session change script (see 'Asynchronous behaviour'):


var new_id = argument0;
if room == rm_choose_mode and 
    (gms_session_type(new_id) == st_mode_normal or 
     gms_session_type(new_id) == st_mode_slow or 
     gms_session_type(new_id) == st_mode_sonic)

Using tags

To store any additional information that does not fit in the type, which only accepts values ranging from 0 to 255, you can use the session tags. To create a session with a tag, use gms_session_create_ext. Once created, session tags cannot be changed, so this is only useful for storing information that you already know when creating the session.

For example, you can use the tag to store session names. This way, you can allow players to enter any session name, instead of requiring them to use IDs.

There are also a million different ways to combine multiple strings into one, so that you can store more than one thing in the tag. For example, you could use something like this script: However, I will not dive into specifics here, since this is mostly GameMaker stuff, and GameMaker Server has very little to do with it.

Reacties (2)

Laatste bericht op 14 Apr 2021

PaPdeveloper op 24 Mar 2015, 21:45:16
Wij hebben maximaal 12 spelers per sessie die tegen/met elkaar spelen. De spelers zijn best simpel; ze lopen alleen en hebben een wapen vast dat niet heel ingewikkeld geprogrammeerd is. Er zijn echter wel veel particles. Ongeveer Hoeveel sessies zouden er op één server gespeeld kunnen worden? En als er te veel activiteit voor de server is, gaat hij dan traag worden? Ik hoop niet dat dit voor ons een probleem gaat worden, maar als dat zo is, is er is vast wel een oplossing. :)
Size43 (Beheerder) op 25 Mar 2015, 14:28:59
Ik vermoed niet dat het een probleem gaat worden. 50-60 personen is het meeste dat er ooit op de server is geweest.
De server kan nog veel meer aan dan dat er nu gebruikt wordt.

Mocht het recht en probleem worden dan kan ik altijd nog een duurdere server huren ;)