ダークモード
授業の進め方
このページは、この教材を使って授業をする先生・講師の方向けの資料です。
教材のねらい
- 完成する体験: 全20回で、タイトル画面からボス戦・ハイスコア保存までそろった1本のゲームを完成させます。「自分で最後まで作れた」という体験を一番のねらいにしています
- 毎回動くものができる: 各回の終わりには、必ず ▶ で動作を確かめられる状態になります。小さな成功を積み重ねる構成です
- Unity の基本操作と C# の基礎: GameObject・コンポーネント・プレハブ・物理・UI・入力・音といった Unity の基本と、変数・条件分岐・くり返し・関数・配列・enum・コルーチンなど C# の基礎を、ゲームの機能と結びつけて学びます
- 3Dモデルで2Dゲーム: 無料の3Dモデル(Kenney Space Kit)を使い、Z=0 の平面上だけでゲームを作ります。見た目の満足度は高く、数学的な難しさは2D並みに抑えています
- ルールを守った創作: 素材のライセンス、作品公開時の個人情報など、作り手としてのマナーにも触れます
全20回の時間配分
「重さ」は作業量と概念の難しさを合わせた目安です(★1〜3)。配布用プロジェクトは、各回の 開始時点 の状態を git タグとして用意する予定です(例: 第7回を始めるときは lesson-07)。
| 回 | タイトル | 目安時間 | 重さ | 前回からの持ち越しの注意 | 配布用プロジェクト |
|---|---|---|---|---|---|
| 0 | 準備をしよう | 90分 | ★★★ | インストールは時間がかかるため、可能なら事前に済ませておく | lesson-00(素材のみ) |
| 1 | 宇宙の舞台を作る | 60分 | ★ | プロジェクトが正しいテンプレート(Universal 3D)で作られているか | lesson-01 |
| 2 | 自機を置く | 60分 | ★★ | カメラが Orthographic・Size 5 になっているか | lesson-02 |
| 3 | 自機を動かす | 90分 | ★★★ | 初めてのスクリプト。エディタの設定でつまずきやすい | lesson-03 |
| 4 | 画面からはみ出さない | 60分 | ★★ | PlayerController が動く状態か。Bank の親子構造 | lesson-04 |
| 5 | 弾を撃つ | 90分 | ★★★ | Muzzle があるか。Input の Save Asset 忘れが多い | lesson-05 |
| 6 | 流れる星空 | 60分 | ★★ | 弾がプレハブ化され、シーンの弾が消えているか | lesson-06 |
| 7 | 敵が現れる | 90分 | ★★ | コルーチンの初出。概念説明に時間を取る | lesson-07 |
| 8 | 当たり判定 | 90分 | ★★★ | 敵がプレハブ化されているか。Rigidbody/Trigger/Tag の設定漏れが最大のつまずき | lesson-08 |
| 9 | 爆発と音 | 90分 | ★★ | 当たり判定が動いているか。Cartoon FX を使う場合は事前に Asset Store で入手 | lesson-09 |
| 10 | スコアを表示 | 60分 | ★★ | TMP Essentials のインポート。static の説明 | lesson-10 |
| 11 | 残機とゲームオーバー | 90分 | ★★★ | PlayerLife を作り直すため、前回までのコードとの差が大きい | lesson-11 |
| 12 | タイトル画面 | 60分 | ★★ | Build Profiles へのシーン登録忘れ | lesson-12 |
| 13 | いろいろな敵 | 90分 | ★★★ | EnemySpawner が配列に変わるため、Inspector の再設定が必要 | lesson-13 |
| 14 | パワーアップカプセル | 90分 | ★★★ | UI 作業が多い。PowerUp アクションの追加 | lesson-14 |
| 15 | パワーアップの中身 | 90分 | ★★★ | 変更するスクリプトが多い(4本)。完成版コードとの見比べを推奨 | lesson-15 |
| 16 | オプション | 60〜90分 | ★★ | Queue の概念説明 | lesson-16 |
| 17 | ボス戦 | 90分 | ★★★ | テスト時に EnemySpawner を止める手順 | lesson-17 |
| 18 | ステージの流れ | 90分 | ★★★ | ScriptableObject の初出。出現表の入力に時間がかかる | lesson-18 |
| 19 | 仕上げと公開 | 90分 | ★★ | Web ビルドは数分〜十数分かかる。公開前の確認 | lesson-19 |
TIP
90分の回は、60分授業なら2コマに分けることを想定しています。中項目(「## 1.」「## 2.」…)の切れ目が区切りの目安です。
配布用プロジェクトについて
git タグ lesson-NN は「第NN回を始める時点」の状態を想定しています(つまり第(NN-1)回の完成状態)。タグの整備状況はリポジトリで確認してください。
1回の進め方の例(90分の場合)
| 時間 | 内容 | ポイント |
|---|---|---|
| 5分 | 導入 | 前回のふりかえり。「今日はこれを作ります」と完成形を見せる |
| 5分 | デモ | 先生の画面で完成状態を実際に遊んで見せる。何を作るかのイメージを共有 |
| 50分 | 手順 | 教材の手順に沿って作業。中項目ごとに「ここまでできた人?」と確認 |
| 10分 | 動作確認 | ▶ で動かす。うまくいかない子は「つまずきポイント」の表を見る |
| 15分 | チャレンジ | 早く終わった子はチャレンジ課題。遅れている子のフォローの時間にもなる |
| 5分 | ふりかえり | 「まとめ」を読む。保存を確認して終了 |
60分の場合は、デモを短くし、チャレンジを宿題または次回の冒頭に回すと収まりやすくなります。
進度差への対応
- 早く終わった子: 各回末の「チャレンジ課題」に取り組ませます。素材を差し替える(別の宇宙船モデルにする、効果音を変える)のも良い課題です
- 少し遅れている子: スクリプト完成版一覧 と見比べさせます。ただし完成版は第19回時点のコードなので、その回にまだ出てこない行が含まれることに注意してください。各回のページに載っている「その時点の全文」を優先して見せます
- 大きく遅れた・プロジェクトが壊れた子: 前回の完成状態(git タグ
lesson-NN)のプロジェクトを配り、そこから再開させます。自分のプロジェクトを直すことにこだわりすぎないほうが、授業全体の流れを保てます - 欠席した子: 同様に該当回のタグから再開できます。チャレンジ課題の時間を使って追いつかせます
よくあるトラブルと声かけ
| トラブル | 原因の多くは | 声かけの例 |
|---|---|---|
| ▶ を押しても始まらない | コンパイルエラー | 「Console の赤い文字をダブルクリックしてみよう。何行目って書いてある?」 |
| 弾が敵をすりぬける | Rigidbody / Is Trigger / Tag / Z 座標 | 「こまったときは の表を上から順に見てみよう」 |
| NullReferenceException | Inspector のつなぎ忘れ | 「Inspector に None になっている欄はない?」 |
| 数字を変えたのに戻った | Play 中に変更した | 「Play 中に変えたものは止めると戻るよ。いい数字はメモしておこう」 |
| モデルがピンク | マテリアルが URP 非対応 | 「Render Pipeline Converter を使ってみよう」 |
| キーが効かない | Save Asset 忘れ・アクション名のつづり | 「InputSystem_Actions を開いて Save Asset を押した?」 |
| 何をしたかわからないが壊れた | — | 「1つ前の状態から一緒にやり直そう」(前回タグから再開) |
「エラーは失敗ではない」
エラーはプログラマーなら毎日見るものです。「エラーが出た=ダメ」ではなく「エラーが場所を教えてくれている」と伝えると、生徒が Console を読むようになります。
詳しい対処法は こまったときは にまとめています。
PC の準備
ソフトウェア
- Unity Hub と Unity 6(6000.0 LTS) をインストールします。教室全体でバージョン(パッチ番号まで)をそろえると、プロジェクトの受け渡しで問題が起きにくくなります
- モジュールとして Web Build Support を追加しておくと、第19回の Web ビルドで使えます
- コードエディタ(Visual Studio Code、Visual Studio、Rider など)。VS Code の場合は Unity 拡張機能も入れておきます
- ディスク容量: Unity 本体とモジュールで 10GB 程度、プロジェクト1つで数GB を見込んでください
Unity アカウント
- Unity の利用にはアカウントが必要です。生徒個人のアカウント作成には保護者の同意が必要 です(年齢条件は Unity の規約を確認してください)
- 学校・教室の方針によっては、教室で管理するアカウント を使う方法もあります。どちらにするか事前に決め、保護者に案内しておきます
- ライセンスは Unity Personal(無料)を想定しています。教育機関向けのライセンスが使える場合はそちらでもかまいません
教室のネットワーク
- Unity のインストール、パッケージの取得(初回のプロジェクト作成時)に大きな通信が発生します。全員が同時に行うと回線が詰まることがあるので、事前インストールをおすすめします
素材の配布方法
- CC0 の素材(Kenney Space Kit、Kenney Sci-fi Sounds、BGM など)は、先生がまとめてダウンロードし、zip や共有フォルダで配布してかまいません。配布用プロジェクトに同梱することもできます
- Cartoon FX Remaster Free(Unity Asset Store)は Asset Store EULA の対象です。配布用プロジェクトへの同梱・再配布はできません。使いたい生徒は各自の Unity アカウントで Asset Store から入手させてください。教材上は使わなくても進められます(自作の爆発パーティクルで代替)
- 素材の一覧とライセンスは 素材とライセンス にあります
作品の公開と個人情報
第19回で、Web ビルドしたゲームを Unity Play などで公開する方法を扱います。
- 公開は 保護者と先生の確認を取ってから にします
- ゲーム内やタイトル、説明文に 本名・学校名・顔写真・住所などの個人情報を入れない よう指導します。ニックネームを使います
- 公開用アカウントの扱い(個人か教室か)は、Unity アカウントの方針とあわせて決めておきます
- 他人の著作物(有名キャラクター、市販ゲームの音楽など)を使った作品は公開しないよう指導します
- 公開しない選択肢も用意し、校内発表会や教室内での遊び合いでも十分に成果発表になることを伝えます
評価の観点の例
| 観点 | 見るところの例 |
|---|---|
| 知識・技能 | GameObject・コンポーネント・プレハブの関係を説明できる。手順どおりに機能を実装できる。エラーメッセージから原因の場所を見つけられる |
| 思考・判断・表現 | 数値(速さ・間隔・HP)を調整してゲームバランスを考えている。チャレンジ課題で自分なりの工夫を加えている。ステージ構成(第18回の出現表)を自分で設計している |
| 主体的に学習に取り組む態度 | つまずいたときに付録や完成版コードを使って自分で解決しようとする。友だちと教え合う。素材のライセンスを確認して使っている |
最終回で「工夫したところ」を1分程度で発表する時間を取ると、評価材料にもなり、生徒同士の刺激にもなります。
このサイトの更新・公開方法
この解説書は VitePress で作られています。本文は docs/ 以下の Markdown ファイルです。
ローカルでプレビュー
Node.js(18 以上)が必要です。リポジトリのルートで次を実行します。
bash
npm install # 初回のみ
npm run docs:dev # http://localhost:5173 でプレビューMarkdown を保存すると、ブラウザの表示が自動で更新されます。
ビルド
bash
npm run docs:build # docs/.vitepress/dist に静的ファイルが出力される
npm run docs:preview # ビルド結果をローカルで確認公開
docs/.vitepress/dist の中身を静的サイトとしてホスティングします。
Cloudflare Pages の場合
- リポジトリを接続し、ビルドコマンドに
npm run docs:build、出力ディレクトリにdocs/.vitepress/distを指定します - ルートドメイン(
https://<project>.pages.dev/)で公開されるので、baseは'/'のままで動きます
GitHub Pages の場合
https://<ユーザー名>.github.io/<リポジトリ名>/で公開されるため、docs/.vitepress/config.mtsのbaseを'/<リポジトリ名>/'に変更しますtsexport default defineConfig({ base: '/Unity_2Dshooting/', // リポジトリ名に合わせる // ... })リポジトリの Settings > Pages で Source を GitHub Actions にし、VitePress 公式ドキュメントの「Deploy to GitHub Pages」にあるワークフローを
.github/workflows/に置くのが簡単です独自ドメインを使う場合や
<ユーザー名>.github.ioリポジトリの場合は、baseは'/'のままです
画像の追加
スクリーンショットは docs/public/images/ に置き、本文からは /images/lesson07-01.png のように参照します(base を変えても VitePress が自動で補正します)。本文中の <!-- 画像: ... --> コメントが画像を入れる予定の場所です。