PSPのペルソナやってます。エキスパートで9時間ほどやってレベル31。PSバージョンは、昔やったけどほとんど覚えてない。
ということで、気になった部分をいくつか。
・オサレヴォーカルBGMが世界観とミスマッチ: ペルソナ3or4っぽいヴォーカルBGMがゲームの雰囲気とかなり合ってないような気がした。
あとはインタフェース関連の不満。
・バトルでコマンドを選択できるまで待ち時間がある: バトルでコマンドを選択する時に、サクサクっと次のコマンドを選択できず、少し待ち時間があるのが残念。この点が一番気になっている部分。
・バトル中の演出のスキップをもう少しできるように: 演出スキップできるのは良いとしても、もう少しスキップできるようにして快適にできた気がした。
最後は、些細なことだけど個人的に気になった部分。
・スクロールでカーソルが一番上の時に上押しても下に移動しない: アイテム選択時に、スクロールの一番上にカーソルがある時に、上ボタンを押すと、一番下に移動して欲しかった。
・キャンセルボタンでメッセージ送りできない: キャンセルボタンでも決定ボタンと同じように、次のメッセージになるようにして欲しかった。
ということで、気になった部分をいくつか。
・オサレヴォーカルBGMが世界観とミスマッチ: ペルソナ3or4っぽいヴォーカルBGMがゲームの雰囲気とかなり合ってないような気がした。
あとはインタフェース関連の不満。
・バトルでコマンドを選択できるまで待ち時間がある: バトルでコマンドを選択する時に、サクサクっと次のコマンドを選択できず、少し待ち時間があるのが残念。この点が一番気になっている部分。
・バトル中の演出のスキップをもう少しできるように: 演出スキップできるのは良いとしても、もう少しスキップできるようにして快適にできた気がした。
最後は、些細なことだけど個人的に気になった部分。
・スクロールでカーソルが一番上の時に上押しても下に移動しない: アイテム選択時に、スクロールの一番上にカーソルがある時に、上ボタンを押すと、一番下に移動して欲しかった。
・キャンセルボタンでメッセージ送りできない: キャンセルボタンでも決定ボタンと同じように、次のメッセージになるようにして欲しかった。
PR
セブンスドラゴンのゲームレビュー分析のドキュメントを更新しました(ここで報告しなくても日々更新してします)。
セブンスドラゴンのレビュー分析(odsファイル, pdfファイル)
PDFで出力するようにしました。odsファイルを開くにはOpenOfficeをインストールしてください。
セブンスドラゴンのレビュー分析(odsファイル, pdfファイル)
PDFで出力するようにしました。odsファイルを開くにはOpenOfficeをインストールしてください。
更新履歴
2009/4/26: odsファイルだけでなく、pdfファイルも用意しました。ダウンロードしてください。
-----
一年以上前から、mk2さん(たとえばndsmk2さん)に投稿されたゲームレビューを分析しています。分析の目的は、プレイヤーの不満から、ゲームデザインの原則を特定することです。成果は、以下のドキュメントにまとめてます。
さて、分析をするにあたって、内部的なドキュメントを書いているのですが、一部を公開していくことしました。とりあえず、最近の分析対象であった『セブンスドラゴン』のドキュメントを公開します。
OpenOfficeのファイルで管理していているので、OpenOfficeのインストールが必要です。
まだあまり有益な情報が含まれていないと思いますが、自由に参考にしていただいてかまいません。
実はこれ以外のドキュメントも使って分析しているのですが、投稿されたレビューを原文のまま使っているので、こちらは公開できません(公開できるのかどうかわかりません)。
2009/4/26: odsファイルだけでなく、pdfファイルも用意しました。ダウンロードしてください。
-----
一年以上前から、mk2さん(たとえばndsmk2さん)に投稿されたゲームレビューを分析しています。分析の目的は、プレイヤーの不満から、ゲームデザインの原則を特定することです。成果は、以下のドキュメントにまとめてます。
ゲームレビューから学ぶゲームデザインの原則
さて、分析をするにあたって、内部的なドキュメントを書いているのですが、一部を公開していくことしました。とりあえず、最近の分析対象であった『セブンスドラゴン』のドキュメントを公開します。
セブンスドラゴンのレビュー分析(odsファイル)
OpenOfficeのファイルで管理していているので、OpenOfficeのインストールが必要です。
まだあまり有益な情報が含まれていないと思いますが、自由に参考にしていただいてかまいません。
実はこれ以外のドキュメントも使って分析しているのですが、投稿されたレビューを原文のまま使っているので、こちらは公開できません(公開できるのかどうかわかりません)。
今まで、ゲームデザインについての定義や特徴付けを行ってきた。今回記事は、もっと根本的な、以下の疑問に答えてみたい。
コンピュータ(or ビデオ)ゲームとは何か?
より具体的には、
コンピュータゲームとは少なくとも何か?
という観点から考えてみたい。
得られた回答を基に、コンピュータゲームのデザインについての定義も再考する。
まず言えるのは、コンピュータゲームというのは、プロセスではなくプロダクトであるということである。別の言い方をするなら、コンピュータゲームは、人工物の一種である。
人工物とは、ある目的を達成するために作られたモノである。たとえば、ゴミ箱は、ゴミを入れておくためのものである。
コンピュータゲームとは、人を楽しませたり、面白くさせるためのものである。
このコンピュータゲームの定義では、不十分である。たとえば、人と人が向かい合って行うような将棋やチェスをコンピュータゲームとして分類してしまう。そこで、コンピュータゲームをソフトウェアの一種としてさらに分類する。
ここでは、デザインを「達成したい目的の集合」を満たすような機能を備える「人工物」を作るプロセスとして定義する。この定義は、従来のデザインの定義より広い意味で使っているため、受け入れにくいかもしれない。
次に、ソフトウェアのデザインについて考える。上の図と同様の考え方をするなら、ソフトウェアのデザインは次の図になる。
しかし、この図は、実際に我々がソフトウェアを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ソフトウェアは、ソースコードをコンパイルするようなプロセスを含む。この場合、コンパイルのプロセスをソフトウェアデザインのプロセスの一部と見なしてしまう。
ここでは、コンパイルのようなプロセスをソフトウェアデザインのプロセスの一部でないと見なす。一部であるかどうかの基準は、ここでは、「達成したい目的の集合」を満たす「ソフトウェア」を作るにあたって、設計者の介入が必要かどうかであるとする。
この基準に従えば、コンパイルは、ソフトウェアデザインのプロセスの一部でない。なぜなら、このプロセスは設計者が介入しないからである。
改良した図は以下のようになる。
次に、コンピュータゲームデザインを考える。上の改良したソフトウェアデザインの図と同様の考え方をするなら、コンピュータゲームのデザインは次の図になる。
しかし、この図は、実際に我々がコンピュータゲームを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ゲームプログラミングを、コンピュータゲーム用のソースコードを出力するプロセスであるとすると、ゲームプログラミングは、コンピュータゲームデザインのプロセスの一部となる。しかし、通常、プロダクトとしてのコンピュータゲームデザインを示すとき、ソースコードorより正確には、プログラムがどのように構成されているかは気にしない。たとえば、変数がどのように命名されているかどうかは、関係がない。
したがって、ここでは、コンピュータゲームデザインを二つのプロセスに分割する。分割前のプロセスを「コンピュータゲームソフトウェアデザイン」と呼ぶ。
二つのプロセスをそれぞれ「コンピュータゲームデザイン」と「コンピュータゲームプログラミング」と呼ぶ。
この二つのプロセスの間に存在するプロダクトを「コンピュータゲームデザイン」と呼ぶ。
コンピュータゲームデザインとは、人を楽しませたり、面白くさせるという目的を達成するために必要であるとして決定した事柄の集合である。
コンピュータ(or ビデオ)ゲームとは何か?
より具体的には、
コンピュータゲームとは少なくとも何か?
という観点から考えてみたい。
得られた回答を基に、コンピュータゲームのデザインについての定義も再考する。
コンピュータゲームとは何か?
まず言えるのは、コンピュータゲームというのは、プロセスではなくプロダクトであるということである。別の言い方をするなら、コンピュータゲームは、人工物の一種である。
人工物とは、ある目的を達成するために作られたモノである。たとえば、ゴミ箱は、ゴミを入れておくためのものである。
コンピュータゲームとは、人を楽しませたり、面白くさせるためのものである。
このコンピュータゲームの定義では、不十分である。たとえば、人と人が向かい合って行うような将棋やチェスをコンピュータゲームとして分類してしまう。そこで、コンピュータゲームをソフトウェアの一種としてさらに分類する。
コンピュータゲームのデザインとは何か?
人工物、ソフトウェア、コンピュータゲームの分類を基に、次に、デザイン(のプロセス)について考えたい。ここでは、デザインを「達成したい目的の集合」を満たすような機能を備える「人工物」を作るプロセスとして定義する。この定義は、従来のデザインの定義より広い意味で使っているため、受け入れにくいかもしれない。
次に、ソフトウェアのデザインについて考える。上の図と同様の考え方をするなら、ソフトウェアのデザインは次の図になる。
しかし、この図は、実際に我々がソフトウェアを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ソフトウェアは、ソースコードをコンパイルするようなプロセスを含む。この場合、コンパイルのプロセスをソフトウェアデザインのプロセスの一部と見なしてしまう。
ここでは、コンパイルのようなプロセスをソフトウェアデザインのプロセスの一部でないと見なす。一部であるかどうかの基準は、ここでは、「達成したい目的の集合」を満たす「ソフトウェア」を作るにあたって、設計者の介入が必要かどうかであるとする。
この基準に従えば、コンパイルは、ソフトウェアデザインのプロセスの一部でない。なぜなら、このプロセスは設計者が介入しないからである。
改良した図は以下のようになる。
次に、コンピュータゲームデザインを考える。上の改良したソフトウェアデザインの図と同様の考え方をするなら、コンピュータゲームのデザインは次の図になる。
しかし、この図は、実際に我々がコンピュータゲームを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ゲームプログラミングを、コンピュータゲーム用のソースコードを出力するプロセスであるとすると、ゲームプログラミングは、コンピュータゲームデザインのプロセスの一部となる。しかし、通常、プロダクトとしてのコンピュータゲームデザインを示すとき、ソースコードorより正確には、プログラムがどのように構成されているかは気にしない。たとえば、変数がどのように命名されているかどうかは、関係がない。
したがって、ここでは、コンピュータゲームデザインを二つのプロセスに分割する。分割前のプロセスを「コンピュータゲームソフトウェアデザイン」と呼ぶ。
二つのプロセスをそれぞれ「コンピュータゲームデザイン」と「コンピュータゲームプログラミング」と呼ぶ。
この二つのプロセスの間に存在するプロダクトを「コンピュータゲームデザイン」と呼ぶ。
コンピュータゲームデザインとは、人を楽しませたり、面白くさせるという目的を達成するために必要であるとして決定した事柄の集合である。
この前書いた「ゲームデザインの構造に対する制約」の内容を修正して、「ゲームデザインの理論」のドキュメントに追加しました。