rozen kranz

ゲーム開発には、社会科学の側面があるかもしれないし、ないかもしれない。ないとしても、前提を考えてみるのは重要かもしれない。

　疑問：　ゲームを開発する上での前提は何だろうか？


この記事では、より具体的に、次の疑問を考えたい。

　疑問：　より多くの人に、より長い間遊んでもらえるゲームを作る、というのはゲームを開発する上での前提だろうか？


一つ目の前提、より多くの人に遊んでもらえる、楽しんでもらえるゲームを作るというのは、そのままの意味である。






















この図では、あるゲームをより多くの人が楽しめるようにするという改善・修正活動は、そのゲームのデザインに適用されるとして表している。ゲームデザインとは、このゲームを作るために決定された結果の集合だと考えている。たとえば、RPGでいえば、LVのあがりやすさのパラメータの調整や、ゲームのテンポ、ユーザインタフェースに関する決定結果を意味する。


二つ目の前提、より長い間遊んでもらえる、楽しんでもらえるゲームを作るというのは、ゲームのクリアに必要な時間ではなく、ゲームを自由にプレイすることを意味する。コンピュータゲームでないゲーム、たとえば将棋は一回の対局で終わりでない。同じように、コンピュータゲームも一度クリアし、エンディングに到達したとしても、楽しみ方が残されていればまだ遊ぶことができる。


























「より多くの人に、より長い間遊んでもらえるゲームを作る」を前提とし、「楽しめる人の数」と「楽しめる時間」を軸にして図で表すとこうなる。





















この図に基づいて考えると、大雑把には、あるゲームのデザイン状態は次の4つのどれかに当てはまる。

ゲームのデザイン状態

	楽しめる人の数	楽しめる時間
理想でないゲーム	少ない	短い
まだ理想でないゲーム	少ない	長い
まだ理想でないゲーム	多い	短い
理想とするゲーム	多い	長い

　






もちろん、何人以上もしくは何時間以上あればある状態であるという一般的な基準はない。さらには、あるゲームのデザイン状態から、楽しめる人の数や楽しめる時間のデータを取ること自体も容易ではない。そのため、以前の状態よりより多くの人が楽しめるようになったのか、より長く楽しめるようになったかの比較も容易ではない。

この二つの前提が意味するのは、状態の意図的な変換の向きが決まっているということだといえる。ここで意図的と書いたのは、状態のデータ（楽しめる人の数や楽しめる時間）を得ることは容易でないため、意図しない逆の変換が行われる可能性があるからである。

意図的な変換の向きには、二つある。

　（1）楽しめる人の数を増やす変換

　（2）楽しめる時間を長くする変換

では、これらの二つの変換の妥当性は何か。言い換えれば、二つの前提は妥当な前提か。妥当でないとするなら、図で表すとこうなる。

























この場合、意図的な変換の向きは4つになる。

　（1）楽しめる人の数を増やす変換

　（2）楽しめる人の数を減らす変換

　（3）楽しめる時間を長くする変換

　（4）楽しめる時間を短くする変換

次の記事では、これら変換の意味する観点から、ゲーム開発での前提を考えたい。さらには、他の軸がどうかどうかについても考えたい。

ゲームプログラムにおける「シーン管理」をデザインパターン（あるいはアーキテクチャパターン）として書くことに挑戦するシリーズ。


シーン管理の現状：

どの分野でもそうであるように、ゲーム開発でもそこで関わる人たちの間で使われる言葉がある。たとえば、「タスクシステム」であったり、今回パターン化を目指してみる「シーン管理」がある。

みんながどんな意味で「シーン」という言葉を使用しているか。たとえば、ゲームのタイトル画面の場面、ゲームプレイ時の場面、スコア表示の画面の場面、ゲームオーバー時の画面の場面など、そういう構成単位を「シーン」と呼んでいる。

　参考：
　　・Javaによるゲーム解説　－８－

　　・第七章．シーン管理クラスの設計１ 

　　・その８ CS３: シーンを切り替え初期化し再生する

　　・Ruby/SDL で始めるゲームプログラミング【後編】

　比較的実装の話の参考：
　　・シーン管理その2

　　・サブシーンについて1


これらの参考ページから分かるのは、シーンとはなんぞやという簡単な説明からはじまり（ない場合もある）、続いてすぐにコード、つまり実現方法の話になるということ。

しかし、パターンとして記述するには、シーンとは何か、に加えてもう少し問題の文脈を明確にし、問題に対する解としてのプログラム構造をガイドできるようにする必要がある。


シーンのコンセプトの特徴付け：

ということで、シーンというコンセプト自身の特徴付けを行う。この特徴付けは、特定の実現方法（プログラミング言語など）に依存せずに行う。

シーンのコンセプトを特徴付ける基本要素を4つ考えてみた。

　（１）シーンは、１つ以上ある：　よほどシンプルなゲームでない限り、シーンは１つ以上存在する。

　　　例：　タイトル画面のシーン、デモ画面のシーン、ゲームプレイ時のシーン、ゲームオーバー画面のシーンなど。


　（２）シーン毎に、画面描画が異なる：　あるシーンと他のシーンとの違いの１つは、画面描画の違いにある。

　　　例：　タイトル画面のシーンでは、タイトルに関連する描画要素を描画するが、ゲームオーバーに関連する描画要素を描画する。
　

　（３）シーン毎に、ゲームユーザからの入力制御が異なる：　あるシーンでは意味のある入力が他のシーンでは意味がない、もしくは別の意味がある。意味とは、入力に対する処理の違い。 

　　　例：　タイトル画面のシーンでのキーボード入力"↑"はゲームのメニュー項目（たとえば新規ゲーム、続きからプレイ）を決定するという処理を行うが、デモ画面のシーンでは、入力"↑"に対する処理は行わない。
　
　　　例：　タイトル画面のシーンでのキーボード入力"A"はゲームのメニュー項目を決定するという処理を行うが、ゲームプレイ時のシーンでの入力 "A" は、キャラクターの攻撃処理である。


　（４）あるシーンと他のシーンとの関係がある：　つまり、あるシーンから他のシーンへの遷移がある。

　　　例：　ゲームオーバー画面のシーンからタイトル画面のシーンへの遷移がある。

　　　例：　タイトル画面のシーンからデモ画面のシーンへの遷移があり、デモ画面のシーンからタイトル画面のシーンへの遷移がある。


これらの要素はすごく当たり前かもしれないは、これらがプログラム構造を規定する基本要素となる。


シーンのコンセプト図：

上で特徴づけしたことを図（メタモデル）で表すとこうなる。











具体例を図（モデル）で表すとこうなる。













今後の調査内容：

今回は、シーン管理のデザインパターン記述の前準備として、シーンのコンセプトの特徴づけとして４つの基本要素を定義したけれど、これだけでは不十分といえる。議論しなかったものには次がある。


　（１）シーンの関係の動的性：　ゲームで必要なシーンの集合、もしくはシーン間の遷移関係は、ゲーム開始から終了まで静的に決まっているのではなく、ゲームプレイ時の状況に応じて動的に変化するかもしれない。

　（２）シーンの粒度と分割の基準の考慮：　どんな粒度で１つのシーンと見なすのか。その分割基準は何か。シーンをあまり細かな粒度に分けると、シーン数が増えて管理が難しくなるかもしれない。シーンを管理するプログラム構造は、粒度の異なるシーンに適切に対処できる必要があるかもしれない。

むむ、こんな本が。

　ゲームクリエイターになりたい人の本
　成美堂出版編集部 編
　http://pc.bookmall.co.jp/search/info.php?code=0000001601091

トップクリエイター7人へのインタビューを収録。ゲームソフト開発の流れ、職種と仕事内容、クリエイターになる10のキーワードなどを紹介。

買うかどうかは分からないけど、一応チェック。

これは気になる！

　ダンジョンゲームプログラミング 
　森山 弘樹 (著), 鷲見 健二 (著) 

3/27発売らしい。

amazonの紹介文によると。

1000回遊べるゲームの作り方を学ぼう! 「ローグ」型ゲームのプログラミング手法をサンプルプログラムを元に解説。自動迷路作成のアルゴリズムからモンスターのAIなどなど、ローグ型ゲームの作成に必要な技術を網羅しました。「1000回遊べるゲーム」の仕組みと作り方をしっかり勉強しましょう!!

「ローグ」や「シレン」に代表されるフロア自動生成型ダンジョンゲームの仕組みと製作技術を、実際のサンプルプログラムを元に徹底解説。自動迷路作成のアルゴリズムから、ターン式の戦闘処理、アイテムシステム、トラップシステム、食料システム、モンスタールーム、モンスターの行動(AI)などなど、ローグ型ゲームのプログラミングが丸わかりです!!

らしい。買うかも。

はじめに：

『ゲームデザイナーの仕事 プロが教えるゲーム制作の技術』という本が最近発売されました。ゲームを制作する上で参考になる本だと思いました。まだ全部読んでいませんが、ゲームを制作する上で基本的なことを書いてくれているように思います。読んでいて、今まで考えたことがなかったことなども多くあり参考になりそうです。

この本は、最初の方では「ゲームデザイン」という作業の定義から始まり、その作業がさらにどのような作業からなっているのかを説明しています。しかし、「ゲームをデザインする」という活動の本質を考えた場合、もう少し詳細な分析が必要ではないかと思いました。

そこで、この記事では、この本でのゲームデザインの定義とゲームデザインを構成する活動の議論から出発した後、ゲームデザインの本質を理解するえで考えなけばならないことを議論します。特に、ゲームデザインという作業を一般的に捉えた場合、ゲームデザインは、ゲーム制作の形態（商業、もしくは趣味・同人）や開発者数（少数か多数）に依存しない作業としての認識が必要であるとを議論します。


ゲームデザインとは：

『ゲームデザイナーの仕事』では、ゲームデザインを次のように定義しています。

ゲームデザインとはプレイヤーとの信頼関係を築く作業である

としています。

そして、信頼関係を築く方法を、次の二つの言葉で要約しています。

（1）ユーザビリティの概念を持つ。
（2）目的意識を強く持つ。


さて、ゲームデザインを、信頼関係を築く作業であるという観点から定義することの妥当性に関しては、この記事では深く議論しません。ある作業は、異なる観点から特徴付けられると思うからです。そもそも「デザイン」という用語に関してさえ、様々な観点から特徴付けられます。

In Guy Steele's 1998 talk at OOPSLA, 'Growing a Language', he said:

A design is a plan for how to build a thing. To design is to build a thing in one's mind but not yet in the real world - oe better yet, to plan how the real thing can be built.

I once wrote:

Design is the thinking one does before building.

Carliss Baldwin and Kim B. Clark define design like this:

Designs are the instructions based on knowledge that turn resources into things that people use and value.

----- Pattern-Oriented Software Architecture: On Patterns and Pattern Languages

次に、ゲームデザインがどのような作業からなるのかです。『ゲームデザイナーの仕事』では、ゲームデザインは、次の三つの作業からなるとしています。

　（1）企画
　（2）システムデザイン
　（3）バランス調整

「企画」とは、この本によれば

アイデアを企画書にまとめてプレゼンに通すこと

です。

企画はさらに次の作業からなるとしています。

　（1.1）企画書の作成
　（1.2）予算の承認を得る
　（1.3）企画の骨子をプロジェクト参加者に伝える

「企画書」とは、この本によれば

自分たちの考えたアイデアが実現可能であると証明するために、その概要をまとめた書類

です。

「予算の承認を得る」とは、この本によれば

企画がプレゼンテーションに通過する

ということです。

「システムデザイン」とは、この本によれば

企画書でまとめた大雑把なゲームシステムのアイデア、ルールを発展させていく形で、細かな仕様を決めていき、それを仕様書としてまとめる

ということです。「仕様書」とは、

　・確率
　・計算式
　・ルール
　・アイテムの効果（パラメータ）

など、ゲームの「仕様」をまとめた設計図とのこととしています。

「バランス調整」は、この本によれば、次のように書いています。

「仕様書の作成まで進めば、あとは実際にゲームを作っていく作業に入ります。グラフィックなどの素材の作成や、プログラミングの作業です。いわゆる「テストプレイ」と「デバッグ」もこの作業に含まれます。デバッグは「バグ取り」などとも呼ばれる、いわゆるプログラム、パラメータなどのミスの修正です」

何が問題か：

以上のことから、この記事で取り上げたい疑問を一言でいうとこうです。

　疑問：これらの活動は、ゲームデザインという活動を考える上での必須の活動か？

というのも『ゲームデザイナーの仕事』では次を前提としてゲームデザインを議論しているためです。

　（1）ゲームデザインは、商業のゲームを作る際の活動である。

　（2）ゲームデザインは、集団で行われる活動である。

現実的な観点からは、これらを前提とするのは適切であると思われます。しかしながら、一般的に言えば、ゲームデザインという活動は、これら二つを前提としない活動であるといえます。なぜなら、次の事実が存在するためです。

　（Ａ）商業のものでない、趣味や同人で作られるゲームが存在する。

　（Ｂ）ゲームは、一人でも作れる。

そのため、この本の議論に従えば、ＡやＢに相当する条件で制作されたゲームは、ゲームデザインの活動を部分的しか伴わないことになります。したがって、ゲームデザインは、必ずしも次の作業を全て伴いません。

　（1）企画
　（2）システムデザイン
　（3）バランス調整

いくつかの作業は、ゲームをデザインするうえで必須の作業ではありません。

たとえば、「企画」という活動は、趣味のゲーム制作であり、かつ小規模なゲームであるなら、不要な活動です。予算という要素は存在しませんし、プレゼンをする必要はありません。プロジェクト参加者に伝えることも不要です。

「システムデザイン」の活動においても、仕様書は必須の成果物ではありません。

また「バランス調整」は、活動としてまとめるには大雑把すぎるのではないかと感じます。たとえば、コンピュータゲームをソフトウェアの一種だとすると、ゲームデザインとソフトウェアデザインとの違いはなんでしょうか？　

また、次のような疑問を思い浮かびます。

（a）ゲームを作るうえでプログラミングは必須の作業でしょうか？　ＲＰＧツクールで制作されたゲームは、デザインされたゲームではないのでしょうか？

（b）役割についても、プログラマーはゲームデザイナーでしょうか？　テストプレイヤーは、ゲームデザイナーでしょうか？　そもそも、ゲームデザイナーは、ゲームをデザインする、という役割を持つ人をさす用語ではないのでしょうか？


表でまとめると次のようになります。ゲームデザインとはせずに、ゲーム制作での活動としました。活動の分類の軸として、「開発者数」と「制作形態」があるとしました。他の軸もあるかもしれません。

ゲーム制作における活動

		制作の形態
		商業ゲーム	趣味・同人ゲーム
開発者数	少数	？？？	？？？
開発者数	多数	（1）企画 　（2）システムデザイン 　（3）バランス調整	？？？

まとめ：

ゲーム制作の形態や開発者数に依存することなく、ゲームデザインという活動を認識し、理解を深めていく必要があります。