2sアブリケーソョンレイリー
ムビューも作ることができる。考えてみればゲームロジックは、プレイヤーどうしが近くにいるのか、何マイルも開れているのかは気にしない。したかって、このリモートビューはゲーム状態とイベントを収集し、できるだけ小さいパイトに圧縮し、TCPやUDPを介して遠層ブレイヤーに送ることができる。遠層ブレイヤーから受け取ったゲームコマンドは当然、検証フィルタに通さなければならない。ついでにいえば、遠隔プレイヤーや油痛ゲームロジックは過信してはならない。つ注意したいのは、異なるビューを持ったプレイヤーには有利な点もあれば不利な点もあるということだ。例えば、16:9の画面でブレイする人は画面全体を見ることができるが、4:3の両面でブレイする人の場合、画像が少し切れる。これを1歩進めて考えれば、ビューの定義が確えばそのビューを使っている人が非常に有利になるが、まったく有利にならない場合もあるということになる。ビューの定義については、それが画面サイズのような明確なものに関係するものであれ、ューがゲームロジックから受け取るイベントの型に関係するものであれ、十分な注意が必要だ。このアーキテクチャが優れていることはおわかりいただけただろう。正直にいえば、このアーキテクチャのコーディングは簡単ではない。特に初めはかなり骨が折れるだろう。もっと簡単な方法が見つかれば、ゲームロジックとピューが完全に分離したこのイベント黒動型アーキテクチャは使いたくないと思うかもしれない。簡単な方法を使いたい気持ちはわかるが、そこはグッと我慢してほしい。少し時間をおけば、簡単だが柔軟性のないアーキテクチャに戻ろうとはきっと思わなくなるはずだから。2.3
アプリケーションレイヤー
アブリケーションレイヤーはさらに、デバイスを扱う領城、OSを扱う領域、ゲームの時間を扱う肌域に分けられる(図2.2)
ゲームアブリケーションレイヤー
デバイス
入力
05
ゲームのライフタイム
RA
DLL
RAM
時間
イプラ：
e
0771ケケーショ
ソレイヤーの由月
2.3.1入力の読み取り
ゲーム用の入力装置にはさまざまな種類のものがある。キーポード、マウスイスティック、ダンスパッド、ハンドル、そして私のお気に入りのギターなどだ。こうした装置の読
ームハッ