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:
///join_session_with_type(type)
var type = argument0;
for(var i = 0; i < gms_session_count(); i++)
{
if gms_session_type(gms_session_id(i)) == type
{
gms_session_join(gms_session_id(i))
return 0;
}
}
gms_session_create(type)
You can then use this script like this (where st_* are macros with values 1, 2, 3, etc.):
// Click 'Play normal mode'
join_session_with_type(st_mode_normal)
// Click 'Play slow mode'
join_session_with_type(st_mode_slow)
// Click 'Play fast mode'
join_session_with_type(st_mode_sonic)
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'):
///on_session_change(new_id)
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)
{
room_goto(rm_play)
}
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:
http://www.gmlscripts.com/script/string_extract However, I will not dive into specifics here, since this is mostly GameMaker stuff, and GameMaker Server has very little to do with it.