Imprementation of realtime_networkgame

Imprementation of realtime_networkgame
リアルタイム通信ゲームの実装例 2016.5.28 株式会社Aiming 山藤智之
自己紹介 • 山藤智之 • 株式会社Aiming所属 • 携わった作品 – Blade Chronicle – 剣と魔法のログレス（PC） – 剣と魔法のログレスいにしえの女神 • 猫大好き！猫アレルギー系エンジニア
Aiming？ • オンラインゲームの会社 • 各職人材募集中です！！
今日の内容 • オンラインゲームを作るのに必要になる通信技術のお話 – 通信規格 – 通信内容 – 通信ライブラリ • RPC（Remote Procedure Call） • IDL （Interface Definition Language）
通信規格 • UDP – 単方向通信 • 届いたか？までは責任持たない • 保証しようとするとTCPと同じ処理をアプリケーション側で適切に実装しないといけない • TCP – 双方向通信 • 配送が順序通り届いた事を保証してくれる • UDPに比べて速度は遅い • UDPに比べて通信量は多い
常時接続 / 非常時接続 • 非常時接続（単方向通信） • リクエストに対してリプライ • クライアントからの要求が必須
常時接続 / 非常時接続 • 常時接続（双方向通信） • リクエストに対してリプライ • サーバ側からのプッシュが可能 • クライアントに要求できる
通信内容 • キーフレーム形式 – フレーム毎のコントローラーからの入力を交換し合う – 対戦格闘ゲームとかで有効 • メッセージ形式 – 手続き呼び出しをメッセージ化して、必要なパラメータをやり取りする – MMOとかで有効 – 手続き毎にコードを記述するので大規模向き • ゲーム、プロジェクト規模に合わせて適切な企画・形式を選ぶ
メッセージ / キーフレーム • 通信量の少なさ – キーフレーム＞メッセージ • 処理の簡単さ（高速） – キーフレーム＞メッセージ • 拡張の容易さ – メッセージ＞キーフレーム • 複雑なデータのやり取りのし易さ – メッセージ＞キーフレーム
通信ライブラリ • 作った理由 – 社内共通ライブラリにしたかった • アプリケーションの移植性向上 – 当時はあまりちゃんとした物がなかった – 送信・受信時のメモリ管理をキチンとやりたかった – 自社製品のそれまでのノウハウを活かしたかった
通信ライブラリ • 要件 – とりあえずメッセージベースの物 – アプリケーションが変わっても、あまり変わらないネットワーク処理部分を分離させた物 – クライアント端末が変わっても大丈夫な様に • PC • スマホ • 家庭用ゲーム機
通信ライブラリ • 主にこの部分
通信ライブラリ • 主にこの部分
通信ライブラリ • 主にこの部分 Windows WinSock Linux Unix Socket Mac BSD Socket ソケットをラップした何か通信関数ゲームアプリケーション
通信ライブラリ • 主にこの部分 Windows WinSock Linux Unix Socket Mac BSD Socket ソケットをラップした何か通信関数ゲームアプリケーション
通信ライブラリ • メッセージ形式を利用したライブラリ – ソケット部分のコード • 幾つかのプラットフォームをサポート • 異なるプラットフォーム間での通信の提供 – RPC（Remote Procedure Call）の提供 • プログラム記述難易度の低減 • 通信プロトコルの隠蔽 – HTTP / ゲーム専用プロトコル – IDL（Interface Definition Language）の提供
RPC (Remote Procedure Call) • プログラムから別のマシンで動いているサブルーチン（手続き）を呼び出す仕組み • 通常はネットワーク越しに、通信対象のマシンで動作するプログラムの手続きを呼び出す
RPC (Remote Procedure Call) Network.function_call(“デザイナー”); void function_call(std::string types) { printf(“%s募集中n” , types); }こんな感じに書くとコレが実行される
RPCを実現するために • RPCを実現する為に必要になりそうな情報 – どの関数を呼ぶ？ – 各関数に渡さないといけない引数リスト • 呼び出し順序の保障 • 適切な単位（メッセージ毎）の受信 – 引数が途中で途切れたりしない様に • バイトオーダーの吸収 – リトルエンディアン / ビッグエンディアン
リトルエンディアン 8bit 16bit • バイトオーダーに影響を受けない数値の受け渡し方ビッグエンディアンデータの表現 0A 0B 0C 0D 0A0B 0C0D 0D 0C 0B 0A 0C0D 0A0B 8bit 16bit 整数値０ｘ0A0B0C0D
データの表現 • バイトオーダーが異なる２台で通信すると…？ 0D 0C 0B 0A 整数値０ｘ0A0B0C0D リトルエンディアン８Bit リトルエンディアン１６Bit 0D0C 0B0A 整数値０ｘ0B0A0D0C メモリのイメージをそのまま移すと
データの表現 • バイトオーダーが異なる２台で通信すると…？ 0D 0C 0B 0A リトルエンディアン８Bit リトルエンディアン１６Bit 0D0C 0B0A メモリのイメージをそのまま移すと表現したい数値が変わってしまう！！整数値０ｘ0A0B0C0D 整数値０ｘ0B0A0D0C
• バイトオーダーに影響を受けない数値の受け渡し方データの表現 0D 0C 0B 0A 送りたい数値リトルエンディアン８Bit リトルエンディアン１６Bit
• バイトオーダーに影響を受けない数値の受け渡し方データの表現 0A 0B 0C 0D 0D 0C 0B 0A 送りたい数値ネットワーク経路上一度整列リトルエンディアン８Bit リトルエンディアン１６Bit
• バイトオーダーに影響を受けない数値の受け渡し方データの表現 0A 0B 0C 0D 0D 0C 0B 0A 0C0D 0A0B 送りたい数値受信側受け取り時リトルエンディアン８Bit リトルエンディアン１６Bit ネットワーク経路上一度整列
• 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効整数値０ｘ00000A0B データの表現 0A 0B 00 00
整数値０ｘ00000A0B • 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効データの表現 0A 0B 00 00 0000_0000 0000_0000 0000_1010 0000_1011
整数値０ｘ00000A0B • 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効データの表現 0A 0B 00 00 0000_0000 0000_0000 0000_1010 0000_1011 011000_0101 後続するデータがあるので最上位は１
整数値０ｘ00000A0B • 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効データの表現 0A 0B 00 00 0000_0000 0000_0000 0000_1010 0000_1011 0101100_00101000_0101 後続するデータがあるので最上位は１
整数値０ｘ00000A0B • 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効データの表現 0A 0B 00 00 0000_0000 0000_0000 0000_1010 0000_1011 0100_00001100_0010 00001000_0101 後続するデータが無いので最上位は０
整数値０ｘ00000A0B • 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効データの表現 0A 0B 00 00 0000_0000 0000_0000 0000_1010 0000_1011 0100_00001100_0010 0000_00001000_0101 0000_0---
整数値０ｘ00000A0B • 数値をやり取りする際の容量軽減 – 小さい数値のやり取りが多い場合有効データの表現 0A 0B 00 00 0000_0000 0000_0000 0000_1010 0000_1011 0000_00000100_00001100_0010 0000_00001000_0101 この２Byteは送らなくても良くなる
パケット構造 • RPCを実現する為に必要になる通信内容 – プロトコルバージョン番号 • エンコード、デコード形式 – 制御用カウンタ • 何回目の通信なのか？ – どの関数を呼ぶ？ • 関数番号（ID） – 関数に合わせた引数 • 関数毎に引数の数、型、長さが変わる – １手続きを実行するのに必要なデータ総容量 • 正しく受信するために必要
圧縮有圧縮無パケット構造 Version （１Byte） PacketNumber （４Byte） PayloadSize （４Byte） Compress （１Byte） Size （４Byte） CompressData （Size） MessageID （４Byte） Parameters Compress （１Byte） MessageID （４Byte） Parameters Payload （PayloadSize）
レイヤー構造による処理 • 送信 / 受信で処理する順にレイヤを構築 Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信
レイヤー構造による処理 • 各レイヤーで行う処理必要に応じて圧縮メッセージデータをバイナリストリーム化ネットワークに流す形式に変換送信受信ネットワークから流れてきたデータの変換必要に応じて伸長バイナリストリームのメッセージ化 OS低レベルAPIによる送受信処理
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信 MessageID （４Byte） Parameters
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信 MessageID （４Byte） Parameters Compress （１Byte）
データの流れ Version （１Byte） PacketNumber （４Byte） PayloadSize （４Byte） MessageID （４Byte） Parameters Compress （１Byte） Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信 Version （１Byte） PacketNumber （４Byte） PayloadSize （４Byte） MessageID （４Byte） Parameters Compress （１Byte）
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信 Version （１Byte） PacketNumber （４Byte） PayloadSize （４Byte） MessageID （４Byte） Parameters Compress （１Byte）
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信 MessageID （４Byte） Parameters Compress （１Byte）
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信 MessageID （４Byte） Parameters
データの流れ Compressor データの圧縮 SplitToContract メッセージ一つを処理 Packetize 送受信ヘッダー処理送信受信関数呼び出し MessageID （４Byte） Parameters
実装における問題点 • 通信内容を一つ追加する都度、追加・修正しないといけないコード量が多い – 送信関数 – 受信関数 – 受信関数の呼び分け部分（Dispatcher) • これを簡易化する為に IDL（Interface Definition Language）を用意する
IDL • IDL（Interface Definition Language） – 通信に載るメッセージ（RPC）の内容定義を抽象化した物 – マルチプラットフォーム向けに変数定義（型）も抽象化する • この定義を元に、最低限必要になるコードを自動生成する仕組み • 定義ファイルとコードジェネレータ
IDL • 送信側 – 受信側が識別可能な一意なメッセージID – メッセージ毎のパラメータ格納 • 受信側 – どのメッセージを受信したのか？（適切な手続きの呼び出し） – メッセージ毎のパラメータ展開 • 受信後の処理はアプリケーションレベルの実装
IDL サーバ用受信クライアント用送信メッセージ定義 --------------------- WANTED string Occupation --------------------- Generator
IDL メッセージ定義 --------------------- WANTED string Occupation --------------------- C++ C C++ C サーバ用受信クライアント用送信 Generator
メッセージ定義 --------------------- WANTED string Occupation --------------------- Generator IDL C++ C C++ void send_WANTED(std::string Occupation); C void send_WANTED(char* Occupation); サーバ用受信 void WANTED(char* Occupation); クライアント用送信 void recv_WANTED(std::string Occupation);
IDL • ゲーム内の操作は、こんな感じでメッセージ化されています。（MMOの場合） MessageID Message 概要パラメータ１ CHAT_SEND チャットに発言 Msg：発言内容２ CHAR_MOVE 移動 X：X座標 Y：Y座標３ CHAT_SHOW 誰かがチャットした Who：誰が？ Msg：何て言った？４ ATTACK キャラクターが攻撃 Target；誰に攻撃する？ How：どうやって攻撃する？
IDL • 実際の例 <?xml version=“1.0” encoding=“utf-8” standalone=“yes” ?> <contract name=“GameMessage”> <party primary=“Client” secondary=“Server” /> <call name=“CHAT_SEND”> <parameter name=“Msg” type=“String” /> </call> <typedefine name=“id” type=“int” /> <receive name=“CHAT_SHOW”> <parameter name=“Who” type=“id” /> <parameter name=“Msg” type=“String” /> </receive> </contract>
<?xml version=“1.0” encoding=“utf-8” standalone=“yes” ?> <contract name=“GameMessage”> <party primary=“Client” secondary=“Server” /> <call name=“CHAT_SEND”> <parameter name=“Msg” type=“String” /> </call> <typedefine name=“id” type=“int” /> <receive name=“CHAT_SHOW”> <parameter name=“Who” type=“id” /> <parameter name=“Msg” type=“String” /> </receive> </contract> IDL • 実際の例このメッセージ群（通信定義）の名前
<?xml version=“1.0” encoding=“utf-8” standalone=“yes” ?> <contract name=“GameMessage”> <party primary=“Client” secondary=“Server” /> <call name=“CHAT_SEND”> <parameter name=“Msg” type=“String” /> </call> <typedefine name=“id” type=“int” /> <receive name=“CHAT_SHOW”> <parameter name=“Who” type=“id” /> <parameter name=“Msg” type=“String” /> </receive> </contract> IDL • 実際の例以下に記すメッセージ定義の方向指定、このファイルの場合 “Client to Server” このメッセージ群（通信定義）の名前
<?xml version=“1.0” encoding=“utf-8” standalone=“yes” ?> <contract name=“GameMessage”> <party primary=“Client” secondary=“Server” /> <call name=“CHAT_SEND”> <parameter name=“Msg” type=“String” /> </call> <typedefine name=“id” type=“int” /> <receive name=“CHAT_SHOW”> <parameter name=“Who” type=“id” /> <parameter name=“Msg” type=“String” /> </receive> </contract> IDL • 実際の例以下に記すメッセージ定義の方向指定、このファイルの場合 “Client to Server” このメッセージ群（通信定義）の名前 call なので Client -> Server Server -> Client
• クライアント typedef id int; class GameMessageReceiver { public: void dispatch(network_data& data) { function_number = data.pop<int>(); switch (function_number) { case 789012: id Who = data.pop<id>(); std::string Msg = data.pop<std::string>(); CHAT_SHOW(Who, Msg); break; } } virtual void CHAT_SHOW(id Who, std::string Msg) = 0; }; IDL class GameMessageSender { public: void CHAT_SEND(std::string Msg) { push_args<int>(123456); // function number push_args<std::string>(Msg); } };
• サーバー <Client_RPC.h> typedef id int; class GameMessageReceiver { public: void dispatch(network_data& data) { function_number = data.pop<int>(); switch (function_number) { case 123456: std::string Msg = data.pop<std::string>(); CHAT_SEND(Msg); } } virtual void CHAT_SEND(std::string Msg) = 0; }; IDL class GameMessageSender { public: void CHAT_SHOW(id Who, std::string Msg) { push_args<int>(789012); // function number push_args<id>(Who); push_args<std::string>(Msg); } };
IDL GameMessageSender::CHAT_SEND(“募集中”);
IDL GameMessageReceiver::CHAT_SEND(std::string) { GameMessageSender::CHAT_SHOW(user_id, string); }
IDL GameMessageReceiver::CHAT_SHOW(id Who, std::string) { std::string name = get_charname(Who); Display(“%s %s”, name, string); } エンジニア募集中エンジニア募集中
まとめ • 通信方式（TCP/UDP/常時/非常時） • 通信内容（メッセージ/キーフレーム） • 通信ライブラリ – RPC • データの表現方法（バイトオーダー） • メッセージの表現（パケット構造） • メッセージを処理するレイヤー構造 – IDL • IDLの例
御清聴ありがとうございました
質疑応答

Check these out next

Imprementation of realtime_networkgame

Recommended

More Related Content

Slideshows for you(20)

Viewers also liked(11)

Similar to Imprementation of realtime_networkgame(20)

Recently uploaded(20)

Imprementation of realtime_networkgame