キャプチャ01

2Dアクションゲーム「Mr.Flip」の制作記録

JUN

2020/2/24(月)～3/2(日)にunityroomで開催されるUnity 1週間ゲームジャムに参加しました。

今回は2Dアクションゲームを作りました。2Dアクションを作るのは初挑戦です。本記事では、その制作過程をゆるーく書きました。（noteで記事を書くのも初めてなので、ゆるーく見てもらえると幸いです。）

↓今回作ったゲームはこちらで遊べます

お題発表

2/24にnaichiさんから今回のお題が発表されました。

今回は「逆」です！
難しいけども、面白そうなお題ですなぁ。

アイデア出し

まずはどんなゲームを作るを考えます。
「逆、逆、逆・・・」とかいっていろいろ考えます。

画像1

画像2

画像3

いろいろアイデアを出し、3つ目の画像のアイデアがいいなぁということになりました。
「あるボタンを押すと、自分以外のオブジェクトを左右反転にする」というアイデアです。
しかし、途中で「あるボタンを押すと、プレイヤーだけが左右反転する」というのに変わりました。なんか前者のアイデアではゲームが面白くなりそうになかったんですね。

決まった仕様をまとめると、次のようになります。

・Shiftキーで左右反転（これを「フリップ」と呼ぶことにしました）
・方向キーで移動、Spaceキーでジャンプ
・プレイヤーをゴールまで移動させると、次のステージに遷移
・トゲにぶつかると、そのステージの最初からやり直し

自作の物理エンジンを作成

まずはプレイヤーを動かすところから作ります。そこで、自作の物理エンジンを作ることにしました。

Unity標準のPhysicsという物理エンジンは、現実と限りなく近い動きをさせたいのであれば、適していると思います。
しかし、非現実的な動きをさせたい場合は、自作の物理エンジンを作りたいですね。例えばスーパーマリオやスーパードンキーコングのような動きにしたいなら、質量とか反発係数みたいなパラメータは必要ないですよね。
で、僕がつくりたかったのは現実と限りなく近い動きをするゲームではなく、スーパーマリオのような動きをするゲームだったので、自作の物理エンジンを作ろうと思ったのです。

で、ググりました！
ググったところ、次のサイトが見つかりました。

Unity公式のチュートリアルです。
動画付きなのですが、残念ながら日本語字幕なし！
ですが、ソースコードは掲載されているし、英語だけどゆっくり喋ってくれているのでなんとか理解できました。

そして、そのコードをほぼ丸写しして、自作（？）物理エンジンが完成。
動かすと、次のような動きになりました。

「やった～～～、自分の絵が動いてる～～～！！」
自分の絵が自分の入力によって反応し動いたときって、ほんと嬉しいんですよね。

ただ、感動はあったものの、次のような理由でアクションゲームとしてはまだいまいちな動きでした。

・空中ですぐに進行方向が変えれてしまう
・空中で方向キーを離すと、すぐに止まってしまう

「空中ですぐに進行方向が変えれてしまう」というのは、例えば、右に時速5kmの速さで進んでいるときに左にスティックを倒すと、一瞬で左に時速5kmの速さで進んでしまうような動きだということです。
これだと、まるでUFOのような動きで、違和感しかないです。
（あと、思ったところに着地するのが簡単すぎてしまうというのも問題ですかね。スーパーマリオをやってて、思うような位置に落下できずクリボーを踏み外してしまうことがよくありますよね。あれが面白いんですよ。）

で、このような動きになってしまうのはさっきのコードの左右の移動に関する部分が次のようになっているからです。

move.x = Input.GetAxis ("Horizontal");

つまり、入力した方向が直接移動速度になっているんです。
これだとまずいということで、入力した方向に毎フレーム速度を加速させるように改造しました。次のようなコードです。

inputDir.x = Input.GetAxis("Horizontal");
velocity.x += inputDir.x * xSpeed;

さらにパラメータも調整し、最終的に次のような動きになりました。

この調整をするときに、かなり参考にしたのがCelesteというゲームの動きです。あのゲームで操作キャラを動かしているとき、とても心地よいと感じたので、とても参考にしました。とりあえずCelesteの動きを完コピして、その後に自分のゲームに合わせて微調整していくことにしました。

余談かもしれませんが、アクションゲームの心地よい操作については、この動画で取り上げられてます。（英語ですが、設定で日本語字幕が出せます）


絵を用意する

まだまだ駆け出しですが、僕はドット絵を描くドッターです。そして、アイデアを出す前から、自分のドット絵を使ってゲームを作るということは決めてました。

作るゲームが決まったら、必要な絵も決まりますね。
そのとき、「絶対に必要な絵」と「余裕があればあってほしい絵」に分けてリスト化しておくといいかもしれません。
絵を描くのに時間をかけすぎて、締め切りに遅れてしまうのを避けるためのunity1weekにおける戦略です。（締め切りに遅れてしまった私が言うと、あまりにも説得力がないですね）

実際リスト化してみると、次のようになります。

今回絶対に必要な絵のリスト

・プレイヤーの正面の絵
・プレイヤーの後ろ姿の絵　←フリップしたに背中を向いてほしいから
・プレイヤーの歩行アニメ
・ステージのマップタイル
・トゲ
・コイン

余裕があればあってほしい絵のリスト

・プレイヤーの待機アニメ
・フリップの最中の絵（正面の姿と後姿を補完する絵）
・ジャンプの上昇時・下降時の絵

画像4

フリップの実装

残りの左右反転（フリップ）の実装も済ませます。

ステージのデザインを考える

ゲームの基礎の部分はできたので、あとはチュートリアルとステージを考えるだけです。

僕がステージのデザインを考える時は、次のことを意識しました。

①プレイヤーにあること(A)を学習させるだけの簡単なステージを作る
　↓
②それ(A)を使ったもう少し難しいステージを作る
　↓
③プレイヤーに新たなる別のあること(B)を学習させるだけの簡単なステージを作る
　↓
④それ(B)を使ったもう少し難しいステージを作る
　↓
⑤AとBを使ったさらに難しいステージを作る

つまり、
Aの基礎→Aの応用→Bの基礎→Bの応用→AとBの応用→Cの基礎・・・
といった感じです。

例えば、ステージ１で「ジャンプ」という操作を学習させて、ステージ２でではジャンプを使ったより難しいステージに。ステージ３で「フリップ」という操作を学習させて、ステージ４でフリップを使ったより難しいステージ。そして、ステージ５でジャンプとフリップを使ったより難しいステージにするといった感じです。

これが繰り返されるようなステージにしたつもりです。
これが正しいかどうかは分かりませんが、マリオやCeleste、他多くのゲームでもこのような作りになっていて、僕はそれで面白いと思ったのでそうしました。

実はステージを考えるのにすごい時間がかかっちゃいました。それでもまだステージ数が全然少ないんですけどね・・・。
最後に音を付け、タイトル画面、エンディングを実装。
残念ながら2日遅刻してしまいましたが、なんとかゲームは完成しました。

この記事を読んだ後に遊ぶと違う意味で面白いかも。
Mr.Flipはパソコンから↓のリンク先で遊べます。

さいごに

制作過程であれば、面白がって見てくれる人が1人でもいるかなと思い、書いてみました。鼻ほじりながらでも面白がって見てくれた方がいれば嬉しいです。

これからも、何か自分にも発信・情報共有できることがあればしていこうと思います。
良かったらnoteのフォローお願いします。
それでは

この記事が気に入ったらサポートをしてみませんか？