Glossary
A (low level) command to acknowledge reliable commands. Used for Reliable UDP (RUDP).
Players in a room are also called "Actors".
An actor has an ActorNumber, also referred to as actorId, player number and player id, valid in the room.
Values for the ActorNumber start at 1 in each room and are not re-used (when a client leaves and another joins).
Applications contain the game logic, written in C# and run by the Photon Core.
They extend the abstract class Application for this. The Photon Cloud makes use of Virtual Applications.
In the Photon Cloud, the Application ID (AppId) is the main identifier for a Title and its Virtual Application.
You can find your AppId prominently in the Dashboard. It is needed for most of our demos.
Application Version (AppVersion)
In all client SDKs except PUN, AppVersion is the same thing as GameVersion.
If you use PUN and non-PUN clients at the same time or if you have clients with different PUN versions,
you need to take into consideration PUN's specific AppVersion format: {gameVersion}_{PUN_version}.
So if you set the gameVersion to "1.0" in PUN and use PUN version "1.80" then the resulting AppVersion is "1.0_1.80".
Vector3 but you need to check the "CustomTypes.cs" of PUN to support this in other client SDKs.
In the Photon Server SDK, the binaries folders contain platform-specific builds of the Photon Core.
They are prefixed with "bin_" and in the "deploy" folder.
A batch file or MsBuild project to compile and copy applications for their deployment.
Takes care of getting a clean build for deployment.
A game's logic, which runs on top of Photon Core.
This "layer" handles operations and events.
Can refer to either low-level channels in the RUDP protocol or to the "conversation" channels in Photon Chat.
Photon Chat is a lightweight service for communication between users.
Users can join channels, send private messages and make use of a user status which is available for friends.
Chat uses a separate connection and is independent of rooms.
Applications that connect to a server are called clients.
In Photon's case, they initiate a connection to a server, which enables them to message other clients.
Photon clients are programmed with a client API, also referred to as client library.
A cluster consists of a Master Server and several Game Servers. Each cluster is separated from any others.
Often a Region has only one cluster.
Commands are used on the eNet protocol layer to transport your data or establish / shutdown connections.
You won't write these, but we will explain them for your background knowledge.
Concurrent Users for a game are all clients that have a connection to a server at the same time.
The CCU count is the basis for the prices in of Photon Cloud subscriptions.
Don't mix this up with Daily Active Users (DAU) or Monthly Active Users (MAU).
Users of a game play only a small amount of time per day and much less per month (just think about all the days you couldn't play for some reason).
Before clients can call operations on Photon, they need to connect and establish a connection.
Any operation that is not in the client API or new to the server side.
In Photon, you can set Custom Properties for Rooms and Players.
In both cases, the custom properties are provided as Hashtable and the key must be of type String but can have any (serializable) value.
Custom Player Properties are deleted when players abandon a game.
The dashboard aggregates counter data and generates graphs for monitoring purposes.
Photon applications can be managed from their respective dashboard.
In the Server SDK, this folder contains everything that is needed to run Photon.
Namely: the binaries-folders and compiled Applications.
In general: a mobile.
Or any other system to runs your client application.
Ends a connection between client and server.
Happens when a player wants to exit the client-app or there is a timeout.
Also, the server logic could disconnect players.
Amount of time in milliseconds that Photon servers should wait before disposing an empty room.
A room is considered empty as long as there is no active actors joined to it.
So the room deletion timer starts when the last active actors leaves.
When an actor joins or rejoins the room when it's empty the countdown is reset.
By default, maximum value allowed is:
- 300.000ms (5 minutes) on Photon Cloud
- 60.000ms (1minute) on Photon Server
Events are asynchronous messages sent to clients.
They can be triggered by operations (as side effect) or raised (as main purpose of an operation) and are identified by an event code.
The origin is identified as ActorNumber.
Short for event code.
Identifies the type of events and which information (and types) the event contains.
Fusion is our state of the art state transfer networking solution. It aims to support more than 100 players in a session even for competitive games.
Depending on context, "game" refers to a title/application or a round/match between a few players.
We try to stick to "Title" for the first meaning and use "Room" for the second.
Game Servers handle the actual in-game communication for the clients.
They only communicate with the Master Server, so they neither provide friends lists nor room lists.
The GameVersion is a string any game can set.
In the Photon Cloud it can be useful to separate users of incompatible versions into separate Virtual Applications.
Time between request and ACK.
Might differ on client and server. Measured as RoundTrip Time (RTT).
Refers to the Hive Application in the Photon Server SDK.
A basic business logic to get you started.
This class the fondation for many of our SDKS, including Photon Client SDK
It contains logic to wrap Photon's load balancing workflow in which a Master Server knows several Game Servers.
When joining a room, clients switch to a specific Game Server.
A lobby is a virtual container or "list" of rooms. You can use multiple lobbies and there are different types of lobbies, too.
E.g. not every lobby type will send the room-list to clients.
By default, players can't communicate in the lobby. In fact, they never know another client is also in the lobby.
A client can only be in a lobby, a room or neither.
The Photon Server is designed to run as service and does not have extensive GUI.
There are two sets of log files used instead: Applications write into "deploy\log".
Photon Core writes into "deploy\bin_*\log".
The process of finding a game or match.
Master Client is a "special" client per room.
In absence of custom server code, it can be made responsible for handling logic that should only be executed by one client in a room (e.g. starting a match when everyone is ready).
A new Master Client is automatically assigned when the former leaves.
Unless explicitly set, the Master Client is the actor (player) with the least actor number among the active actors.
The Master Server handles the matchmaking for a region or cluster. It distributes rooms across a range of Game Servers.
It is important that clients look up their Master Server via the Name Server.
Messages are in general anything that updates someone else or does something on the server.
- In Photon terms: All Operations, Responses and Events are messages.
- In PUN terms: All RPCs, synchronization updates, Instantiate calls, changing Custom Properties (including playerName) are messages.
Sending an Event (or RPC) to all other clients counts as one message per player in that room: One send, the others receive.
PUN is special, because it tries to aggregate updates by OnPhotonSerializeView.
If possible, the updates of several objects are aggregated into one message.
Also, the observe mode affects this: "Unreliable On Change" stops sending anything when the GO doesn't move between updates.
In worst case one object can cause 10 messages per second per player. That's not common however.
We limit the messages (updates) per room and per second for two reasons:
- Things break when you send too many updates. There is no fixed cap though. This depends on traffic, devices, etc.
- Make sure everyone has a fixed slice of our shared servers.
The messages per room and second are shown in the Dashboard.
The Name Server provides a list of available regions to clients and handles their authentication requests.
When the client selected a region, the Name Server provides the Master Server address for it.
There are multiple, loadbalanced Name Servers.
Another word for RPC functions on the Photon server side.
Clients use operations to do anything on the server and even to send events to others.
Short for operation code.
A byte-value that's used to trigger operations on the server side.
Clients get operation responses with opCodes to identify the type of action for the returned values.
This term refers to one side of a connection.
The client has a peer and the server is the remote peer for the client.
Amount of time in milliseconds that an actor can remain inactive inside the room before it gets removed.
An actor becomes inactive when it leaves the room temporarily or gets disconnected unexpectedly.
A value of -1 means inactive actors do not timeout.
The C++ core of Photon. It handles connections and the eNet protocol for you.
The Photon administration tool of the Photon Server SDK.
Start the PhotonControl.exe to get a tray-bar menu and easily manage Photon's services.
The Photon Server SDK contains the tools to run and build your own Photon Server instances on basically any Windows Machine.
Read more.
This is the configuration file for the Photon Core.
It configures IPs, applications and performance settings.
Formerly it was called PhotonSocketServer.xml and for a short time PhotonSocketServer.config.
Photon Unity Networking is a C# client package for Unity.
It uses Photon's lower-level features to re-implement Unity's built-in networking in a more advanced form.
Many of the lower-level Photon features are covered by PUN. You rarely have to worry about a ReturnCode or Commands, e.g.
It is now in Long Term Support mode and won't get major feature updates anymore. New projects should use Fusion or Quantum on the client side.
The Policy Application runs on Photon to send the "crossdomain.xml".
Webplayer platforms like Unity Webplayer, Flash and Silverlight request authorization before they contact a server.
Quantum is our state of the art predict rollback networking solution.
The term region refers to hosting locations of the Photon Cloud.
Reliable commands will reach the other side or lead to a timeout disconnect.
They are sequenced per channel and dispatching will stall when a reliable command is temporarily missing.
Primary result of every operation in form of a byte-value.
Can be checked if an operation was done successfully (RC_OK == 0) or which error happened.
Players meet in rooms to play a match or communicate.
Communication outside of rooms is not possible.
Any client can only be active in one room.
Photon rooms have these properties and methods:
- create and join rooms by name
- set Custom Properties for the room and players
- define maximum amount of players
- hidden (do not show in lobby) or visible
- close (no one can enter) or open
Short for Remote Procedure Call.
Can be a term for Operations (calling methods on the server) but in most cases it refers to calling a method on remote clients within PUN games.
Reliable UDP.
A protocol on top of UDP which makes sent commands reliable on demand.
A sender repeats reliable messages until they are acknowledged
Another name for the Photon Core.
With eNet, client and server monitor if the other side is acknowledging reliable commands.
If these ACKs are missing for a longer time, the connection is considered lost.
Turnbased games are any game in which players take turns.
They might play one after another or at the same time - lots of variants are possible.
Photon's support to perist games is being phased out. Clients can use an external service to store and load the state.
Unreliable commands are not ACKd by the other side.
They are sequenced per channel but when dispatching, the sequence can have holes.
The Photon Cloud runs a single game logic (Application) for all titles.
Internally, games are separated per AppId and GameVersion.