【SMFL非公式和訳】チュートリアル: ベーシックゲームデザイン

この記事は僕がSFMLを学習する為に
Tutorial: Basic Game Design
Tutorial: Basic Game Design · SFML/SFML Wiki · GitHub

を無断で和訳したものです。訳者がSMFL、英語どちらも学習中の為意訳・誤訳ご了承のほど。

 自明のとおり、君には新しいゲームのアイデアがあり、それを実際に生み出したいと思っている。しかし、どこから手をつけたら良いかわからない。

 このチュートリアルでは君のゲームのアイデアをベーシックゲームデザインを通して生み出すことを手助けするために書かれている。もしこのチュートリアルを読んでいる間に大きな間違いを発見したり、役に立ちそうにないと感じたら、君はこのチュートリアルにまったく沿う必要はない。このチュートリアルは数年に渡る私の個人的な趣味として開発したやっつけゲームの経験とコードレビュー、それからネットで見つけたチュートリアルをベースに書かれている。もしあなたがゲーム会社に勤めるプロのゲーム開発者なら是非みんなにあなたの見識を共有してほしい。

 それはともかく、早速ゲームのアイデアから議論していくことにしよう。

Game Idea(ゲームのアイデア)

 まだ未熟な若者だった頃、私は友人や家族、それから学校の先生と、私の最新のゲームアイデアを議論することに夢中だった。もし君があの頃の私と同じなら、君にはまだまだ深化の余地がある。私はゲーム制作のことを熟慮する(年を取るとも言う)に従って、ゲームアイデアというのは、ゲーム制作において全体の1%(か君のアイデアが最高に良くても10%)程度だという事がわかってきた。残りの99%はアイデアを理論化したり実装したりする部分だ。だからベーシックゲームエンジンチュートリアルの制作(とGQEプロジェクト)を、みなさんと、それから私のゲームを形にするために取り組んだわけだ。

 それにくわえ、素晴らしいゲームアイデアというものは、シンプルなコンセプトや理論に基いていることも学んだ。初期のFPS(ファースト・パーソン・シューティング)作品でいえば、その基本コンセプトは「迷路」だ。プレイヤーは先の分からない道をゴールに到達するまで進んでいく。次の面も(さらに多くの敵や人を殺しながら)ゴールを探して道を進む。

 次第にFPSは進化し、中でもマルチプレイヤー型FPSは洗練されオープンな環境になった。

 というわけで、ゲームデザイナーであるあなたの目標は、あなたの能力で実際に制作可能なゲームのアイデアを探すことだ。もし実現するのに複雑すぎるアイデアを選んでしまったら、私の過去の経験と同じく、まずゲームを完成させることができないだろう。

 しかし、絶望する前に伝えておこう。君が実現できる素晴らしいゲームというものは世の中に山ほどある。

 では、それらのゲームの検討を、まずはゲームのジャンルから議論していこう。

Game Genre (ゲームのジャンル)

 人間というものは、カテゴライズしたがるものだ。ゲームデザイナーとて例外ではない。この十数年、ゲーム制作会社は、各ゲームカテゴリになんだか格好良く聞こえる名前を付けて、「ゲームジャンル」リストを生み出してきた。

 最近私は、そういったゲームジャンルリストを使って、自分のゲームアイデアたちを他のゲームとの「違い」や「類似点」やらで分類して、さらに同じゲームジャンルのゲームと私のアイデアも比較して、制作に値するオリジナリティや面白さを兼ね備えた良いアイデアか検討した。結果、とても多くのライバル「アプリ」が見つかった。「似たような」ゲームが存在しない新しいゲームのアイデアを生み出すのは年々難しくなっている。だから、君はそのゲームのアイデアを形にする前に充分に調査し、煮詰める必要がある。

 ゲームアイデアをより深化させるために、ゲームデザインに関するドキュメントを作成することを私はおすすめしたい。ドキュメントがあれば、ゲーム制作にあたって君とその仲間のガイドとなる。さらにこのドキュメントは、アイデアをより深化させ、ゲームのメカニズム実装方法を手早く導き出す手助けにもなる。君が真剣にゲーム開発に取り組んでいるなら、ゲーム制作を始める前にドキュメント制作にも真剣に取り組み、時間を割く必要がある。一般的なゲーム会社ではどんなゲームのアイデアでもデザイナーから、お楽しみ(代償とも言う)の前に、この手のドキュメントを最低限要求する。

 ゲームデザインに関するドキュメントが一旦完成したら、次はゲームのプロトタイプを制作する。ゲーム開発のプロトタイプフェーズにおいては、最小限の核やゲームデザイン上のメカニズムを搭載したものを制作する。ゲームデザインプロトタイプの最初のステップは、ゲームエンジンスタイルの選択だ。

Game Engine Style (ゲームエンジンスタイル)

 いくつものゲームを制作するに従って、それらがいかに似たような実装になるか君は気づくだろう。例えゲームジャンルが異なった場合でも、多くの部分は同じゲームエンジンスタイルで作成することが出来る。たとえば、マルバツゲーム(三目並べ)とアステロイドゲーム(ピンポンゲーム)は同じゲームエンジンで作成できる。たとえアステロイドゲームがアクションゲームに分類され、マルバツゲームが(たぶん)パズルゲームに分類されるとしても。

 上記から言える事として、君はゲームデザイナーとして、ゲームエンジンスタイルの違いを理解し、ゲームデザインを実装するにあたって、これらが君にどんな機能を提供するか理解することだ。

 私の数年のゲームプログラミング経験と文書で得た知識による、ゲームエンジンスタイルの違いを以下のリストで表した。

 私はこれらの経験と、得られた知識に本当に感謝している。だからこのページへの追記や、君のちょっとした思いつきをここに追加することをためらわないで欲しい。

 それぞれのゲームエンジンスタイルはそれぞれ異なる層の複雑性に関わっており、それは君がゲームデザインと目論見をどのようにまとめるのが賢明か、どのゲームエンジンが君のゲームデザインに良くフィットするかに関わってくる。2Dゲームに3Dゲーム用のエンジンスタイルを使おうとすると、大変な目に遭う。もしそれが出来たとしても、不必要で複雑なものを山程用意してやらなければならない。

 それぞれのエンジンの実装スタイルについて、以下のリストにもとづき比較できるように心がけた。

  • オブジェクトマネージメント -- ゲーム内の各要素のマネージメント(管理)
  • コンテンツマネージメント -- 画像や音、音楽などのゲーム内資源のマネージメント
  • ゲームロジック -- ゲームメカニズムやルールの処理
  • ゲームレンダリング -- ゲーム内要素の画像や音の出力処理

Sprite Engine(スプライト エンジン)

 君がゲームデザインとプログラミングのビギナーなら、ここから始めるべきかもしれない。スプライトエンジンを使った最も基本的なコンピューターゲームといえば、ポン(Pong)だ。(※ピンポンゲームの事)

 ポンは偉大な初心者向けゲームだ。しかし私はマルバツゲームを最初のゲーム開発におすすめしたい。マルバツゲームは簡単な入力処理とゲーム状態ロジックのみで制作できる。一方ポンは、それらに加えて動くグラフィックが必要になる。

 スプライトエンジンを使ったプロ開発のゲームは多数存在する。モータルコンバット、スペースインベーダー、Scorched Earthなど(※昔あった砲撃ゲーム) 。さて、スプライトエンジンの実装を定義していこう。

オブジェクトマネージメント

 スプライトエンジンにとってオブジェクト群は、シンプルな配列で一般的に全て表せれる。もしくは全てを個別の変数に格納する。

 一般的に変数はゲームオブジェクトを表す事ができるシンプルな仕組みだ。前述のマルバツゲームの場合、10オブジェクトで表現できる。×が5つ、○が4つ。それからゲーム盤が1つ。ぽんであれば3〜4のオブジェクトになる。棒が2つとボールが1つ。それから仕切りが必要な場合もある。

コンテンツマネージメント

 スプライトエンジンの場合、コンテンツもオブジェクトと同じくシンプルだ。プログラマーはゲームオブジェクトを表示させる際、そのコードのすぐ側でオブジェクトの画像ファイル1つずつを毎度直接コードで指定する。プログラマーがホントに頭が良かったらそれらは上手く結び付けられ、必要なものが必要なだけ画面に出力される。

 そういったわけで、一般的にこのゲームエンジンスタイルでは、ゲームコンテンツの管理が出来るだけ少なくなるよう考慮される。

ゲームロジック

 スプライトエンジンの場合、ゲームロジックは一般的にIF/SWITCHなどの条件分岐文をハードコーディング(直書き)をすることによって構成される。これらの条件分岐は、動くゲームオブジェクトに対する衝突判定や画面の境界線を判断するためのものにすぎない。ポンの場合、いくつかのシンプルなロジックで動くボールを壁や棒で跳ね返せる。マルバツゲームの場合、そのマスがすでに取られているか、3マス並んでいるかを監視するのに用いられる。

ゲームレンダリング

 スプライトエンジンの場合、グラフィックの表示は、ゲームエンジンを通してループ(繰り返し)毎に、ゲームオブジェクトを画面に描画することで構成されている。多くの場合、スプライトエンジンはゲームオブジェクトの複雑な動きを許容しないので、画面外のオブジェクトに何が起っているかなど面倒な事を考えなくてよい。しかし、あなたがそんな動きを許した場合、ゲームエンジンをループするたびに全てのオブジェクトがそのループを通ることになるので、それなりの負荷が発生することになる。

Tile Engine (タイルエンジン)

 スプライトエンジンゲームを作れる程度に技能が上達したら、タイルエンジンの開発を次に検討すべきだ。

 タイルエンジンの流通レベルのゲームはたくさんある。素晴らしい例で言えば、チェッカー、チェス、マリオブラザーズ、ゼルダの伝説、ウルティマ1-4などなど。

 ではタイルエンジンとは何かを定義していこう。

オブジェクトマネージメント

 タイルエンジンではゲームオブジェクトを、背景(バックグラウンド)、前景(フォアグラウンド)と2つに分類して取り扱う。前景は一般的にシンプルな配列でゲームオブジェクトや値を管理する。背景用のゲームオブジェクトは、ゲーム世界をタイル状に分割し、マップと呼ばれる方法や多次元配列で管理する。このような複雑なデータは充分上手く管理する必要があるが、他のゲームエンジンスタイルのそれと比べれば理解も実装も用意だろう。

コンテンツマネージメント

 コンテンツマネージメントも、タイルエンジンにおいてはやや複雑となる。一般的に、背景タイルなどの画像データを1枚の巨大な画像ファイルに全て格納し、グラフィックカードでその画像ファイルをロードする。その後ゲームエンジンのループ内で適宜画像を切り出し、背景を描写する。

 さらに、背景ファイルに余裕がなく、グラフィックカードが可能であれば、2枚目の巨大な画像ファイルを前景のために用意し、全ての前景画像データを格納する。

 このように巨大な画像ファイルの取り扱いさえ上手く行けば、スプライトエンジンと比較してもさほど複雑にはならないだろう。

ゲームロジック

 ゲームロジックの処理もタイルエンジンにとっては複雑さを増す要素の1つだ、なぜなら、タイルエンジンのゲーム世界は大きくなり、ゲームロジックはゲームエンジンループ内で時間をさらに要求する。これはタイルエンジンスタイルのゲームではより多くのゲームオブジェクトがゲーム内で飛び回るからだ。これはあなたのゲームデザイン実装をより困難にする。

 そのため、ゲーム開発者たちは、スクリプトエンジンを実装することでゲームメカニズム実装をより簡単にしようとする事が少なくない。ただ、君がいくつかの簡単なタイルエンジンスタイルのゲームを完成させるまでは、私はスクリプトエンジンの組み込みをおすすめしない。スクリプトエンジンによって得られるメリットと、スクリプトエンジン自体の実装の負担を天秤にかけれるようになってから、初めて検討すべきだろう。

ゲームレンダリング

 もし上手く実装できなければ、ゲームレンダリングは、タイルエンジンにとって大きなボトルネック(負荷)に成りうる。SFMLフォーラムで、これを上手く実装するための手助けとなるスレッドをいくつか見つけられるだろう。

 ストレートなやり方としては、マップ情報を元に全ての背景タイルを個別のスプライトでゲームループ毎に描き出すことだ。このやり方だと768のスプライト(1024x768ピクセルの画面を32x32ピクセルで埋める)を毎ループ描き出す事になる。しかもまだ前景は含まれていない。もしあなたの背景がアニメーションしているなら、どうしてもこの高コストな方法は避けられない。

 他の手段としては、まず全ての背景タイルを1枚の画像にまとめてから、それを一度に描画し、その後前衛を描画する。この方法であれば、ただ巨大な画像で描かれたゲーム世界の前衛を、ゲームオブジェクトか動きまわるだけだ。こうすれば、背景の再描画は768のスプライトから、前衛のゲームオブジェクトが移動した部分、1移動につき2タイル分のスプライトで済む。さらに画面移動分の描画についても、元の背景画像データをコピーして利用できる。

 ただ、どちらにせよスプライトエンジンよりは複雑さを増すだろう。

Storybook Engine (ストーリーブックエンジン)

(※アドベンチャーゲーム用エンジン)

 ストーリーブックエンジンと聞いて君は明確にイメージできないかもしれない。ストーリーブックエンジンを使った商業ゲームはいくつもあります、Kings Questシリーズ, Police Questシリーズ, Space Questシリーズ, Mystシリーズなど。これらの名称を聞いて「ああ、ああいうのね」とピンときたかもしれない。私はこのタイプのゲームの熱狂的なファンだと白状しよう。ただ、私自身がこの手のゲーム開発について熟知しているというわけではない。

オブジェクトマネージメント

 ストーリーブックでもオブジェクトは2種類として取り扱う。前景(フォアグラウンド)と背景(バックグラウンド)。 

 前景は一般的に、プレイヤーの操作に基いて反応するオジェクトたちをシンプルな配列に格納して取り扱う。それ以外のプレイヤーが注意するに値しないオブジェクトたちを背景として取り扱う。一般的にストーリーブックエンジンのオブジェクトマネージメントは、タイルエンジンのそれほどは複雑にはならないだろう。

コンテンツマネージメント

 一方コンテンツマネージメントは、タイルエンジンのそれより多くの課題をはらんでいる。一般的にストーリーエンジンゲームでは大きな画像群を表示する必要がある。タイルエンジンであれば、小さな画像をまとめあげて、繰り返し表示するだけだが、ストーリーエンジンの場合、全画面に背景を表示し、さらに前衛に別の大きな画像を表示する必要がある。ただ、それらは多くの場合静的で、プレイヤーが何か操作するまで停止している、もしくはアニメーションを繰り返している。

 こういった環境は、しばしばゲームが動作するプラットフォームや、ユーザーのゲーム環境に大きく制限を加える事になる。しかしやりようが無いわけではない。

ゲームロジック

 ストーリーブックエンジンの場合、ゲームロジックの処理はかなり複雑にも、とてもシンプルにも成りうる。多くのストーリーブックエンジンはスクリプト言語エンジンを実装している。それはスクリプトとコンテンツの書き換えだけでゲームに変更を加える事を可能にする。最近のストーリーブックエンジンゲームは、カーソル選択と決定程度の入力しか必要としない事が理由だ。例えば、カーソル移動を追跡してどのオブジェクトをプレイヤーが掴んでいて、それが正解どうか、といった事を処理しない。また、改変、続編の制作も容易となる。これは、手間を考えてもスクリプトエンジンをゲームロジックに組み込む背景となる。

ゲームレンダリング

 もし上手く実装できなければ、ゲームレンダリングは、ストーリーブックエンジンにとって大きなボトルネックに成りうる。しかし、ゲームロジックはとても簡単。それほどゲームレンダリングを調整する必要はないだろう。多少スプライトエンジンのそれより複雑なくらいで、タイルエンジンほど複雑にはならないだろう。

ファーストパーソンシューターエンジン(FPSエンジン)

 今ゲーム制作をする人の多くが、FPSゲームエンジンを使いこなそうと努力している。今日のゲーム業界でFPSゲームが益々勢力を拡大しているのが理由だ。ただ、複雑さの観点で言えば、FPSエンジンはとても複雑だ。マルチプレイヤー対応の場合は輪をかけて難しくなる。あなたが真剣にFPSゲームを制作しようと考えているなら、ネットで探せるオープンソースのFPSエンジンを採用してゲーム制作をする事を真剣におすすめする。この業界では、IDソフトウェアがFPSエンジンのソースコード提供に積極的だ。

オブジェクトマネージメント

 FPSにとってオブジェクトマネージメントは大きな仕事だ。今まで紹介してきたゲームエンジンよりもさらに多くのゲームオブジェクト管理が必要となる。そのほとんどはゲームループで画面を出力するための画像出力命令として管理されている。FPSゲーム制作は10-15年前の黎明期よりかなり複雑になっている。

コンテンツマネージメント

 FPSエンジンのコンテンツは多分、タイルエンジンやストーリーブックエンジンのそれより多少複雑な程度だろう。FPSエンジンのコンテンツは複雑にもシンプルにもすることが出来る。多くの人が考えるように素晴らしいゲームはコンテンツのリッチさよりプレイそのものやレベルデザインにある。ただ、そのどちらも実現できればより多くのファンを獲得できるだろう。

ゲームロジック

 ゲームロジックは今まで紹介してきたどんなゲームエンジンと比較しても複雑だ。その理由は二次元ではなく三次元の世界を取り扱わなければならないからだ。

 いくつかの初期FPSエンジンは二次元を取り扱うため専用にデザインされた。まだその頃のハードウェアは三次元の複雑な問題を解決できるようになっていなかったからだ。今のFPSエンジンでこれは一般的な問題では無くなった。このゲームエンジンスタイルで最も複雑な側面は、弾丸やらロケットとオブジェクトの衝突判定を常に行わなければならい点だ。それ以外にもオブジェクトが三次元の正しい場所に正しく描画させるためにも多大な労力が必要となる。

ゲームレンダリング

 FPSゲームエンジンにおいてレンダリングは他のゲームエンジンと比較してもっとも複雑になる。毎フレームの描画負荷を低減するために、どのオブジェクトを描画するか、スキップするかなどの取り組みに多大な労力が必要となる。

 こういったオブジェクトの整理はゲームが始まる前(背景や壁などの、弾丸自体、階段などの静止オブジェクト)に完了するか、ゲーム動作中(血しぶき、体の一部、窓など前景オブジェクト)に行わる。マルチプレイヤー対応を行えばさらに複雑となる。

シミュレーションエンジン

 シミュレーションエンジンとFPSエンジンの違いはそれほど大きくないだろう。ただ、シミュレーションエンジンは、FPSエンジンと比較しても厳密な物理処理を要求する事がある。シミュレーションエンジンが多分組み込まれている例でいえば、タイガー・ウッズゴルフ、フライトシミュレーター、フットボールシミュレーターなどが挙げられる。

オブジェクトマネージメント

 シミュレーションエンジンの場合、ゲームオブジェクトマネージメントはとても大きな仕事となる。これほど多くのオブジェクトを扱うゲームエンジンスタイルは他にはない。それらのオブジェクトは物理的な状態を情報として伴っている。ゲームオブジェクトの正確なモデリングナシでは、現実世界の物理現象を表現することはできない。というわけで、最近のFPSゲームエンジンがシミュレーションエンジンと似通ってくるのは驚くに値しない。ただ、ゲームを面白くするために物理現象をゲームらしく再現したほうが良い場合もある。

コンテンツマネージメント

 シミュレーションエンジンにとって、コンテンツはFPSエンジンと同じように扱われるだろう。唯一の大きな違いとしては、シミュレーションエンジンのほうがより厳密に光源を管理している点だ。

ゲームロジック

 シミュレーションエンジンにとってゲームロジックの処理はFPSにくらべてより厳密に取り扱わなければならない。それはリアルな世界の計算を実数を使って処理をするためだ。これにより、コンパイルエラーを始めとした様々な問題が簡単に発生するようになる。

 FPSエンジンでは2つの自由度しか移動が許可されていないが、シミュレーターエンジンではしばしば6自由度の移動が許可される。これは衝突判定やその他の事柄から発生する処理パフォーマンスに大きく関連してくる。さらにいえば、これらが思惑通りに配置され正しく表示されるかに多大な注意を払わなければならない。

ゲームレンダリング

 ゲームレンダリングはシミュレーションエンジンにとっておそらくFPSエンジンよりさらに複雑になる。毎フレームの描画負荷を低減するために、どのオブジェクトを描画するか、スキップするかなどの取り組みに多大な労力が必要となる。

 こういったオブジェクトの整理はゲームが始まる前(背景オブジェクト)に完了するか、ゲーム動作中(前景オブジェクト)に行わる。マルチプレイヤー対応を行えばさらに複雑となる。

マルチユーザーダンジョンエンジン(MUDエンジン)

 マルチユーザーダンジョンエンジン、またはMUDエンジンは、マッシブ(大規模)マルチプレイヤーロールプレイングゲームエンジンの前身とみなされる事がしばしばある。これは、多くのMUDゲームエンジンが、前インターネット時代のテキストエンジンゲームから進化してきたためだ。このゲームエンジンスタイルは、グラフィックやその他の要素より、実際のプレイヤーのゲーム経験が反映され、練磨されてきた部分が大きい。

オブジェクトマネージメント

 MUDエンジンにとってゲームオブジェクトマネジメントは、他に紹介してきたどんなゲームエンジンより複雑になりうる。それは、このエンジンが本質的に多数のプレイヤーが一度にゲームに参加することに対応しているためだ。これによりオブジェクトマネージメントがとても重要なものとなる。君もこの手のゲームをプレイしている時に、ほぼ同じタイミングで他プレイヤーと同じタイミングでアイテムを拾おうとしたことがあると思う。これを疎かにすると参加プレイヤーが1つのアイテムから人数分のアイテムを複製できる事になる。

コンテンツマネージメント

 MUDエンジンにとってコンテンツマネージメントは、他に紹介してきたどんなゲームエンジンよりも複雑になりうる。なぜならプレイヤー達は探険、経験、拾得などゲームの内容を1人でプレイする1時間よりさらに早く消費する事が可能だからだ。

 自分のゲームをホットな状態に維持するために新しいコンテンツを追加して行くことは、コンテンツマネージメントにより複雑性をもたらすだろう。

ゲームロジック

 MUDエンジンにとってゲームロジックの処理は、マルチプレイヤーのアカウントを管理し、だれが同時にシステムにアクセスしているのかを管理するのが大変なだけである。一般的にゲームメカニズムやルールはそれほど複雑にはならないだろう。しかしながらプレイヤーイベントやゲームの状態を永続的に管理する必要があり、これはかなり難しい。これを解決するために多くのMUDエンジンでは、データベースを使ってゲームオブジェクトとユーザーデータを管理する事を試みている。これが単に1つのコンピューター上で、1人のプレイヤー情報を管理する場合よりゲーム開発の難易度をあげることになる。このゲームシステムの管理がゲーム会社に大きな負担を強いらせているのだ。

ゲームレンダリング

 MUDエンジンにとってグラフィックスレンダリングとはタイルエンジンと同じかもしれない。これはMUDエンジンの肝がゲームロジックとゲームオブジェクトにあり、ゲームの描画部分は大した売りでは無いからだ。多くのゲームプレイヤーは、探険中に何がどう見えるのかではなく、新たな体験、探険自体を欲しているのである。しかしながら最近のMMORPGゲームはいくぶん考え方を変えつつあるようだ。

マッシブ(大規模)マルチプレイヤーオンラインロールプレイングゲーム (MMORPG) エンジン

 前述のとおり、多くのMMORPGエンジンは古きMUDエンジンが原点となっている。それらの最も大きな違いは、同時に多くのプレイヤーがゲームに参加する点だ。例を挙げると、Everquest、World of Warcraft、Star Wars Online、Ultima Onlineなどが挙げられる。

オブジェクトマネージメント

 MMORPGエンジンにとってオブジェクトマネージメントはMUDエンジンより複雑で、さらに言えば今までに紹介してきたエンジンスタイルのどれよりも複雑だ。これは接続した複数のプレイヤーを同じ場所にいる状態を管理する必要があるからだ。

 そのため、ゲームエンジンをできるだけシンプルに留めるためにプレイヤーは仮想的な複数の世界に分割される。別の言い方をすると、複数の仮想ワールドXYZがありつつ、それぞれのプレイヤーがお互いを視認できるよう1つのワールドXYZに配置される。プレイヤーがワールドXYZ Aに割り当てられ、もう一方のプレイヤーがワールドXYZ Bに配置されるとする。そうすれば2人は同じワールドに存在しているように見える。ただしプレイ中はお互いを視認できない。(もしこの認識が間違っていたら是非誤りを指摘してほしい)

コンテンツマネージメント

 MMORPGエンジンにとってコンテンツマネージメントはMUDエンジンのそれよりさらに複雑になる。半年から2年かけて開発したような新しいコンテンツをプレイヤーはほんの1日で消費してしまう。全コンテンツの生産管理と新しいコンテンツの同時リリースは大変なチャレンジとなる。全プレイヤーを満足させるコンテンツの質・量の投入はかなり難しいため、新しいコンテンツ開発の間、何かべつの方法でユーザーにゲーム参加の目的を用意してやる必要がある。

ゲームロジック

 MMORPGエンジンにとってゲームロジックの処理は、マルチプレイヤーのアカウントを管理し、だれが同時にシステムにアクセスしているのかを管理するのが大変なだけである。一般的にゲームメカニズムやルールはそれほど複雑にはならないだろう。しかしながらプレイヤーイベントやゲームの状態を永続的に管理する必要があり、これはかなり難しい。

 さらにいえば、FPSエンジンのような見た目を表現するためにゲームオブジェクトを処理しなければならない。これはMUDエンジンゲーム以上にゲームロジックを複雑にする。

ゲームレンダリング

 MMORPGエンジンにとってゲームレンダリングはFPSエンジンのそれとおなじになるかもしれない。最近ではMUDエンジンゲームより見た目で勝負する必要があるからだ。特にゲーム内のコンテンツを全て探索しきってしまったプレイヤーに対して、見た目は大事だ。


 結論として、現在いくつかの違ったタイプのゲームエンジンスタイルが世の中で使われている事を伝えたい。大事な事は、君のゲームデザインに適したゲームエンジンスタイルを採用することだ。また、誰も試したことのないような新しいチャレンジに臆する必要が無いこともあわせて伝えたい。君がどのゲームエンジンが自分のプロジェクトに適しているか決めたら、次は君のゲームではゲームオブジェクトをどのように管理すべきかを検討するべきだ。ではそれについて次から議論していこう。

ゲームオブジェクトマネージメント

近日公開...

ゲームコンテンツマネージメント

近日公開...

ゲームの配布

近日公開...

コメント欄

 ベーシックゲームデザインからゲームを生み出す君のやり方を是非気軽に上記トピックに追加してほしい。君はどうやってゲーム完成までのモチベーションを維持しただろうか?

※訳者注 最終更新から1年以上経過しても残りのコンテンツが追加されないため、更新はないと思われます