ゲームフィーチャーパターン

ゲームには厳密に決められた形というのは存在しませんが、共通した似たパターンというのは見つけることができます。これは、大きな枠組みとしては「ジャンル分け」という形で分類されていることが多く見受けられますが、個々のゲームタイトルの中にあるゲームを構成する要素を取り出してみると、必ずしも「ジャンル分け」によって分類できないような要素というのを見つけることができます。例えば、アクションゲーム(platform game)の中にも、「サイドビューで歩きまわる」や「近距離／遠距離攻撃と敵の攻撃の回避」や「謎解き／トラップ回避」、「レベルアップ／成長」など、遊びの要素が混合して存在しています。

また、ゲームプレイそのものではなく、ゲームプレイを補助する機能に位置する要素というものもあります。例えば、メニューシステムや、画面の構成と遷移の仕方、セーブシステム、操作の補助、などがあります。

ここでは、上で述べた「ゲームを構成する要素」のことを「ゲームフィーチャー」と呼ぶことにします。フィーチャーというのはfeatureのことで、直訳すると「機能」という意味になります。また、先に述べた、ゲームプレイを構成する要素のことを「ゲームプレイフィーチャー」と呼び、ゲームプレイを補助する機能の要素のことを「ゲームシステムフィーチャー」と呼ぶことにします。

現存しているゲームで、このゲームフィーチャーに相当するものとしてどういうものがあるのか、思い出してみましょう。

まずは、ゲームプレイフィーチャーとしては、以下のものが思い出されます。詳細な説明は無しで、簡単な説明、または呼び名だけで列挙してみます。

• プレイヤーキャラクターの位置の操作
• アイテム
• スキル
• 敵との戦い（攻撃と回避）
• 謎解き／パズル
• クエスト（おつかい）
• ストーリー（一応、楽しめる要素として）
• 成長／育成
• 陶酔／リズム
• 運（ギャンブル性）

このような感じでしょうか。

次に、ゲームシステムフィーチャーに相当するものは、以下のものがあります。

• ゲーム情報の提示（ゲームプレイをする上で必要な情報の表示）
• メニューシステム（情報参照や機能呼び出しのためのユーザーインターフェイスの大枠）
• セーブシステム
• 操作方法のカスタマイズ
• 画面遷移
• BGM/SEの音量設定
• 難易度設定（最近は、自動判定のものもあり）

このような感じでしょうか。

ここで挙げた各ゲームフィーチャー以外にも、ゲームフィーチャーに相当するものは存在すると思いますので、それらも含めて厳密にパターンとしての名称と定義を決め、それをゲームデザインを行う人たちの間に広めなければ、ゲームデザインについての議論が発展しにくいと考えています。

ゲーム開発における専用ツール開発の有用性

人類は道具を使うことによって大きな進歩をしてきました。石を削り刃を作り、それで肉を切ることで食べやすくしたり、さらにそれを使って新しい道具作りに活用したりするなど、道具による道具の発展という可能性も広げました。このような歴史をたどって今があるということを考えますと、現代人においても道具というのはとても重要な存在に感じられます。

コンピュータ分野においては、こういった「道具」的な役割を持ったものはソフトウェアとして提供され、これらは「ツール」と呼ばれます。

さて、ゲーム開発においてもツールというのはたくさん使われるものであります。ゲームに使われるツールの種類としましては、主に以下のものがございます。

• グラフィック系ツール（2D/3D）
• 音系ツール
• プログラミングツール
• テキストエディタ
• 表計算という皮をかぶった「Microsoft Excel」という名の日本を支配している謎の統合環境。方眼紙として使われることも

グラフィックや音関連に付きましては、ゲームを表現するための素材を作るためのツールということになります。いわゆる飾り付け部分のための道具ということになります。

プログラミングツールの存在は、ゲームが実際にゲームとして動くための情報を記述したり出力したりするための道具になります。このツールによって、ゲームがゲームとしてルールに沿って動くことが出来るようになります。

さて、単純なルールと表現だけでゲームは作れるのですが、ゲームの内容の規模が大きくなってきますと、ゲーム内部で扱う情報の量が当然増えてくるわけですが、そういう情報をプログラムから取り出して外部のデータとして扱うというパターンが出てきます。そして、そういった外部のデータを記述するためのツールとして、テキストエディタや、Excelが使われる場面が出てきます。

ゲームで扱う情報の形式で多いパターンとしては、以下のものがあります。

• リスト（行単位で情報が記述されたテキストなど）
• テーブル形式（CSVなど）
• 構造化形式（XML, JSONなど）
• 独自のバイナリ

上記のような情報を記述するためのツールとして、テキストエディタやExcelを例に出しましたが、時には、扱う情報の種類に特化した専用のツールが使われるパターンがあります。そういったものの例としては、マップエディター、レベルエディターがあります。これらは言わば、ゲーム世界を構築するためのコンストラクションツールと言えるでしょう。

マップエディターに関しては、汎用的に使えるツールを見かけることがありますが、少しでもゲームの内容に特化した情報を付加させようとすると、そのツールでは物足りなくなります。レベルエディターについては、厳密にゲームデザインに沿った形になっていなければなりません。

ゲームデザインが固定化しているジャンルにおいては、いわゆるゲームエンジン、ミドルウェアといった形でレベルエディターが提供されているものがあります。

もしあなたが、あなたオリジナルのデザインによって世界を構築したいのならば、それを構築するためのツールを作るという選択肢を考えて下さい。それは単にデータ作りが楽になるだけではなく、むしろ、ツール無しでは作られることのなかった世界がそこで構築されることになるのです。

「制限があるほうが人は創造的になれる」という話を聞きます。まったくの無から有を生み出すことは非常にコストのかかる作業になります。厳密には無理でしょう。なぜなら、まったくの新しいものと思われるアイディアも、すでにある何かの組み合わせであるから、という話に由来します。もし、その組み合わせの元になる何かがすでに用意され、組み合わせの選択肢が制限されているとしたら、その作業コストはずっと少なくなります。しかし、それはとても創造的なことなのです。なぜなら、組み合わせこそが創造だったからに他なりません。その制限された創造的な空間を提供するのがツールなのです。

人は、創造のためにツールを使うのではなく、ツールの上で創造するのです。

ゲームよって発生されうる感情や感覚、楽しみの要素について

ゲームの楽しさが何であるかということについては過去に多くが語られ、そして誰もが納得出来る答えをしている場面は未だ見受けられないという現実があります。頻繁に見かける回答としては、ある固有のゲームタイトルにおいて突出して感じられる何らかの感情・感覚を取り上げ、「それこそがゲームの楽しみである」と論ずる場面です。もちろん、一つの固有ゲームタイトルにゲーム全般の遊び要素が含まれているということは少ないので、他のゲームタイトルを例に出して反論されるというのが恒例の行事のようにさえなっています。

では、ゲーム含まれる、いわゆる「楽しみの要素」が一つでは無いのだとしたら、それはどういったものがあるのか、探すこととしましょう。私個人がこれまでに体験したことのあるゲームから感じられた感情・感覚や楽しみの要素としては以下が挙げられます。

• 生理／本能系
• 暴力(violence)
• 性(sex)
• スピード感(speed)
• 恐怖感(horror)
• 緊張感(thrill)
• 雰囲気系
• 畏怖感(awe)
• 哀愁不安感(nostalgia)
• 気味悪さ(creepy)
• 没入感(immersion)
• 臨場感(real)
• 爽快感(effects)
• 酩酊系
• リズム感(rhythm)
• グルーブ感(groove)
• 達成感／完了感(done)
• 知性系
• 観察(observe)
• 発見(discover)
• 冒険(adventure)
• 戦略(strategy)
• 資源管理(resource management)
• パズル(pazzle)
• 創造(create)
• カタルシス(catharsis)
• 自我系
• 成長感(grow)
• アバター／部屋などのカスタマイズ(arrange)
• 世話(care)
• 社会系
• 優越感(superiority)
• 自尊心(esteem)
• 支配感(control)
• 情操系
• 悲哀感(miserable)
• 友情／仲間(friends)
• 愛情／恋(love)
• 自己実現感(success)
• 正義感(justice)

上記のうち、筆者が関心を得ている要素について、今後このブログで詳しく扱っていきたいと考えています。

ゲームプログラミングにおけるモジュール分割

プログラミングを行う上で、処理をある単位で分割してプログラムを組むということが行われます。これはよく「モジュール分割」と呼ばれます。ゲームプログラミングにおいても、このモジュール分割はしばしば行われます。では、ゲームプログラミングする上でどのような内容のモジュールが作られることがあるのかご紹介します。

コアシステムモジュール

コアシステムモジュールは、プラットフォームAPIを直接使うような"システム"に近い位置に居るモジュールです。主に以下のようなモジュールがあります。

• ファイルI/O
• リソース管理
• グラフィクス
• サウンド

この「コアシステム」系のモジュールは、ライブラリやミドルウェアなどによって提供されることが多いです。それぞれの具体的な仕様については、設計毎に異なりますし、「どういう仕様であるべきだ」という話（例：「サウンド管理はリソースレベルで管理すべきか？」など）はについてはここでは触れません。

ゲームモジュール

対してこちらは、ゲームシステムやゲームロジックに近い位置にあるモジュールです。ゲームシステム上で必要になる仕組みや、ゲーム仕様を実現する処理単位などがこれにあたります。例として、以下のようなものが挙げられます。

• タスクシステム
• ゲームモード／シーン管理
• マップ／イベント管理
• スプライト
• キャラクター管理

これら以外にも、ゲームジャンルによっては様々なモジュールが必要になってきます。

【注意】ここでは「コアシステムモジュール」「ゲームモジュール」という呼び方をしていますが、これはあくまで私個人が定義した名称であって、すでに誰かが似た概念を提唱していた場合、それと異なる名称である可能性があります

ゲームの企画書を書く"伝える"以外の目的

ゲームの企画書を書く目的としてまず一番に思いつくのが「ゲーム開発に携わる人に対して企画の意図と内容を伝えるため」というのがあります。確かに、その企画の意図と内容を伝えるためには、それをまとめた資料というのがあったほうが良く、それが「企画書」という事になると思います。では、もし企画に携わる人間が「自分たった一人」であった場合、企画書を書く必要は無いのでしょうか？

私が考える、意図と内容を人に伝える以外の「企画書を書く目的」としては「企画内容を自ら参照・記憶し、改良を重ねる土台とするため」というのがあります。

参照する

人の記憶というのはとても儚く、それを思い出さない限り、そもそもそんな記憶があったのかどうかすら証明することができません。今あなたが思いついたアイディアを、ぜひ書き留めて下さい。あなたは記憶を失うことはないでしょう。

記憶する

アイディアというのは、記憶してある点と点を結びつけた時に生まれるものです。あなたは、あなた自信が考えたアイディアを忘れることは無いだろうと考えるでしょう。しかし、先程も申し上げましたように、自然の流れに沿うと、その記憶は失われることになります。新しく考えたアイディアを記憶するために、そのアイディアを何度も参照しましょう。そして、そのために記録し、まとめるのです。

改良する

プログラマの間で言われていることで「自分が書いた３日前のコードは他人のコードのように見える」というのがあります。これはプログラミングだけに言えることではなく、自らが考えたこと全般で言えることのように思います。同様に「企画内容」についても、数日経てば「どうしてこんなことを考えたんだろう？」と、自分で考えた企画にもかかわらず、あとになって疑問を抱くことがあります。この疑問抱くこと自体には問題は無く、むしろそうやって疑問を持つことが、企画の改良に繋がっていくと思います。

また、企画の意図と内容を企画書としてまとめておくことで、それを他人に評価してもらうことが可能になります。ぜひ、レビューを受けましょう。そして意見をもらい、さらなる改良へとつなげるきっかけとしましょう。このとき注意していただきたいのは、企画の主軸となる意図を明確にしておくということです。意図が不明な場合、レビュー者は無責任な提案を声高々と繰り返すでしょう。また、意見や提案とも言えないただの非難や不毛と感じる的はずれな意見は、基本的には聞いてるふりをして無視しましょう。


以上のように「ゲームの企画書を書く」ということは、それを伝える以外にも、自分の中で考えをまとめ、記憶し、改良へとつなげるツールとなるのです。ぜひ、アイディアを記録し、記憶し、企画レベルでの品質向上を目指しましょう。