Unityの教科書を終えたら、自分でゲームを更新してみよう ― 3つの更新タイプとGitのブランチで安全に試す
この記事は、北村愛実 著『Unityの教科書 Unity 6完全対応版』（SBクリエイティブ）のサンプルゲームを作り終えた方に向けた、ソフトライムの補足記事です。コードおよび制作手順の詳細は、書籍もあわせてご参照ください。
教科書のゲームを一通り作ると、「できた！」という達成感があります。でも、その次に何をすればいいのか迷う人は多いと思います。おすすめは、完成したゲームを自分で「更新」してみることです。この記事では、更新の考え方と、Gitのブランチを使って安全に試す方法をまとめます。
なぜ「更新」が力になるのか
教科書は「正解の作り方」を教えてくれます。一方、更新では「何を直したいか」「どう変えたいか」を自分で決めるところから始まります。決めるためには、まずゲームをよく観察して、コードがどう動いているかを自分の言葉で説明できる必要があります。これが、写して作るだけでは身につきにくい「理解」につながります。
仕事でも、プログラミングの多くは新規制作ではなく、すでにあるものの更新です。小さな更新を、計画して、試して、確認する。その練習としても役に立ちます。
更新の3つのタイプ
「何を更新すればいいか分からない」ときは、次の3つのどれに当てはまるか考えてみてください。
| タイプ | 意味 | 考えるときの問い |
|---|---|---|
| A 機能追加 | 遊びや表示を増やす | 遊ぶ人は、ほかに何が見たい・したいだろう？ |
| B 弱点の修正 | 変な動きや困る場面を直す | どんな操作をすると、おかしくなるだろう？ |
| C 書き換え | 動きは同じまま、書き方を良くする | 数字や名前を変えたいとき、何か所直す必要があるだろう？ |
難しさの目安は、まず簡単なものを1つ、そのあと少し考える必要があるものを1つ、の順がおすすめです。「書き換え(C)」は動きが変わらないので地味ですが、コードの意味を理解していないとできません。
ゲームごとの「考えてみよう」
完成したゲームを、もう一度遊んでみてください。そのうえで、次の問いに答えられるか試してみましょう。答えが分かったら、それがそのまま更新のヒントになります。
| ゲーム | 考えてみよう | 更新案の例 |
|---|---|---|
| 第3章 ルーレット | 止まったとき、何が当たったか分かる？／回っている最中にクリックするとどうなる？ | 回し始めの速さをランダムにする／止まった角度から結果を表示する／回っている間はクリックを無視する |
| 第4章 SwipeCar | 画面の大きさが変わっても同じ強さで飛ぶ？／旗を通り過ぎたら距離の表示はどうなる？ | ゴールの表示を出す／リトライボタンを付ける／スワイプの長さを画面の幅との割合にする |
| 第5章 CatEscape(②) | HPが0になったらどうなる？／猫を動かし続けるとどこまで行ける？ | ゲームオーバーの表示を出す／時間とともに矢を速くする／猫が画面の外に出ないようにする／よけた矢の数をスコアとして表示する |
| 第6章 ClimbCloud(②) | 落ちてしまったとき、どこから再開する？／上に登るとき、ジャンプをいつ使うと安全？／クリアしたとき、どれくらいの時間で登れたか分かる？ | クリアまでのタイムを表示する／スペースキーでもジャンプできるようにする／落ちた回数を数えて表示する |
| 第7章 Igaguri(②) | たくさん撃つと、ヒエラルキーのオブジェクトはどうなる？／的に当たったことを、プログラムはどう知る？ | 当てたら得点が入るようにする／撃てる数を決めて残り数を表示する／的を左右に動かす |
| 第8章 AppleCatch(②) | 毎フレームやっている処理に、無駄はない？／難しさの数字を変えたいとき、何か所直す？／終わったあと、何が起きてほしい？ | ハイスコアを保存する／点数の高い金のリンゴを出す／終了後に結果画面へ移る |
ここに載せたのは一例です。遊んでいて気になったことは、全部が更新のネタになります。
表の「ゲーム」の列のリンク先には、「もう一歩」という節がある記事もあります。そこに、更新案の答えの一例が載っていることもあります。先に自分で考えてから、答え合わせに使ってください。
Gitのブランチで、安全に試す
更新するとき、元の完成版を壊してしまうのは避けたいところです。そこで、完成したプロジェクトでGit管理を始め、更新はブランチで作る方法をおすすめします。GitHub Desktopの基本操作が分かれば、すぐにできます。
- 完成したプロジェクトのフォルダでリポジトリを作る。
.gitignoreはUnity用を選ぶ(GitHub Desktopの作成画面で選べます) - 「完成版(教科書どおり)」というメッセージでコミットする。これが元に戻れる出発点になる
- 更新用のブランチを作る。名前は
update/ch5-gameoverのように、章と内容を入れる - そのブランチで、小さくコミットしながら更新を進める(1つの機能や修正につき1コミットが目安)
- 履歴の画面で差分を見て、思ったとおりに変えられたか確認する
- 満足したら、元のブランチ(
main)にマージする。別の案を試すときは、mainから新しいブランチを作る
ブランチを分けておけば、うまくいかなかったときはそのブランチを捨てるだけで、完成版に戻れます。「失敗しても大丈夫」と思えると、思い切った更新ができます。
Unityで気をつけること
- GitHubに公開しない。書籍のサンプルは、掲載されたままの複写・転載が禁止されています。リポジトリは、自分のパソコンの中だけ、またはPrivate(非公開)にしてください
.metaファイルも一緒にコミットする。外してしまうと、別のパソコンで開いたときにスクリプトの設定が外れることがありますLibraryやTempフォルダはコミットしない。Unity用の.gitignoreが除外してくれます- 1つのブランチでは、1つのテーマだけ更新する。シーンのファイルは、複数の更新が混ざると、あとで直しにくくなります
※GitHub Desktopの画面の表示は、バージョンによって少し違う場合があります。
分からないときの調べ方
更新に必要なことを、自分で調べるのはとてもいいことです。この記事や教科書以外を使っても構いません。ただし、Unityは古い情報も多いので、次のことに気をつけてください。
- まず公式ドキュメント(UnityのManualとScripting API)を見る。ページのバージョンがUnity 6系か確かめる
- ネットや動画の情報は、古いバージョンのものが多い。そのまま貼ってエラーになったら、まずバージョンの違いを疑う
- 見つけたコードは、そのまま貼らず、1行ずつ自分の言葉で説明してから使う
- AIに聞くときは、コードを書かせるより、「この行は何をしているか」「エラーの意味は何か」を聞く。AIの答えも、公式ドキュメントで確かめる
調べたことを「自分の言葉で説明できるか」が、理解できたかどうかの目安になります。
更新の前に、計画メモを書こう
いきなりコードを書き始める前に、次の5つを短く書いておくと、迷いにくくなります。
- 気づいたこと(動かして、変だと思った点や足したい点)
- 更新のタイプ(A・B・Cのどれか)
- 何をどう変えるか、一文で
- どこを変えるか(どのスクリプトやオブジェクトか)
- どう確認するか(何を操作して、何が起きれば成功か)
終わったあとに、メモと実際にやったことを見比べてみてください。違った部分が、いちばん勉強になります。
まとめ
- 教科書のゲームを作り終えたら、自分で「更新」してみると理解が深まる
- 更新は「機能追加」「弱点の修正」「書き換え」の3タイプで考える
- 完成版でGit管理を始め、更新はブランチで試すと、失敗しても戻れる
- サンプルをGitHubに公開しない。ローカルかPrivateで管理する
- 更新の前に、計画メモを書いてから作る
- 分からないときは、公式ドキュメントで、Unity 6向けの情報か確かめて調べる
小さな更新を1つ終えるたびに、「自分でゲームを変えられた」という手応えが増えていきます。ぜひ、気になったところから試してみてください。
参考書籍
北村愛実 著『Unityの教科書 Unity 6完全対応版』（SBクリエイティブ）