Unityの教科書を終えたら、自分でゲームを更新してみよう ― 3つの更新タイプとGitのブランチで安全に試す

2026年10月7日

この記事は、北村愛実著『Unityの教科書 Unity 6完全対応版』（SBクリエイティブ）のサンプルゲームを作り終えた方に向けた、ソフトライムの補足記事です。コードおよび制作手順の詳細は、書籍もあわせてご参照ください。

教科書のゲームを一通り作ると、「できた！」という達成感があります。でも、その次に何をすればいいのか迷う人は多いと思います。おすすめは、完成したゲームを自分で「更新」してみることです。この記事では、更新の考え方と、Gitのブランチを使って安全に試す方法をまとめます。

1. なぜ「更新」が力になるのか
2. 更新の3つのタイプ
3. ゲームごとの「考えてみよう」
4. Gitのブランチで、安全に試す
- 4.1. Unityで気をつけること
5. 分からないときの調べ方
6. 更新の前に、計画メモを書こう
7. まとめ
8. 参考書籍

なぜ「更新」が力になるのか

教科書は「正解の作り方」を教えてくれます。一方、更新では「何を直したいか」「どう変えたいか」を自分で決めるところから始まります。決めるためには、まずゲームをよく観察して、コードがどう動いているかを自分の言葉で説明できる必要があります。これが、写して作るだけでは身につきにくい「理解」につながります。

仕事でも、プログラミングの多くは新規制作ではなく、すでにあるものの更新です。小さな更新を、計画して、試して、確認する。その練習としても役に立ちます。

更新の3つのタイプ

「何を更新すればいいか分からない」ときは、次の3つのどれに当てはまるか考えてみてください。

完成したゲームを前に、「機能追加」「弱点の修正」「書き換え」の3つの更新タイプと、Gitのブランチ(mainとbranch)を示したイラスト

タイプ	意味	考えるときの問い
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の画面の表示は、バージョンによって少し違う場合があります。