Realtime Intro
Overview
Photon Realtime is our base layer for multiplayer games and our higher-level network solutions Fusion or Quantum. It solves problems like authentication, matchmaking and fast, cross-platform communication with a scalable approach.
On its own, it does not provide object synchronization or tight engine integration. It can be a good choice if you know which values you need to sync and how to drive the simulation with those.
These pages are the manual for the client-side Realtime C# SDK (for .Net and Unity) but also provide an overview of the workflow and structures involved. The term Photon Realtime relates in the same way to the client-side APIs, the server-side and the workflows and features both sides use.
Concepts
Connections
Photon Realtime always connects clients to a Photon Server, as opposed to connecting clients directly. The Photon Cloud provides a battle tested, scalable infrastructure for any type of game.
The server side is split into three distinct server types:
- Name Servers provide region lists and addresses and authenticate the users.
- Master Servers handle matchmaking per region.
- Game Servers host the actual gameplay in rooms.
A Realtime client is only connected to one server type at any time. This means, matchmaking is only available while the client is not active in a room (and vice versa). Most of the time, the client API will switch servers as needed but it makes sense to know them to understand the workflow of clients.
Users and Authentication
Photon Realtime does not store user information for your app. Instead, clients can authenticate with an external service and ask the Photon server to validate this. Photon servers rely on an "Authentication Provider" to verify the provided authentication values and set the userID for the client.
Matchmaking
Photon Realtime offers a lean, client-driven approach to matchmaking. Rooms represent gameplay sessions with some common ("well known") properties: open, visible, max players and a room name as ID. Custom Room Properties (key-values) can be used to customize and enhance the matchmaking.
Lobbies can be used to list visible rooms on the clients but the most effective workflow is to ask the server to join a random room fitting a given filter. Example: Ask for a room with 4 players max and the active "map" being "saturn. The SQL Lobby extends this concept and allows SQL-alike queries as filters. It is possible to ask for a room matching "level > 5 AND level < 10".
The built in matchmaking can get you a long way but Photon also plays nice with external matchmaking. Rooms are identified by name, so assigning a room to players is simple. With Matchmaking Tickets, an external server can define the matchmaking for the client, closing the door for joining any but the defined room.
Players
When a client joins a room, it represents one player or "actor". By default Photon shares player nickname and an actor number is used as reference for gameplay.
Rooms may be set to share the server-verified userID.
Players are usually removed from the room when they disconnect or leave. Optionally, there is a "player time to live", which temporarily turns the user inactive should the client lose connection.
Communication
Within a room, players can share state and data in several ways:
- Events can be raised with custom code and content. Perfect for frequent updates such as input and positions.
- Custom Room Properties act like a Hashtable which can be updated by either player. This can store general room state for pickup items but also matchmaking tags.
- Custom Player Properties provide a Hashtable per player. Store the players look, equipment and similar values.
Operation, Response, Event
Clients call Operations on the server side and get Operation Responses for most of those. Aside from Operation Responses, clients also receive Events, which are used independently of what the client asked for.
While in a room, the operation RaiseEvent is used to pass data to the others, which receive a custom event.
The Realtime client API summarizes common workflows and abstracts-away some of the required operations. For example, the initial Connect-call integrates OpGetRegions and OpAuthenticate. Still, these operation calls may show up in logs and sometimes need to be handled independently.
Messages
Operations, Responses and Events are sent within Messages.
For our reliable UDP protocol, you can choose if these Messages are sequenced or not and if the messages are reliable or not. In TCP and WebSockets, reliability and order are mandatory (by the transport itself).
Where To Go Next
