呼び出し操作
基本コンセプトのページで説明したとおり、操作はPhotonアプリケーションが定義するリモートプロシージャコールによっておこなわれます。
クライアントのAPIにはPhotonピアクラスが含まれており、そこにはサーバー上で操作を呼び出すメソッドがあります。
多くのデモでは、簡便性のため高度なレベルの LoadBalancingClientクラスを使用しています。
LoadBalancingPeerは、ほとんどのLoadBalancing API操作をカバーしています。
たとえば LoadBalancingClient.OpJoinRoomはJoinGame操作への呼び出しをラップしています。
Photonからの操作結果
サーバー上のアプリケーションは操作ごとに結果を送信できます。
たとえば **"GetHighscores"**操作の場合、明らかに結果を利用できるためスコアのリストが含まれます。
RaiseEventなど他のRPCは、活用できない結果を安全に省略できます。
一般的に操作の結果の取得は、ネットワークが原因となり若干の時間を要します。
このため、結果はすべてIPhotonPeerListener.OperationResultへの呼び出しによって取得されます。
結果のコールバックは、プラットフォームによって異なる場合があります。
以下のコードはC# callbackインターフェースのもので、ゲームへの実装が必要です：
C#
public interface IPhotonPeerListener
{
//[...]
void OnOperationResponse(OperationResponse operationResponse);
ゲームがloadBalancingPeer.DispatchIncomingCommandsを呼び出した場合のみ、コールバックOnOperationResponseが呼び出されます。
これによって、正しいスレッドのコンテキストでのコールバックの取得が容易になります。
多くの場合、ゲームループ内で複数のフレームごとにDispatchIncomingCommandsを呼び出せば十分です。
カスタム操作
カスタム操作はExit Gamesのアプリケーション（Lite、ロードバランシングなど）内で定義されていない操作です。
基本的にはLoadBalancing APIがカバーしない操作はすべて「カスタム」です。
バックグラウンドでは、 JoinGameなどのようなカスタムでない操作も全く同じメソッドを使用していることが分かります。
以下の例は、LoadBalancingClient.OpJoinRoomからのコードです：
C#
public bool OpJoinRoom(string roomName, string[] expectedUsers = null)
{
// [...]
EnterRoomParams opParams = new EnterRoomParams();
// [...]
return this.loadBalancingPeer.OpJoinRoom(opParams);
}
明らかなとおり、これはLoadBalancingPeer.OpJoinRoom向けのラッパーです:
C#
public virtual bool OpJoinRoom(EnterRoomParams opParams)
{
// [...]
Dictionary<byte, object> op = new Dictionary<byte, object>();
// [...]
return this.OpCustom(OperationCode.JoinGame, op, true);
}
明らかなとおり、OpJoinRoomは送信対象としてOpCustomを内部的に使用しています。
メソッドは使用率を合理化するためのラッパーで、これも実施すべき使用法です。
OpCustomへの呼び出しは、操作の送信に必要な部分を示しています：
OperationCode: 操作を識別するための単一バイトです（負荷を最小化するため）。
たとえば(byte)OperationCode.JoinGameは255です。Operation Parameters: サーバーが予期する一連のパラメータです。
ここでもネームではなくバイトが使用され、パラメータごとの負荷が最小化されます。Reliability: 3つ目のOpCustomパラメータは、操作がサーバーに確実に到達するのか、または
失われる可能性がある（信頼性が低い）のかを定義します。
ただちに交換できるデータは信頼性が低い場合があります。JoinGame、Authenticateやこれらに類似した操作は
高信頼性での送信を推奨します（これが、この場合に「true」となる理由です）。ChannelId: これはシーケンスで、この操作は順序づけのために設定されます。ほとんどの場合は「0」で問題ありません。Encrypt: オプションで、クライアントとサーバー間でデータを暗号化します。
パフォーマンスを消耗するため、必要不可欠な場合のみ使用してください。必ずしも必要ではありません。
ここではfalseとなっています。
最後の３つの値は、正確には操作の一部ではありません。
SendReliable、ChannelId、Encryptは操作ごとに変更できる通信用の設定です。
操作用のバイトコード、パラメータや結果の値はサーバー側で定義されます。
呼び出すには、クライアント側でこれらを使用する必要があります。
操作呼び出しの戻り値
説明を簡潔にするため、OpCustom (OpJoinとその他の操作)には戻り値がある点は無視しました。
ただし、この戻り値は実用的です：
クライアントの最新の状態によって、操作を呼び出せない場合があります。
OpCustomの結果によって、その操作を送信できるのか無視されるのかがすぐにわかります（クライアント側）：
True:操作が可能で、（SendOutgoingCommands()によって)サーバーに送信されます。
OpCustomに渡した値はすべてシリアライズされるため、データは任意に変更できます。False:操作は送信できません（たとえば、クライアントが接続していないなどのため）。
この場合、クライアントライブラリでデバッグのヒントを確認してください（`DebugReturnを参照してください）。
新しい操作の定義
多くの場合、新しい操作の定義はサーバー側でおこなわれるため、操作の実装や使用はサーバー側のコンテキストで説明されます。
「オペレーションの追加」(../app-framework/adding-operations)を参照してください。