どっちから見るか問題

ゲームを作る人になろう、とおもったら必要なモノはいくつもあるんですが、その中の1つに「作る側の視点」というのがあります。

◆自転車の乗り方みたいな

ゲームに限らず、それを作ろうとするときには「作る側の視点」ってのが必要になります。
1ユーザとしてではなくて、1開発者としてその「モノ」を見る視点。

プレイヤーなら、目に見えているパラメータ(と、わずかな隠しパラメータ)を気にしてプレイしていけばいいわけですが、開発者だと「それ以外の全部」を設計して組んでいかないといけないわけで。

そうすると、「プレイヤー視点」とは違ったゲームの見方が必要になります。

プレイヤーに透けて見えるレベルデザインはすぐに飽きられちゃうから、そこはプレイヤーの感情をうまくコントロールしながらゲームを進行させていく「仕組み」が必要になります。
それは「プレイヤーの視点」では設計しづらいモノです。

システムに寄ってみれば、ゲーム内の全パラメータを見て、いつどこで使うか、セーブするか、とかは開発者の考えで作らないといけない。
だって内部データ(プレイヤーIDとかアイテムのデータとか)を作るのは開発者側だから。
プレイヤーから見えない部分も含めて「ゲーム」なので、プレイヤー視点だけでは作れない、設計できない部分がどうしてもあります。

ゲーム開発者なら、両方持ってる方が良いし持ってるべき。

◆視点を獲得するために

で、どうやってその視点を得るか、になるわけですが、

1.ゲームの分析をする

2.実際にゲームを作る

3.実物のゲームの仕様書を読む

あたりになるのかなぁとおもっています。

自分がどうやったかを考えてみたところ、
最初は見よう見まねで作ってみて、先輩の作ったゲームや仕様書を見て「ここが足りない」とか考えて、また作る、って繰り返しだったように思います。

自分は運良く(タイミングと運だと思います)現場に行けたので、3,の「実際のゲームの仕様書を読む」ができて、これが成長するポイントだったかなとおもいます。

仕様書を読むといっても、その辺に転がってるモノではありませんし、商業ベースのものならNDAで外に出てくることはまずないです。

とすると、「ゲームの分析をする」か「作る」になるわけで。

どっちも回数繰り返すのがいいのかなぁ、と思っています。
で、コレやるときに大事なのが「(とりあえずでいいんで)最後までやる」ってだけ。

あと裏技的には「デバッグ(QA)のバイトをする」ってのもあります。

QAって「仕様書と実装を比較して、仕様通りに実装されているかを確認する」ことなので、つまり一部ですがホンモノの仕様書が見られます。

仕様書って、タイトルごとにデベロッパーごとに書き方が違います。
なので「正解」ってのはないんですけど、見る機会がほぼないものでもあります。なので、デバッグのバイトで仕様書(の一部)が見られるのは覚えておくと良いと思います。

あとアレだ。

ゲームが好きでそれなりの本数プレイしている、なのは必須条件てコトで。
ゲームってあくまで嗜好品なんで、好きじゃないと作りにくいとおもいます。ものすごくドライに「エンターテインメントを設計する」って方向もナシでは無いですが、やっぱゲーマーで開発者な気持ちとしては「好き」が最初にあってほしいなぁと。

1本、熱く語れるタイトルがあるといいですよねぇ。