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

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

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

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

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

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

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

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

◆視点を獲得するために

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

１．ゲームの分析をする

２．実際にゲームを作る

３．実物のゲームの仕様書を読む

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

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

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

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

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

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

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

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

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

あとアレだ。

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

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