ゲームのつくりかた　2020年3月13日 (Pixiv Fanbox)

　なんか書いた方がいいのかなみたいな感じをにわかに感じ取ったので，僕がゲームを作る手続きを一回だけ書こうと思います。だいたいどのゲームでも同じ作り方で作っています。かなり削ぎ落としていて実際にはもっと細かい区分があるのですが，おおむねこういう感じだよってことで。

1.原動力があるか確認する

　これは別になんでもよくて，「イベントがあるのでそれに出す」とか「ハマってるゲームとかアニメとかめちゃめちゃ好きなキャラとかを推す」とか「作りたいゲームの案が温まってきた気がするので形にする」とか，最後まで「それを理由に完走できること」が作り始めの時点で確実ならなんでもいいと思います。「ゲームを作りたい」ことそのものとか「お金が欲しい」みたいな理由でも最初はいいかもしれないんですけど，それは具体的な目標がなくてだいたい雲散霧消しがちなイメージがあるので，本当に最初だけかな～と思います。

　めちゃめちゃお金が好きな人だったらお金！！！！！　って思うことで完走できる可能性はありますが，そもそもゲームを作ることにお金がかかるので「これ本当に売れるんか？」みたいな気持ちになって鎮火するリスクなどがあると思います。そういう話だと急にキャラ萌えが冷めてやる気なくすとかは全然ありうるし，作りたいゲームがじつは作りたくなかったことに気づくとかもあるので，まあ……あれなんですけど。

2.おおざっぱなゲームの中身と，その着地点を決める

　ゲームの中身というのは，何するゲームかっていう話です。ボタンを押すと数字が増えるとか，ボタンを押したらへんな絵が出るとか，そういうざっくりしたレベルで決めます。

　着地点というのは，ゲームのボリュームとか開発の規模とかじゃなくて，つくってるゲームが行き着いたら何がどうなるのか？　です。「ゲームが最終的にプレイヤーの物になったとき，そのプレイヤーはどういう遊び方をしてどういう気持ちになってるのか」を決めるみたいな話です。ぼくのゲームってボリュームとかはその場その場で決めて適当に作ってるんですが（だいたい納期が理由で間に合うように作ります），でもゲーム的な軸はさいしょに考えてることが多いので「何を作りたかったのか」という点だけはある程度ハッキリしてるんじゃないかなと思います。もうすでに書くことなくて飽きてきたな～

3.とりあえず画面に何を置くか決める

　プレイヤーがゲーム中に見る画面がどういう構図になるのかをてきとうにスケッチします，最初に画面に置くものを最低限決めておかないと数字とかが画面にごちゃごちゃ無秩序に表示されたりして，何がなんだかわからない，いかにも素人臭い画面になったりしてしまうからです。

　最初の段階で「これは必要なはず」って決めた情報の意図は基本的に削られることはあんまりないと思います。情報の意図というのは，「何のためにそれを表示したいのか」ということです。

　（追記）画面を作る際なのですが，なんもまっさらな状態から生み出すのはめちゃくちゃ大変なので，「あのゲームっぽい画面つくろ」とか「このゲームジャンルならこういう画面にしとけばいいっしょ」みたいな感じでやるのがまずは手っ取り早いと思います。ずっとやってるうちに方法論みたいなのが身についてきて，引き出しをひっくり返してゲーム画面作るのがすごいスムースになってくると思います。

4.画面を作って動かしてみる

　この段階ではまだ計算式とかが走ってる必要はなくて，メニューの行き来が思った通りにできるかとか，最初に決めたとおりに画面を表示してみて変にならないかとかを見ます，思い通りにいくことはだいたいなくて，このタイミングでゲームっぽく見せるために結構直しが入ることになります。

　そのためスケッチの段階と見比べたとき，最低限の構図だけは似てるけど表示物が全部変わるとかはよくあります。画面を作ったら嘘スクショが貼れるようになるので，まったく何一つできてなくてもとりあえず「今作ってます！！」ってアピールできるようになります。

　（追記）このへんでもう技術的な話になってぜんぜんわからない！　ってなるかもしれないんですが，たとえばぼくが使ってるようなRPGツクール製とかのゲームなら，RPGツクールでがんがん覗きまくって構造をコピペして動かしたらめちゃめちゃ簡単にマネできますよ！　おすすめです。

5.ひたすら計算を入れまくる

　これが一番長くてだるいしあんま楽しくないです。メモ帳とかにずーっとやることを羅列してそれを実装しては横線引いていく作業が入ります。少しずつゲームの機能的な部分が組みあがる実感こそありますが，ぶっちゃけ4でやった画面を作って動かしてる状態と見た目的にはなんも変わらんので，だいたい嘘スクショを作ってから嘘スクショに実装を近づけるだけで半月とか一か月とか最近はかかります。困りますね。

6.とりあえず適当にゲームデータを入れてみる

　システムが入ったらゲームが機能としては遊べるはずなので，まずは適当に遊べるようになるデータをぶちこんでみます。結果的に面白い気がしたらそのまま進めばいいのですが，面白くならなかったら最悪ゲーム自体がなかったことになるので，できる限り「俺の発想は正しいはずでデータが間違ってるんだが……」みたいな言い訳をして機能をいじったり計算を治したりデータをよくしようとしてみたりします。しかしだいたい適当な数値を入れてもシステムが整っていればそれっぽくゲームは動くので，すでにほとんどダメな場合が多いです。どうしてもダメだったら諦めて1からやり直します。

　短編の場合，この「適当にゲームデータを入れた」時点でそこそこ遊べるので，もう終わりでいいやん♪となって終わるケースが少なくありません。1～2週間くらいでゲーム作るときはそういうことになりがちだと思います。

　↓てきとうに敵データを入れてる例

7.ゲームの流れに沿ってボリュームをガンガン足す

　ここまでの工程に問題がなければ本番の制作に移ります。スタート地点と着地点はあらかじめ決まっているはずなので，あとは適当にそれを分割してゲームっぽく仕上げます。システムはほとんど組みあがっているのでデータを適当にぶちこむといきなりステージが1個とか出来たりしてとっても楽しいところです。僕はかなり好きな部分です。

　ガンガン作っているうちに機能とか仕組みが足りなくなってきて，基本的には最初につくった仕組みを可能な限り流用して作っていく努力はするのですが，やはり適度にシステムに手を入れてどうのこうのする瞬間が出てきます。こういうのがだいたい締め切り間際とかに苦しめてくるのですが，でも「やろうっと♪」って決めたのは自分なので泣きながらやるしかありません。しかし本当に間に合わなかったり，ただの思い付きを実現する手間がバカらしかったり，単に技術的問題が解決しなかったりという理由で没になることもよくあります。

　制作中にあたらしい機能を入れたいとき，「そこまでする価値があるのかどうか」を自分に問うています。たとえ大変でも入れた方がゲームがよくなる，というのはすべての機能に共通することなのですが，とはいえその「よくなる」がどこまで独り善がりなのかということはもっと気を付けたいと思っています。

8.テストする

　神は7日間で世界を作ったとか言いますが，われわれは7工程でゲームができてしまいました。人間もなかなか捨てたもんじゃないな。というわけでテストをします，テストはゲームをより面白くするためにたいへん重要な工程で，開発期間と述べ工数が同じになるくらいのテストが必要だとぼくは思っています。

　ゲームのテストは「バグをぜったいに出してはいけない場所（たとえばエンディングとかの1回しか見ない場所）でバグが出ないようにチェックする」とか「遊びの振れ幅がどこまで許容されてるかいろんな人にむちゃくちゃな遊び方を試してもらう」とか「ちゃんと思った通りにゲームが進行するかバランスというまぼろしを確かめてもらう」みたいな要素があります。どれも同じくらい大事で，手抜きしたらなんかフワフワしたゲームになったり，大事なところでバグって感情が台無しになったり，作りたいものが伝わってこない，あるいは意図した通りに伝わってくれないゲームになることがあります。

　というような感じでだいたい作っています。かなり大雑把な概要で，細かいブラッシュアップの工程や，個々人のバックボーンの準じた具体的な思考の流れとかはできる限り排しているつもりなので，応用は効くんじゃないかと思っています。参考になったらみなさんもゲームつくりましょう！　ではまた！

youtube post: vyqw1TU7xzo

(YouTube)