The Beamable Multiplayer feature allows game makers to create real-time and turn-based multi-user game experiences.
Support turn-based gameplay with seamless integration with rewards, matchmaking, and leaderboards without the need to build, run, and scale a game server.
What is a game server? A game server is the source of event coordination in a multiplayer video game. The server transmits enough events about its internal state to allow each connected client to maintain their own accurate version of the game. Events may contain various types of information including; properties about the game world, the players, and player input. See Wikipedia for more info.
More details are covered in related feature page(s).
• Matchmaking - Allows game makers to connect remote players together for shared experiences
Here are the leading options;
- The server processes game-specific logic. The server is the game.
- Ideal For: Persistent world games, MMOs, and first-person shooters.
- The server introduces client to client. Key communication passes directly from client to client.
- Ideal For: First-person shooters and games that can tolerate cheating.
- The server sends and receives events between all clients in a match. The match is the "Room" in which all the game players interact. Each client is the game.
- Ideal For: Real-time strategy, tower defense, MOBAs, card battlers, auto chess, and more...
Here is a comparison of various game servers;
|Default Benefits||Relay Server||Dedicated Server||Peer-To-Peer Server|
|Simpler Server Infrastructure & Simpler Setup||✔️|
|Higher Security||✔️ (Determinism)||✔️ (Server-Authoritative)|
The Beamable Multiplayer API is lean and straightforward to setup. The pipeline and workflow for development are ready out-of-the-box on day 1 of development, allowing game makers to focus on game-specific client logic.
Beamable's Multiplayer is a relay server. This means that Beamable keeps a list of all events sent from all clients in a given match. Then, via push or pull, each client can ask "for all events since last time I asked". The clients then MUST advance the game play deterministically, replaying each player’s input, so each client is in sync.
This section contains any advanced configuration options and workflows.
Here are some common terms:
|Client||This refers to the instance of the game code that is running on each player's local device (e.g. Mobile Phone)|
|Event||The data packet that represents a player's turn in the game. This may be any serializable C# structure.|
|Latency||This measurement indicates the average total time needed for the game client to send an event to the Multiplayer server and receive the reply. Latency is measured in milliseconds (e.g. 200ms)|
|Matchmaking||This is the process of choosing a |
Note: See Matchmaking for more info
|SimClient||This class is the main entry point for Beamable's Multiplayer feature.|
|This is network buffer. It represents how long the Multiplayer server holds game events before sending them back to clients. E.g. With a value of 5, the Multiplayer server will hold 5 events before sending those 5 to the game client's. A higher value provides more consistency to the clients' rendering experience, but at the cost of higher latency.|
|This represents a set of players playing a specific instance of the game together. Only players in the same match may collaborate, compete, and communicate.|
|This is the rate (in times per second) at which the client receives event updates from the Multiplayer server. As a data optimization, typically this is set lower than the rendering frame rate of Unity.|
|Server||This refers to the instance of the server code that sits between the game's clients and manages distribution of the game events.|
To be more secure against any malicious hackers in your multiplayer game’s community, consider never sending any game object state (player’s heath, power of weapon, etc) as part of the messages to be synchronized over the network.
Any enterprising hacker can “easily” hack a game client to send inflated values which will only make the game worse for everyone. If all a player can do is send an “action”. i.e. “What I did” (“I fired my equipped gun” rather than “I hit player 2 for 100 damage”), it becomes quite a bit harder for someone to cheat.
A hacker may also attempt to replay actions AGAIN for a particular turn or to send malformed game event object messages that can lead to a worst experience for other players.
In multiplayer gaming, matchmaking is the process of choosing a
MatchId based on criteria (e.g. "Give me a match to play in with 2 total players of any skill level"). Beamable supports matchmaking through its matchmaking service.
See Matchmaking for more info.
One of the challenges of developing a multiplayer game is testing it frequently as an individual developer. Finding a friend to play against you every time you run the game in development is prohibitive.
Here are 2 strategies to help the development process.
The sample game includes an optional bot opponent. This is an AI that plays against you. Simply click "Start Game: Human vs Bot" from the Menu Scene to activate it. Architecturally this is similar to the full game and it fully uses the Beamable Multiplayer event objects for each player move. However, it requires only one human player.
The sample game allows a workflow to test the full 2 player experience with relative ease. Build the Unity sample project as a standalone game for either Mac or PC. Then run the game in the Unity Editor also. Simply click "Start Game: Human vs Human" from the Menu Scene in both game clients to activate it.
Doing a build takes a few minutes. Depending on the specifics of your game, it may not be required to rebuild the standalone after every code change. See Game Maker User Experience for more info.
This is the process of choosing a
MatchId based on criteria. E.g. "Give me a match to play in with 3 total players with beginner skill level". Beamable includes an optional, light-weight Matchmaking service.
Updated about 1 month ago