:Unity 1週間ゲームジャム お題「しろ」 | フリーゲーム投稿サイト unityroom

unity1week は unityroom という Unity （現在は Godot も）の Web ゲームを投稿できるサービスで不定期に実施されているゲームジャムです。

今回は中学生の受講生１名が参加してくれました。

投稿作品

しろぬり | フリーゲーム投稿サイト unityroom

スマートフォンには対応していないのですが、パソコン・Mac でしたらブラウザさえあれば遊べます。

複数ステージに別れた物理パズルゲームになっています。
難易度は普通ですが、アクション要素もあるので、慣れていないと「やり方はわかっているのにクリアできない」ということもあるかもしれません。

受講生自身も、unity1week への参加は初めてで、おそらくこれだけ短期間でゲームを作ったことも初めてだったと思います。

参加と教室側でのサポート

今回は、「参加するつもり」というのは、事前に聞いており、全体としては以下のようなサポートを行いました。

1. お題が発表された翌日に、リマインドと次回のレッスン（翌日）までにゲームのアイデアを考えて来てほしいと伝える

2. レッスンは通常のレッスンではなく unity1week に向けたアイデアのブラッシュアップと、Unity プロジェクト作成、最初のプロトタイピングまでを一緒に行う

3. レッスンとは別に、受講生と一緒に作業する時間（約３時間）を設け、一緒に作業を行う

4. その後はチャット (Discord) で課題があれば教えてもらい回答する

アイデア出し

アイデア出しに関しては、「小さいゲームで、面白いゲームを作ろうとは思わないこと」を伝えました。

「面白くないゲームでいいのか？」という疑問は最もですが、まだ作業の見積もりができないため、「まずは完成を目指す」「そこから時間内で面白くする」という方針を取りました。

今回に関しては、受講生も「提出まで行いたい」と思ってくれていたので、この点は良かったです。（案外、「間に合わなかったらそれでいいや」と思う人もいますので）

ブラッシュアップ

持ってきてくれたアイデアを口頭で話してもらい、私が「それは具体的にはどういう感じ？」など、ゲームの開始から終了までのゲームループを質問ベースで埋めていきました。

この辺の言語化に関しては、AI に相談する際にも効いてくるので、まずは受講生の考えていることを言葉にする、または絵にするとどういうことかを明確にしていきました。

通常のレッスンであれば、ある程度仕様ができたところで、Gemini などの AI に仕様の考慮漏れや、詳細化すべき点などを洗い出してもらうのですが、今回は１レッスンの時間しかなかったためそこまでは行いませんでした。

プロトタイピング

ゲームの仕様が言語化されていくなかで、いくつかコアとなるメカニクスが出てきました。

• クリックでレベル内のオブジェクト（通路・障害物など）を削除することができる

• 2D プラットフォーマーのように動くキャラクター

シンプルなものではありますが、受講生は2Dゲームを最近作っていなかったことと、今回のゲームはシンプルにはこの２要素さえあれば、後は「パズルを考える」ことだけで成立するため、自宅での制作を進める点でも、レッスン中にそこまでのプロトタイピングを行いました。

ある程度、実現方法を調べたり Gemini に教えてもらい、実作業は OpenCode で行わせ、デバッグしていくことで時間内に終わらせました。

一緒に制作する時間

大都市になれば、ゲームジャムの際に一緒に作業するようなイベントが開催されることもありますが、残念ながら徳島はありません。

実は今回も駅前の会議室を予約して、もう一人参加していそうな知り合いを呼んで、もくもく会形式にしたかったのですが、あいにく受講生の空いている日と会議室の空いている日が噛み合わず、いつものレッスンルームで受講生と二人のもくもく会になりました。

レッスンルームで行いましたが、私も自分のラップトップを開いて、自分の unity1week の作品を隣で制作するということを行いました。
たまにお互いの進捗を見たり、質問を受けたりと、レッスンの倍の時間でしたがあっという間に終わりました。

結果、新しいスイッチのメカニクスが生まれたり、UI の実装も進み、ほぼステージの量産を行うだけのところまで進められました。

締切まで

締め切り直前に、unityroom へのアップロード方法の質問を受けたぐらいで、後は受講生自身で進めてくれました。

実際、一緒に作業した日は、まだステージは１つだけだったのが、完成版はステージがかなり増えていて嬉しい驚きでした。

本当にすばらしいです🎉🎉🎉

AI の使い方

OpenCode に作業をさせた話を書きましたが、一緒に３時間作業している間も、受講生はその多くを OpenCode に作業を依頼し、動作確認・デバッグ・フィードバックを自分で行うということを繰り返しています。

デバッグの中でコードを読んではいますが、今回はおそらくコードの記述量はかなり少ないと思います。

AI に頼っていいか？

当教室では、受講生の AI に対する向き合い方によって、利用すべきかどうかを判断しています。
今回参加した受講生は、AI が出力したコードやログに対してもきちんと向き合い、ただ AI に何かを出力させるだけの使い方はしていません。

ただ、今回は高い能力の AI を使った

通常のレッスンは、過剰に AI の能力に頼りすぎないように、Qwen3.6:27Bを使っています。十分に賢いモデルではありますが、Claude や GPT のように曖昧な命令を汲み取って（推論して）作業を完遂してくれる程ではありません。

そういう意味で、きちんと命令し、きちんと情報を与える練習にもなりますし、その中で、AI が出した間違いを自分でも調べる機会も多く、バランスの良い使い方だと思っています。（もちろん、ある程度 C# を読めたり、Unity Editor を触れる前提ですが）

今回は、時間もなかったため、OpenCode Go で使えるモデルを使ってもらいました。Claude や GPT のフロンティアモデル程ではありませんが、とても自宅では動かせない高性能なモデルです。

今回は、それ程複雑なゲームではなかったため、かなり効率よく働いてくれました。一方で、通常より受講生はコードに向き合う時間はなかったと思うので、ここからはゲームのブラッシュアップを通して、改めてコードに向き合ってもらう時間を取ろうと思っています。

一方で、「自分のゲームをゲームジャムに出せた」という達成感を得られたと思うので、今回の判断はそれ程悪くなかったと思います。

この辺りは、企業のプログラマーの話ではなく学生の話なので、どれぐらい AI を使ってもらうかは難しいです。
プログラマー志望なのであれば、AI にすべてを任せて終わりにはさせられませんが、あくまで趣味としてアイデアがあるからゲームを作りたいという場合には、AI を使ってどんどん形にしていく方が意味があると思います。

今後も、受講生一人ひとりと向き合いつつ考えていきたいと思います。