ゲームアーキテクチャ
ゲームのサブシステムを組み立てる方法は、ゲームプログラマの数と同じくらいある。サブシステムとは何なのか、何をするものなのか、お互いにどのようにやりとりしているのかについて私の考え方を逃べるが、あなたと私のやり方は違うかもしれない。それでもまったくかまわない。私が焼べることはあなたの理解力を高めることが目的であって、必ずしも効率性の話ではないからだ。どういったことでも理解さえすれば、もっと効率的な独自の方法を見いだすことができるが、その仕組みがわからなければより効本的な方法を見つけ出すことは不可能だ。。
器り返すが、私の方法を真似る必要はない。しかし、私自身この方法が一番やりやすいと思っているので、参考程度にでも知っておけば損はないだろう。本章を読むときに注意してもらいたいのは、私がそのシステムでどういった問題を解決しようとしているのかを考え、少なくともサブシステムとそれが何をするものなのかだけはしっかり理解する、ということである。そして私よりもいい方法を思いついたらぜひ連絡してほしい。あなたを雇うから。
それでは、最も重要な顔念から重要度の低い概念へ、という順で話を進めていくことにしよう。ゲームを構成するサブシステムは次の3つの基本的なカテゴリのいずれかに分類できる。3つのカテゴリとは、アプリケーションレイヤー、ゲームロジックレイヤー、ゲームピューレイヤーの3つである(2.1),アブリケーションレイヤーではハードウェアとOSを扱い、ゲームロジックレイヤーではゲームの状態とその経時的変化を管理する。ゲームビューレイヤーは、ゲームの状態をグラフィックスとサウンドで提示する。
アーリイm
ゲームロジック
ームー
021レベルゲームジーキテクチャ
このアーキテクチャ(およびMFCのドキュメント/ピューアーキテクチャ)はよく知っていると思う人がいるかもしれないが、それだけで早まってこの本を燃やしてしまったりしないでほしい。私はMFCを使ってのプログラミングは誰にも負けないくらい嫌いだが、このアーキテクチャにはゲームを3つの独立したシステムに分類するという驚くべき柔軟性がある。もう1つよく使われる設計がターンにモデルビューコントローラがあるが、これはシステムのロジックをインターフェイス(データ変更を提示したり要求したりするのに用いる)から分離するという特徴を持つ。私が提案する