Workflow

To get an impression of how to work on the client, we will use the server's Lite logic. This application defines rooms which are created when users try to join them. Each user in a room becomes an actor with its own number.

A simplified workflow looks like this:

• create a LitePeer instance
• from now on: regularly call service() to get events and operation responses and to send operations (e.g. ten times a second)
• call connect() to connect to the server
• wait until the library calls onStatusChanged()
• the return code should equal StatusCode::CONNECT
• call opJoin() to get into a room
• wait until the library calls onOperationResponse() with operation code OPC_RT_JOIN
• send data in the game by calling opRaiseEvent()
• receive events in onEvent()
• when you are done: call opLeave() to quit/leave the game room
• wait for a response to "leave" in onOperationResponse() with operation code: OPC_RT_LEAVE
• disconnect with disconnect()
• wait for status code StatusCode::DISCONNECT in onStatusChanged()

Combined with the server's Lite application, this simple workflow would allow you to use rooms and send your game's events. The functions used could be broken down into three layers:

• Low Level: service(), connect(), disconnect() and onStatusChanged() are directly referring to the connection to the server. This level works with UDP/TCP packets which transport commands (which in turn carry your operations). It keeps your connection alive and organizes your RPC calls and events into packages.
• Logic Level: operations, results and events make up the logical level in Photon. Any operation is defined on the server (think RPC call) and can have a result. Events are incoming from the server and update the client with some data.
• Application Level: Made up by a specific application and its features. In this case we use the operations and logic of the Lite application. In this specific case, we have rooms and actors and more. The LitePeer is matching the server side implementation and wraps it up for you.

You don't have to manage the low level communication in most cases. However, it makes sense to know that everything that goes from client to server (and the other way round) is put into "commands". Internally, commands are also used to establish and keep the connection between client and server alive (without carrying additional data).

All functions that are operations (RPC calls) are prefixed with "Op" to tell them apart from anything else. Other server-side applications (like for example MMO or your own) will define different operations. These will have different parameters and return values. These operations are not part of the client library but can be implemented by calling opCustom().

Aside from operations, there is a separate communication layer to make UDP reliable. Everything that goes from client to server (and the other way round) is put into "commands" and some commands establish and keep the connection between client and server (without carrying additional data).

Callbacks

PhotonPeer uses the virtual functions of the class ExitGames::Photon::PhotonListener to do callbacks. Each function is called in separate cases:

• onStatusChanged() is for peer state changes (connect, disconnect, errors)
• onOperationResponse() is for operation responses (join, leave, raiseEvent and custom operations, etc.)
• onEvent() gets called for events coming in
• debugReturn() is called to pass debug output to you (not used by release builds)

The calls to onStatusChanged() are of special interest, as they denote connection status changes and errors.

Getters/Setters

The following getter- and setter-functions in PhotonPeer are of special interest:

• setTimePingInterval() sets the time between ping operations
• getRoundTripTime() returns the ping between the Photon client and the server
• getRoundTripTimeVariance() shows the jitter (variability of the roundtrip time)
• getServerTime() is the continuously approximated server's time in milliseconds