2009-10-22

ゲームレビュー分析：真・女神転生 STRANGE JOURNEY

ゲームレビュー分析

ゲームレビューの分析を更新しました。更新したのは、アトラスからNDSで発売されたRPGの『真・女神転生 STRANGE JOURNEY』です。以下のページで分析結果を見れます。

ゲームに関するユーザレビュー調査
- htmlで見る
- pdfで見る

ndsmk2に投稿された17件のレビューを分析した途中経過の調査報告となります。まずは、悪い点/要望点を分析しています。

真・女神転生 STRANGE JOURNEY(ストレンジ・ジャーニー)

出版社/メーカー: アトラス
発売日: 2009/10/08
メディア: Video Game
購入: 19人クリック: 708回
この商品を含むブログ (288件) を見る

2009-10-21

ソフトウェアとしてのゲームの進化と保守　その２：ゲームユーザの視点

ゲーム開発ゲームソフトウェア進化

前回のエントリでは、ソフトウェアとしてのゲームの進化と保守が今後の課題になるかもしれないことを述べた。

課題が生じる条件あるいは前提には、以下の3つがあると考えた（前回から少し修正している）。

(前提1) ゲームユーザの視点：ゲームユーザは、購入したゲームに対して、その後の更新を要求/期待する
(前提2) ゲーム開発者の視点：ゲーム開発者は、ユーザの更新要求/期待に対応する動機がある
(前提3) ゲーム市場の視点：一度発売したゲームを継続的に更新していくことが今後の傾向になる

下記の図は、これら前提の関係を示している。

ここで、いわゆるシリーズもの（たとえば、ドラクエシリーズ）の話ではないことに注意して欲しい。つまり、この図でいえば、以下のような話ではない。

「ゲーム」：ドラクエ1
1つ目の「期待するゲーム」：ドラクエ2
1つ目の「更新されたゲーム」：ドラクエ2
2つ目の「期待するゲーム」：ドラクエ3
2つ目の「更新されたゲーム」：ドラクエ3

今後、シリーズものや移植との関係についても考えていくが、現状では対象外としている。

このエントリでは、一つ目の前提について考えたい。下記の図は、この前提を示している。

あるユーザはあるゲームをプレイする。プレイの結果として、様々な期待する更新要素を持つ。ユーザは、そのゲームが、自身の期待するような要素により更新されることを期待する。
なお、ここではまだ、ゲーム自体がユーザの期待に応じて実際に更新されていないことに注意して欲しい。ユーザは更新を望むだけである。

下記の図は、具体例を示している。

この例では、ゲームAをプレイする二人のユーザがいるとしている。各ユーザは、それぞれ異なる期待を持つ。したがって、各ユーザが期待する更新後のゲームもそれぞれ異なる。もちろん、実際には、ユーザ間で共通の期待が存在することもある。

ユーザが更新を望まないかもしれない理由には以下が考えられる。

(1) 嗜好の衝突：　各ユーザが期待する要素間、あるいは、期待要素と既存要素の間で好みの衝突が発生する場合がある。たとえば、あるスキルをあるユーザは「もっと強く」と望み、あるユーザは「もっと弱く」と望むかもしれない。さらには、そのスキルを「更新しないこと」を期待するユーザがいるかもしれない。

(2) プレイ体験共有の妨げ：　ゲームを楽しくさせる要因の一つには、各ユーザが同じゲームをプレイし、そのゲームについての体験を互いに語ったり、情報交換・共有することにあるかもしれない。ゲームの更新は、「更新前のゲーム」と「更新後のゲーム」を生み出すことになる。このことは、「同じゲームを楽しむ」という行為の妨げとなるかもしれない。

ユーザが更新をどれだけ受け入れるかは、ゲームの形態や更新の種類に依存するかもしれない。

(a) ゲームの形態： たとえば、MMORPGなどでは、「(1) 嗜好の衝突」が起こるとしても、ユーザは更新を受け入れるかもしれない。

(b) 更新の種類： たとえば、「バグ修正」による更新は、ゲームの形態やジャンルに関わらず「(1) 嗜好の衝突」が発生しにくく、「(2) プレイ体験共有の妨げ」になることも少ないと思われる。他には、たとえば、「クリア後のダンジョンの追加」では、同様に、「(1) 嗜好の衝突」が発生しにくく、「(2) プレイ体験共有の妨げ」になることも少ないかもしれない。

次回は、ゲーム開発者の視点から考えてみたい。

リンク

その他のコラムと連載の目次はこちら

2009-10-19

プレイシナリオによるゲーム制作について考えてみる　その２：プレイシナリオのモデル

ゲーム制作プレイシナリオ

以前のエントリで、プレイシナリオというコンセプトを用いて、ゲームを制作する手法について考えた。

このエントリでは、プレイシナリオというコンセプトをもう少し明確にしたい。

なお、これらエントリのまとめは、こちらのドキュメントに随時反映していく予定である。

プレイシナリオとは

これまでは、プレイシナリオというのを「ゲームプレイにおいて、プレイヤーが設定するあるゴールを達成するための特定のアクション（動作）の流れ」であると定義してきた。
あるゴールは、いくつかのサブゴールで構成されていてもかまわず、同様にあるアクションは、いくつかのサブアクションで構成されていてもよい。

たとえば、RPGでは、次のようなプレイシナリオがあると考えられる。

レベル上げ：　あるボスを倒すため（ゴール）に、レベルを一つ上げる（サブゴール）。ダンジョンを歩き（アクション）、敵を倒す（アクション）。
お金をためる：　ある武器を買うため（ゴール）に、500Ｇの金稼ぎを行う（サブゴール）。手持ちの不要となったアイテムを売る（アクション）。

プレイシナリオとは、別の表現をするなら、ゲームプレイの一部を切り取ったものであると言える。

プレイヤーは、プレイ時にゲームに対するさまざまな不満を持つ。ある不満は、あるプレイシナリオにおいて生じる。
たとえば、プレイシナリオ例の「お金をためる」では、プレイヤーは「アイテムをまとめ売りできない」ということに対して不満を持つかもしれない。

どのようなゲームプレイが可能かは、プレイヤーがプレイするゲームにより制約される。

プレイシナリオを用いてゲームを制作するとは、

(1) プレイシナリオとそのシナリオで生じる可能性のある不満をペアとして明示的に記述し、
(2) その記述をゲームデザインの評価・改善のために利用する

ことを意味する。

プレイシナリオ記述の必要性は、以下の二つの前提に基づく。

(前提1) ゲームは複雑な人工物となってきており、今後もより複雑になる可能性がある。
(前提2) どのようなプレイシナリオが生成されるかは、個々のプレイヤーに依存する。

このため、ゲームデザイナーは以下の問題を抱えることになる。

プレイヤーが不満を持つかもしれない全てのプレイシナリオを想像することは困難である。

結果として、ゲームには潜在的な欠点が残ってしまう可能性がある。

また、プレイシナリオ記述の有用性は、以下の前提に基づく。

(前提3) 全てのゲームがユニークなわけではない。ゲーム間には、共通部分がある。共通部分は、類似したプレイシナリオおよびそのシナリオでのプレイヤーの不満を生成する。

そのため、あるゲームから得られたプレイシナリオ記述は、新規制作するゲームにおいて再利用できると考えられる。

まとめると、プレイシナリオによるゲーム制作手法では、プレイシナリオを明示的に記述・収集・カタログ化することで、ゲームデザイナーの想像力を支援することを意図している。想像力の支援は、以下の利点をもたらす可能性がある。

(a) デザインの手戻りのコスト削減：　テストプレイヤーからのフィードバックによるデザインの手戻りコストを削減できる。

(b) クリエイティブな思考時間の増加：　プレイシナリオ記述に書かれるのは、既に分かっているシナリオとそのシナリオでの不満点である。プレイシナリオ記述の利用は、このようなルーチン的なデザイン上の欠点を特定・修正することを意味する。ルーチン的作業を効率的に行えるようにすることで、ゲームのクリエイティブな側面の思考により多くの時間を費やすことができる。

リンク

その他のコラムと連載の目次はこちら

2009-10-16

ソフトウェアとしてのゲームの進化と保守

ゲーム開発ゲームソフトウェア進化

2009年10月13日以前に「GRADIUS ReBirth」を受信されたお客様へ
2008年9月2日（火）に配信いたしました、Wiiウェアソフト「GRADIUS ReBirth」につきまして、ゲーム内容の一部を変更した更新版を2009年10月13日に配信いたしました。
つきましては、2009年10月13日以前に当ソフトを受信されたお客さまには更新版「GRADIUS ReBirth」を再受信いただきますようお願いいたします。
【修正内容項目】
・BGMの追加
・スコア調整
・上記スコア調整による、新ランキングボードの設置
・画面演出の強化
・プレイ周回の画面表示
・ステージセレクトの調整（4〜30周の選択が可能）
GRADIUS ReBirth

なお、更新版「GRADIUS ReBirth」の再受信は無償とのこと。

GRADIUS ReBirthは、プレイしたことないけれど、これを読んでいくつか疑問が出てきた。

(1) ゲームユーザは、購入したゲームに対して、その後の更新を要求/期待するか？
(2) ゲームメーカーは、ユーザ要求/期待に対応する動機があるか？
(3) 一度発売したゲームを継続的に更新していくことが今後の傾向になるのか？

ゲームではない分野であれば、このような条件は多くの場合満たされる。普段利用しているアプリケーソン（たとえばWebブラウザ）やIT系のソフトウェアは、ユーザの要求に対応している。

ゲームの分野でも、もちろん、MMORPGなどは、条件を満たす。また、パッケージゲームであっても、ネットワークを介して、更新（アップデート）が行われる。たとえば、PS3の『白騎士物語』では、2008年12月25日に発売後も、2009年1月29日にバージョン1.03へのアップデートが行われ、現在、8月25日のアップデート「2nd. WAVE」が配信されている。

まずは、上記の個々の条件の検討をゲームを対象に行う必要がある。しかし、もし、このような条件が多くのジャンルや個々のゲームで満たされるなら、以下が課題になる。

ゲームメーカーは、出来る限り、低コストかつ素早くゲームを更新できる必要がある。

つまり、多くの場合、ユーザ要求に対応して、ソフトウェアとしてのゲームを更新（変更）するのは容易でないと考えられる。

ソフトウェア工学においては、ユーザ要求の変化、ソフトウェアを取り巻く環境の変化、あるいは、開発者の知識・経験の変化に対応することにより、ソフトウェアが変化していく過程の現象をソフトウェアの進化と呼ぶ。ソフトウェア進化の過程において、ソフトウェアの構造、つまりアーキテクチャやプログラムは、徐々に老化*1や劣化*2していくことが知られている。その結果として、変化に対応するのが困難になっていく。

今後のエントリでは、このソフトウェア進化の観点、つまり、ソフトウェアとしてゲームを捉えた場合の進化について考えていきたい。

従来の「ゲームの進化」というと、グラフィックが向上したとか、今までになかった斬新なシステムが導入されたとか、そういう観点の議論がされてきたと思う。ゲームのあるジャンルを対象に、そのジャンル内でどんなゲームが生まれ、淘汰されていったのかみたいな議論。

今後のエントリでは、そういう観点ではなく、ソフトウェアとしてのゲームの進化と保守を考えていきたい。

ゲームの進化の特性：　進化の要因にはどのようなものがあるのか。従来のアプリケーションソフトウェアと異なる特徴があるのかどうか。

ゲームの進化のさせ方：　従来のアプリケーションソフトウェアにおける進化の課題と対策がゲームに応用できるのかどうか。

続き

続きはこちら。

リンク

その他のコラムと連載の目次はこちら

*1:Software Aging, pdf

*2:Design Erosion: Problems & Causes, pdf

2009-10-15

ゲーム製品ファミリについて考えてみる　その２：一般的な話と課題について

ゲーム開発ゲーム製品ファミリ

前回のエントリでは、「ニーアゲシュタルト」と「ニーアレプリカント」の製品化を例に、ゲーム製品ファミリというコンセプトを考えた。前回は少し具体的な例の話だったけれど、このエントリでは、少し一般化した話として考えたい。また、課題についても少し考えてみたい。

ここでは、ゲーム製品ファミリとは、そのファミリ内で、共通となるゲーム要素と異なるゲーム要素を備えるゲームの集合であるとする。あるファミリに属するゲームをそのファミリのメンバーと呼ぶことにする。

上記の図は、二つのメンバーからなるゲーム製品ファミリを示している。この製品ファミリは、3つのゲーム要素の特定の組み合わせからなるゲームで構成される。

メンバー1：「ゲーム要素A」と「ゲーム要素B」を備える。
メンバー2：「ゲーム要素A」と「ゲーム要素C」を備える。

ゲーム要素Aは、メンバー間で共通となるような要素である。一方で、ゲーム要素BやCは、各メンバーの固有な部分を表す要素である。

ニーアゲシュタルトとニーアレプリカントの場合は、主人公キャラクターというゲーム要素が異なる要素である（らしい）。

ニーアゲシュタルトの場合は、主人公が父親（おっさん）
ニーアレプリカントの場合は、主人公が兄（イケメン）

ゲーム製品ファミリ開発の主な動機は、ユーザの多様な嗜好に対応することにある。「萌え要素があれば（なければ）購入したのに」、「こんなやりこみ要素はいらないからその分安くしてくれたら購入したのに」、「クリア後も遊びたいから、ちょっと高くても隠しダンジョンがいっぱいあるこっちを買う」など。

ニーアゲシュタルトとニーアレプリカントの場合は、主人公が異なるのは、海外市場での受け入れられるかを考慮してとのこと。

主人公がおっさんなニーアゲシュタルトは、海外ユーザ向けに、
主人公がイケメンなニーアレプリカントは、日本ユーザ向けに

ゲーム製品ファミリの開発の大まかなステップは次のようになると考えられる。

(1) ユーザの嗜好の多様性の分析
(2) 分析にもとづく、ゲームの共通部分と異なる部分の定義
(3) 定義にもとづく、ゲーム製品ファミリの開発・提供

各ステップで様々な課題があると思う。どのステップとは限定できないけれど、たとえば、次のようなものが考えられる。

ゲーム要素への分割容易性：　もちろん、いうほど簡単ではないと思うけれど、主人公のグラフィックだけが異なる、というのは、要素への分割対象としては容易だと思う。なぜなら、他のゲーム要素との関わりが小さいと思われるし、ゲーム性へは影響は少ないと思われるから。一方で、たとえば、RPGでの「敵とのエンカウント方式」というものを考えてみると、難しさが分かる。「ランダムエンカウント」をゲーム要素として持つメンバーと「シンボルエンカウント」を持つメンバーでは、他のゲーム要素への影響が大きいことが分かる。たとえば、フィールドやダンジョンのゲーム要素、つまり、それらの設計に影響を与える。「ランダムエンカウント」に適したダンジョンは、「シンボルエンカウント」には適していないかもしれない。

テストプレイのコスト：　同じく「敵とのエンカウント方式」で考えてみると、エンカウントの仕方はゲームプレイの過程に影響する。テストプレイ時には、単に「シンボルエンカウント」や「ランダムエンカウント」が機能しているかどうかの確認だけでなく、ゲームプレイ全体を通してのゲーム性やバランスといった観点からの調整が必要になる。つまり、メンバーとして他と異なるゲーム要素（エンカウント方式）だけをテストすればいいのではなく、他の要素との関わりを含めた、ゲーム全体としてのプレイテストが必要になる。

次回もまた課題について考えてみたい。

リンク

その他のコラムと連載の目次はこちら

2009-10-13

SIG-Indie 第4回研究会の個人的まとめ

XNA SIG-Indie インディーゲーム

10/10日に行われた、SIG-Indie 第4回研究会「Xbox360向けゲーム開発環境XNAにまつわるインディーズゲームシーン」に参加してきました。懇親会と二次会も参加。色々学ぶことがあったし交流もできたので参加して良かったです。

当日の様子なんかは、以下が参考になるかと。

まとめはこちら。

このエントリでは、XNAを取り巻く課題の全体像を少し理解したいな、ということで、個人的に少しまとめてみた。

具体的には、id:yara_naikaのエントリを参考に課題的なものを抜き出して、次のような図を作ってみた。

図の方が分かりやすいかどうかは不明だけど。
XNAプラットフォームの部分はややうそくさい。勘違いしてるかも。間違った部分や抜けてる部分の指摘があれば修正します。

あと、id:ABAさんのエントリでは、図に載せてない課題がいくつか紹介されているで参照してほしい。

SIG-Indie XNA研究会無事終了、けど語り足りない部分も多かった

本当は、XNAのエコシステムというネタで書き始めたんだけど、図だけ書いて力尽きた。続きでエコシステムのネタで書くかも。

2009-10-12

プレイシナリオによるゲーム制作について考えてみる

ゲーム制作プレイシナリオ

以前のエントリで、プレイシナリオというコンセプトについて少し触れた。

プレイシナリオを使ってテストプレイをする

このエントリでは、プレイシナリオというコンセプトを用いて、ゲームを制作する方法について考えてみたい。

プレイシナリオというのは、「ゲームプレイにおいてあるゴールを達成するための特定のアクション（動作）の流れである」と定義している。たとえば、RPGでいうと「経験値を稼ぐ」や「お金をためる」などのシナリオがあると考えている。

プレイシナリオは、ゲーム制作におけるデザイン工程とテスト工程で用いられることを想定している。これら工程におけるプレイシナリオの役割には、以下があると考えてる。

デザイン工程では、ゲームデザインの欠点の作りこみを避けること
テスト工程では、ゲームデザインの欠点を効率的に特定すること

基本的な前提としては、特定のプレイシナリオを想定することがゲームデザイナー/テスターの想像力を支援するのではないか、ということがある。

プレイシナリオによるゲーム制作の概要

下記の図を使ってもう少し詳しく説明したい。

このの図の上部と下部では、それぞれ次のことを示している。

(上部) このエントリでのゲーム制作工程の捉え方：かなり何となくな工程の分割の仕方だけど「企画」「デザイン」「プログラミング」「テスト」の４つの工程があると考えてる。もちろん、この捉え方が不適切な部分があるかとは思う。

(下部) このエントリの内容：このエントリが対象としてるのは、ゲーム制作工程でいうと「ゲームデザイン」のシナリオ、サウンド、グラフィックなど、ゲームの素材に関わらない部分と、「ゲームテスト」でのテストプレイの二つがある。プレイシナリオを用いて、これら工程での作業が行われること想定している。
- プレイシナリオを用いたゲームデザイン
- プレイシナリオを用いたテストプレイ

現状ではかなり曖昧な感じではあるけれど、こういう感じで考えていきたい。