ゲームプレイ環境とゲームデザインの適合構造
「ゲームプレイ環境とゲームデザインの適合構造」という章を「ゲームデザインの理論」のドキュメントに追加しました。
このエントリでは、その章の抜粋(と少しの編集)と、書きながら悩んだことをあとがきとして紹介します。
ゲームプレイ環境とゲームデザインの適合構造
「ゲームプレイ環境とゲームデザインの適合性」の章では、
ゲームプレイヤーは、自身のプレイ環境に適合するゲームデザインを期待する
ということを主張しました。
下記の図は、ゲームプレイ環境とゲームデザインがうまく適合していない状況の一例を示しています。
ゲームプレイ環境の定義は以下です。
ゲームのプレイ環境とは、ゲームプレイヤーとゲームを取り巻く現実世界の空間に存在する人および人工物の集合である
ゲームデザインの定義は以下です。
ゲームデザインとは、人を楽しませたり、面白くさせるという目標を達成するために必要であるとして決定した事柄(デシジョン)の集合である
この章では、ゲームプレイ環境とゲームデザインを関係付けます。関係付けたモノをここでは、「ゲームプレイ環境の適合構造」と定義します。
ゲームプレイ環境の適合構造とは、ゲームプレイ環境を構成する要素(エンティティ)とゲームデザインの要素(デシジョン)との間の適合関係から成るモノである
下記の図は、ゲームプレイ環境の適合構造のモデルを示しています。
このモデルでは、デザインがプレイ環境に「適合している」という関係ではなく、「適合していない」という関係を強調するモデルです。
図の下部の例は、以下のように解釈します。
「セーブデータは一つ作れる」というデシジョンは、「ゲームをする家族がいる」というプレイ環境に適合していない
あとがき
書きながら悩んだことの一つは
- 読者、特にゲームデザイナーの方からの「だから何?」
という質問に答えられるかどうかです。
回答の一つは、「どんなプレイ環境でプレイされるのかを想定してデザインする必要がある」というものです。しかし、この回答の粒度と上記の議論の粒度とは一致していないように思えました。つまり、一つのエンティティとデシジョンが(不)適合関係にあるかどうかという議論は、粒度の小さいものに感じます。
もう一つ悩んだのは、適合の定義です。
- 適合しているかどうか、あるいは、不適合かどうかの判断基準は何でしょうか?
- そもそも、適合している/していないの二択なのでしょうか?
適合とは、ある/ないでなく、度合であるように感じます。しかし、このことをうまく表現できませんでした。
以下は、考察です。
- (1) すべてのデシジョンがプレイ環境でのエンティティと適合関係を持つわけではない:
別の言い方をすれば「特定のデシジョンが特定のエンティティと関係を持つ」ということです。
- (2) ゲームプレイ環境の概念だけでは不十分である:
「プレイ環境」だけでなく、「プレイ状況」あるいは「プレイ文脈」という概念と、ゲームデザインの関係付けが必要に思っています。
一つの事例としては、「ゲームの時間設定(その1)」という記事が参考になります。この記事では、通勤電車に乗っている20分くらいの時間に適したゲームの遊び方をしたいのだけど、既存のバズルゲームなんかは、そういうふうになっておらず、時間の無駄ができて不満だ、と書いています。つまり、「20分のスコアアタック」がなく、あるのは、開発者が決めた「○分間のスコアアタック」だけであり、プレイヤーが自由に時間を設定できないと書いています。
この例でのゲームがプレイされている様子は、プレイ環境というよりは、プレイ状況と呼ぶのが適しているように思えます。プレイ状況は、たとえば、以下のように記述できます。
- 「プレイヤーは、通勤電車に乗っており」、
- 「乗っている時間は20分である」
この状況と不適合なのが、たとえば、以下のようなデシジョンです。
- 「30分間のスコアアタックモードがある」
不適合から発生するプレイヤーの不満は、以下のようなものです。
- 「時間の無駄ができる」
このことからは、
ゲームプレイヤーは、自身のプレイ状況に適合するゲームデザインを期待する
と考えられます。
とはいえ、プレイ状況の定義とさらなる分析が必要です。
ゲームデザインとゲームプレイヤーの不満感情の原理
ゲームデザインについて色々考察してるわけだけど、最近は、プレイヤーを理解することに重点を置いている。
ちょっとした思いつきで、『真・女神転生 STRANGE JOURNEY』(以下SJ)をプレイしたユーザが、どんな種類の不満の感情を持っているのかを軽く調べてみた。データは、ndsmk2に投稿されたレビューを使用。
結果は、以下の通り。
- 面白くない
- だるい
- めんどくさい
- イマイチ
- 簡単
- 作業的
- 〜しにくい
- 理解できない
- 違和感
- 魅力に欠ける
- イライラする
- もっさり感
- ストレスが溜まる
- ダレる
- 理不尽
- うんざり
- 単調
- しんどい
- 緊迫感がない
- 気持ち悪い
- 親切でない
- 楽しくない
- 不便
- ワクワクがない
- 退屈
- うざい
- 疲れる
- 嫌らしい
- うんざりする
- 意地悪
- 寂しい
- 味気が無い
- 嬉しくない
- 達成感が殺がれる
- テンポが悪い
- 戸惑う
- うっとうしい
- しつこい
- 苦痛
- 邪魔
- 不快
本当は、以下のような疑問について考えたり、さらに詳細な分析も必要だけど、とりあえずは、各項目が一つの「不満の感情」に対応するとして考えてみる。
- 「感情」と呼ぶのが適切なのかどうか
- 項目間の関係性: たとえば、「理解できない」ので「イライラする」ので「楽しくない」というような関係性があると見なすのかどうか。
- 項目間の類似性: 「意地悪」と「嫌らしい」は、異なる感情だと見なすのかどうか。
いずれにせよ、上記の項目は、プレイヤーが表現したものであることは確か。
下記の図は、ゲームとプレイヤーの不満感情の関係モデル化したもの。
あるゲームは、SJの上記の項目のように、考えられる不満感情の一部に対応付けされる。
上記のモデルでは、あるゲームから不満感情への対応付けだけど、もう少し詳細化したモデル化も可能に思える。僕の理論では、
- ゲームは、ゲームデザインを実現化したものである
- ゲームデザインは、デシジョンとデシジョン間の関係からなる構造である
- ゲームデザインに対するプレイヤーの不満は、以下の場合に発生する
- (1) 個々のデシジョンから発生
- (2) デシジョン間の関係から発生
という見方をしてる。
この見方によれば、上記のモデルは、下記のようになる。
下記の図は、最初のモデルと二つ目のモデルの関係を示している。
このようにモデル化することで、以下が考察できる(あるいは、仮説を設定できる)。
- (1) あるデシジョンから特定の不満感情への対応づけの度合が存在する: たとえば、あるRPGでの「ラスボスは、10回攻撃できる」というデシジョンがあったとすると、「理不尽」という感情に対応づけされる可能性は多くても、「気持ち悪い」という感情に対応づけされることは恐らく少ない。
下記の図は、対応付けの度合いを線の太さで表現している。太いほど、対応づけされる可能性が高い。
- (2) あるデシジョン構造から特定の不満感情への対応づけの度合が存在する: 一つ目と同じだけど、例が思い浮かばない。
冬コミ終り
購入してくださった方々ありがとうございました。
20部と少しを持っていたのですが、12時半ぐらいには、見本以外はなくなりました。
もっと持っていってもよかったかなと思いました。ちなみに、持っていかなかったのは単に製本が間に合わなかっただけ。
完成版のPDFはこちら。
ローゼンクランツ,『ゲームデザインについて考えてみた』, コミックマーケット77, 2009.
※「ゲームデザインの理論」のドキュメントを冊子にしたもの。
- 個人的に印刷したり
- 何らかのテキストとして印刷して使用したり
- 文献として引用したり
は自由ですのでぜひ活用してください。
次の夏コミでは、オフセット本で頒布したいなあと。
冬コミ頒布:ゲームデザインについて考えてみた
ローゼンクランツ
火曜日(一日目) 西 "り" 06b
ゲームデザインについて考えてみた
※ゲームデザインの理論のドキュメントからいくつかのトピックを抜粋して、修正・編集したもの。
まえがき書いたり、まだ修正するけど、ほとんど完成バージョン。PDF
A5で78ページ(あるいは80ページ)です。20部ぐらい作ろうかなと思い中。
なお、インクジェットプリンタ&安物のコピー用紙で印刷して製本するので、しょぼいです。
コミケ
思うことがあって、しばらく沈黙してましたが・・・。
コミケにうっかり当選してるので、一つ頒布するかもしれません。
頒布予定は、「ゲームデザインの理論」を編集したものにしようと思ってます。
まともに編集できれば、20部ほど、編集できなければ(=Webページをほとんどそのまま)、10部ほど頒布を計画してます(希望があるのであればもっと準備も可)。時間がないのでコピー誌です。
Webページをそのまま仮にWordに貼り付けたら70ページほどだったので、だいたいこの前後のページ数です。
頒布価格は、200円か300円ぐらいにしようと思ってます。
完成版は、PDFで後にフリーでダウンロードできるようにするつもりです。
以上。
ローゼンクランツ
火曜日(一日目) 西 "り" 06b
ゲームデザインについて考えてみた
ゲームデザインパターンについて考えてみる その4:ゲームデザインパターンの記述形式
ゲームデザインパターンの第4回目。
これまでのエントリでは、ゲームデザインパターンの記述形式については、特に気にすることなく議論してきた。
今回のエントリでは、ゲームデザインパターンの記述形式について考えてみたい。特に、僕の書いたパターンを、mnagakuさんが、他の分野でのパターン形式でまとめてくれたので、それについて思ったことをもとに考えてみたい。まとめてくれた記事は以下。
基本形式によるパターンの記述
使用されたパターン形式は、「名前」「コンテキスト」「フォース」「解決策」という最低限必要な項目でパターンを記述するもの*1。mnagakuさんによれば、各項目には次のことを記述する。
「名前」
ゲームデザインパターンについて
共通の語彙となるもの
「コンテキスト」
問題:解決すべき課題
状況:パターン適用前の周囲の環境
「フォース」
解決に至る際に考慮した事柄
「解決策」
フォース間のバランスを考慮した解決策・手順
この形式をもとに、僕の「弱点属性パターン」と「耐性属性パターン」を、mnagakuさんが記述したのが以下になる。
名前「弱点・耐性属性パターン」
弱点・耐性属性パターン
コンテキスト
状況:戦闘システムが単調でプレイヤを「力攻め」に誘導してしまう
要求:プレイヤを「試行錯誤」に誘導し、戦闘に関するノウハウ学習を楽しませたい
フォース
戦闘システムの複雑さ
プレイヤの理解の容易さ
プレイヤの楽しさ
実現の容易さ
※戦闘システムを複雑にしようとする力と、簡単にしようとする力の間でトレードオフを見ることになる
解決策
攻撃・防御に、複数の属性を持たせ、属性間の優位性を定義する
攻撃が優位属性となる場合、防御力がプレイヤに分かるぐらい下がる(弱点)
防御が優位属性となる場合、攻撃がほぼ無効化される(耐性)
付記
プレイヤは属性を意識した戦術に導かれ、属性間の優位性や、自身の武器の属性、敵の属性について考えるようになる。適度に複雑な戦闘システムに対し、学習する動機付けがなされ、学習の結果で得られる勝利により、達成感が得られる。
この記述に対する僕のTwitterでの反応はこう。
参考になりました。ただ、そのコンテキストとフォースをだけを見せて、その解決策に至るのかどうか気になりました。ただし、それは、記述の詳細度に依存するかもしれません。
http://twitter.com/asatohan/status/5049793116
もう少し補足すると、「フォース」の部分がかなり一般的であることに注意したい。
- 戦闘システムの複雑さ
- プレイヤの理解の容易さ
- プレイヤの楽しさ
- 実現の容易さ
これらは、「コンテキスト」にほとんど依存しない「フォース」に思える。つまり、この 解決策を導く根拠としては弱い。たとえば、『真・女神転生3』や『アバタール・チューナー』のプレスターンでも解決策として導いてしまうのではないか(たとえば、「ターン増減パターン」として)?
プレスターンは、弱点や耐性のシステムを基盤として作られているシステムであり、そういう意味で粒度が大きな解決策(システム)である。しかし、この粒度でも、この コンテキストでのこの フォースにおいての解決策となってしまうと考えられる(繰り返し起こる解決策かどうかは考慮しないとする)。
同様に、「コンテキスト」も一般的であると思われる。戦闘システムとは、ドラクエなどの通常のRPGを想定しているのか? シミュレーションRPGではどうか? ダンジョンRPGではどうか? アクションでは?
つまり、コンテキストとフォースの一般性の高さ(あるいは、抽象度)は、コンテキストとフォースを共有、あるいは部分的に共有するような多数のパターンの存在を許してしまう。
- (1) 粒度が同じ解決策を導く多数のパターン
- (2) 粒度が異なる解決策を導く多数のパターン
これらは以下の疑問を生む。
- どの解決策が適切なのか? 単にどれかのパターンを選択すればいいのか? あるパターンは他のパターンと比べてどんな点が優れていて、どんな欠点があるのか?
結局のところ、
- コンテキストとフォースの項目は何か意味があるのか?
ということになる。
これらの疑問の存在こそが、僕がこの形式で書けなかった理由である(ここまで詳しくは考えていなかったけれど)。ただし、書けなかったのは、僕自身が実際にこれらの弱点属性や耐性属性を備えたシステムをデザインしたことがないことにも起因する。デザインをそのまま模倣、あるいは、流用したゲームを作ったことはあっても、具体的なコンテキストやフォースを考え直したことはない。
さて、先ほどの僕のTwitterの疑問へのmnagakuさんの返事はこう。
ゲームデザインにおけるトレーサビリティは難しいですね。文脈とフォースをもっと詳細にして制約かけたら、当てはまる解決策は減るので、もっと良くなるかも。 @asatohan 解決策に至るのか
http://twitter.com/mnagaku/status/5050468762
これは、先ほどの形式でゲームデザインのパターンを記述するとするなら、チャレンジになる点だと思う。
でも、ゲームではそもそも制約が緩くて、要求の抽象度が上がる傾向が高いので、文脈に対する解決策が多数出てくると思います。そこが創造的な部分。 @asatohan 解決策に至るのか
http://twitter.com/mnagaku/status/5050579355
パターンでの話としては、解決策が創造的かどうかは重要でないと思う。パターンの基本的な定義からして、解決策としてのパターンは、既に知られているもの。
パターンでの話でない、一般的なゲームデザインでの話なら「文脈に対する解決策が多数出てくる」というのはそうだと思うし、創造的な部分もあると思う。
ゲームデザインのパターンランゲージに向けて
海外では、ゲームデザインのパターン収集やランゲージ化は既に行われてる気もするけれど*2、それらを参考にしつつも日本からもチャレンジしたい。
根本的な問題は、分野に限らずパターンを記述するのは難しいということ。これは、パターン執筆者を限定してしまうということにつながる。できれば、ゲームデザインの経験のある、あるいは無くてもゲームのシステムについて詳しい多くの人が、執筆に参加してもらいたい。
幸いなのは
- はじめから完璧なパターンを書けなくても気にしなくていいこと。
- 全部一人で執筆する必要はないということ。たとえば、このエントリで示したように、僕の書いたパターンを、mnagakuさんが特定の形式で書きなおしてくれた。
がある。
ということで、この節では、段階的な執筆について少し考えたい。
ゲームデザインパターンについて、日本で精力的に活動している人が現状でどれだけいるかは把握できていなけれど、たとえば、y_miyakeさんがいくつかパターンを書いてる。たとえば「過去の自分と協力プレイ」パターン。
このy_miyakeさんの書き方は、特に形式を気にするわけでなくラフな書き方で、
- パターン名
- パターンの大雑把な説明
- いくつかのゲーム事例
で構成されている感じのもの。これは、ゲームに詳しい人なら、書けると思う。難しいかもしれないのは、パターン名で抽象化が必要になるぐらいかな?
次は、僕の書き方で、特に形式はないけれど、デザインの構造を明確に図示する点に特徴がある。
- パターン名
- パターンの大雑把な説明
- 抽象化されたデザインの構造(解決策)
- 事例となるゲームのデザインの構造
図を描くのが面倒なので、そこは欠点。ただ、今後パターン間の関係や組み合わせ、合成を考えるなら、何らの形式で構造を明確にする必要があると思ってやってる。
最後は、今回紹介したmnagakuさんが書かれたようなパターンとしての形式による記述。コンテキストやフォースを項目として明確化するため、今回議論したように、いくつか難しい点が出てくる。
ということで、指針としては、まずはy_miyakeさんの書き方でパターンを大雑把に書いてみるのがいいんじゃないかと思う。このゲームのこのシステムは、あのゲームのあのシステムに似ている、ということから出発して、それっぽいパターン名を付ける。
*1:なお、Meszarosらの A Pattern Language for Pattern Writing では、「パターン名」「コンテキスト」「問題」「フォース」「解決策」
*2:たとえば『Patterns In Game Design』
ゲームプレイ:真・女神転生 STRANGE JOURNEY その3
『真・女神転生 STRANGE JOURNEY』のプレイ感想その3。その1はこちら。その2はこちら。
真・女神転生 STRANGE JOURNEY(ストレンジ・ジャーニー)
- 出版社/メーカー: アトラス
- 発売日: 2009/10/08
- メディア: Video Game
- 購入: 19人 クリック: 708回
- この商品を含むブログ (288件) を見る
細かな点だけど、個人的に気になった部分が出てきたので書いてみる。
-サブアプリの付け替えが面倒: 毎回、特定の状況に合わせてサブアプリを付け替えるのが面倒かも。といっても、個人的には、よくつかうサブアプリセットみたいなのを登録できるようになってれば良かった。経験値稼ぎのときは、「エネミーコイコイ」を付けたセットになるだろうし、探索時には、「エネミーバイバイ(ララバイ)」を含むセットにしたい。
-フォルマをサーチするのが面倒: フォルマってサーチしたらまずいことが起こることってあるんだっけ? ないなら、いちいち、「サーチしますか」って確認なく、通過した時点で自動的に取得したことになってもよかったんじゃないのかな。
リンク
その他のコラムと連載の目次はこちら