プロジェクト演習Ⅳ・Ⅵ インタラクティブゲーム制作 第4回 マルチスレッドとネットワーク
今日の内容 マルチスレッド – ローディングの進捗表示とか – 処理高速化も見込めます ネットワーク通信 – 必然的にマルチスレッドを扱います
マルチスレッドとは 1つのプログラムの中で複数の関数が 同時に(並列して)動かせる技術のこと – 今まで皆さんが書いていたプログラムは 「実行している箇所」は1カ所だけだった シングルスレッド マルチスレッドの導入により、メイン ループを回しつつ、他のスレッドで重い 処理をさせることができるようになる
メリット・デメリット 重い処理をメイン ループから外して処 理の高速化、効率化 が見込める – バックグラウンド読み 込み、ローディングの 進捗表示、ネットワー ク処理、BGMのスト リーミング再生など夢 は広がるばかり データのアクセスに 制約が付く バグった時の対応難 度が跳ね上がる 苦労して別スレッド にしてもその割には リターンが少ない、 あるいは悪化するこ ともある
今回のサンプルは(も) Windows限定コード boostというライブラリを使うと、 機種依存せずにスレッド処理が可能 ただし、ライブラリのサイズが膨大かつ、 コンパイル速度が低下するなどの影響も boostはおすすめしたいのですが、 今回は学習の利便性をとって Windowsネイティブの実装にしました
使い方 Javaライクにしてあります – 基底クラスを継承してMyThreadクラスを 作る – Main()をオーバーライドして、別スレッドで 行う処理を実装する – MyThreadオブジェクトを作り、 Start()をコール Main()を直接コールしてはだめ – 止める時はEnd()をコール
別スレッドで操作している データの参照 必ず受け渡し用のメンバ関数を作る そのメンバ関数内でLock()～Unlock()を 忘れずにコールする – Lock()して – 返値用の変数にデータをコピーしたりして – Unlock()する これを怠ると、データの読み書きが かちあってSUGOIことになる
ネットワーク処理を扱う 開発環境 XNA – 何か規約とかが面倒らしい DirectPlay – 滅びる定めのフレームワーク boost::asio – 機種非依存で、将来はC++標準になるかも – でもboostなので… winsock – Windowsネイティブ実装 – でもAPI構成はUNIXの系譜を受け継いでいて そこそこきれい(他機種への移植も容易)
ネットワークには マルチスレッドが必須 通信待ち状態で処理が止まる メインループに組み込もうもんなら ゲームになりようがない サーバー – 接続してくるクライアントごとにスレッドを 立てる クライアント – サーバーとの接続用に1本立てる
今回のサンプル POEを開発した時のテストプロジェクト – コマンドバッファによるアクションゲームに 対応した設計例となっている – 60FPSのアクションゲームに対応できるので だいたいのゲームに応用できるはず
考え方 クライアント： – サーバーにキー入力情報を送る サーバー： – 各クライアントからと、自分自身のキー入力情報を集め、 あるフレームにおける全プレイヤーのキー入力状態の セットを作る – サーバー上で1セットの状態に基づいてゲーム状態を再現 しつつ、各クライアントに1セット分のデータを送る クライアント： – 受け取った1セット分のデータを数フレーム分プール (コマンドバッファリング)しておく – ある程度貯まったら1フレームずつ取り出して状態再現を 行う
特徴 来たデータを片っ端から再現してしまう と、通信遅延が起きた時のガタ付きがひ どくなる – 5フレーム程度ため込んでおくことで、 多少の通信速度のムラは吸収できる – あまりためすぎると、操作に対する反応の 遅延が大きくなってストレスがたまる
コマンドの送り方 固定長のテキストでキーワードを送る その後でキーワードに即したデータ送信 キー操作以外にもチャットメッセージを 送ったりもできる コマンドだけだと何かのタイミングで 取りこぼしがあると致命傷なので、 一定のタイミングで現在の状態そのもの を送信