Master Server Kit General concepts

From gamevanilla wiki
Jump to: navigation, search

Fundamentals

There are two key components in Master Server Kit:

  • The master server.
  • The game server.

The master server is the entry point to Master Server Kit. It is responsible for managing:

  • The player authentication and registration process.
  • The list of active (registered) game servers.

All players connect to the master server, where they can create new games or join available ones.

The game server is responsible for managing the server-authoritative logic of your game (i.e., the gameplay). You are responsible for writing the game server, because it will vary from game to game, but do not worry; we provide a useful component that you can leverage to make sure your game server works in concert with the rest of the kit.

What does server-authoritative mean?

When we talk about "server-authoritative logic" we simply mean that the server is responsible for the outcome of the game. Connected players send their input to the server, which is only accepted after deemed as valid, and render the state the server sends to them (they may also run some logic locally in order to reduce the perceived lag, specially in real-time networked games, but that is orthogonal to this discussion).

These are some excellent resources that introduce the concept of authoritative game servers:

Master server

The master server is the entry point to Master Server Kit. It is responsible for managing:

  • The player authentication and registration process.
  • The list of active (registered) game servers.

You will always have one and only one master server running at the same time.

You create a master server by creating a new game object in your scene and adding the Master Server component.

master_server_component.png

Let's examine each of the Master Server component settings in detail:

  • IP address: The IP address the master server will listen to.
  • Port: The port the master server will listen to.
  • Player limit: Check this option if you want to set a hard limit on the number of players that can be connected to the master server at the same time. If this option is not checked, any number of players will be able to be connected to the master server at the same time.
  • Max players: If the Player limit option is checked, here you can specify the maximum number of players allowed.
  • Allow guests: Check this option if you want to allow guest players on the master server. If this option is not checked, only registered players will be able to log into the master server.
  • Guest name: If the Allow guests option is checked, here you can specify the nickname to use for guest players.
  • Game registration id: The unique identifier used to verify that the game servers trying to register into this master server are legitimate.

Zone server

Zone servers are responsible for spawning new game server instances and they allow you to distribute the game server load across different machines. Their basic workflow goes as this:

  • You launch the master server.
  • You launch as many zone servers as you need to. They will automatically register themselves in the master server.
  • When a player requests the creation of a new game, the master server will choose between all the registered zone servers and request the creation of the game to the chosen one (and the selection process is an operation that you can override as appropriate). When the game server instance is spawned, it will automatically be registered in the master server so that it is eligible for matchmaking.

Zone servers are very useful for room-based games, but you are not forced to use them; you can also spawn independent, persistent game server instances that will automatically register themselves in the master server for world-based games. In that regard, you can have zero, one or several zone servers, depending on your game.

Zone servers have properties (a pair of data consisting of a name and a value). These properties will be inherited by all the game server instances spawned by that zone server. For example, you could have the following configuration:

Zone server US: Property "Region" = "US"

Zone server EU: Property "Region" = "EU"

And implement load balancing and region-based matchmaking. All the game servers spawned by the US zone server will automatically inherit the "Region: US" property, and all the game servers spawned by the EU zone server will automatically inherit the "Region: EU" property.

Or maybe:

Zone server A: Property "GameType" = "A"

Zone server B: Property "GameType" = "B"

And have different zone servers running different types of games (each zone server can launch a different game server binary). All the game servers spawned by the zone server A will automatically inherit the "GameType: A" property, and all the game servers spawned by the zone server B will automatically inherit the "GameType: B" property.

zone_server_component.png

Let's examine each of the Zone Server component settings in detail:

  • Master server IP address: The IP address the master server is listening to.
  • Master server port: The port the master server is listening to.
  • Zone server IP address: The IP address the zone server will listen to.
  • Zone server port: The port the zone server will listen to.
  • Zone server properties: The list of properties of the zone server. These properties will automatically be inherited by all the game server instances spawned by the zone server.
  • Path to binary: The path where your game server binary is located. This is needed so that the zone server knows which binary to launch when a new game server instance is spawned.
  • Maximum instances: The maximum number of game server instances that can be spawned on the zone server.
  • Pre-spawned instances: The number of pre-spawned game server instances on the zone server. These instances will be automatically spawned when the zone server is launched.
  • Spawn in batch mode: If this field is checked, the spawned game servers will be automatically launched with the -batchmode -nographics command line arguments. This is particularly useful if you are building your servers for Windows (on Linux, you can build them as headless instead).
  • Default game name: The name to use for the pre-spawned games.
  • Default game players: The maximum number of players of the pre-spawned games.

Game server

The game server is responsible for managing the server-authoritative logic of your game, which you are responsible of.

game_server_component.png

Let's examine each of the Game Server component settings in detail:

  • Game registration id: The unique identifier sent to the master server that is used to verify that this game server is legitimate.
  • Is standalone: Check this option if the game server is spawned manually and not by a zone server (useful for world-based games). If you check this option, please make sure to pass the -ip, -port, -master-ip and -master-port command line arguments (indicating the IP address and port of the game server and the IP address and port of the master server, respectively) to the game server binary when manually launching it. These are passed automatically when using a zone server and non-standalone game servers, so you need to make sure to also pass them in when using standalone game servers.
  • Name (only for standalone servers): The name of the game.
  • Max players (only for standalone servers): The maximum number of players of the game.
  • Password (only for standalone servers): The password of the game.
  • Close when empty: If this field is checked, the game server will be automatically closed when there are no more connected players left.
  • Hide when full: If this field is checked, the game server will be automatically removed from the matchmaking results when it is full.
  • Use Network Manager: If this field is checked, the connection will use the Network Manager component.
  • Properties: The list of properties of the game server. If the game server was spawned by a zone server, it will also automatically inherit the zone server properties.

Structure of the kit

User Drew Dough kindly provided the following diagram showcasing the general structure and flow of communication between the servers in the kit:

msk_diagram.png