見出し画像

[Unity] [最強ゲームジャム2024] 学生たちと一緒に29時間で協力アクションゲーム作成したレポ


この記事は?

上記ゲームジャムに私+学生5人チームで参加しました。

アイデア出し -> ゲーム完成までの軌道と反省点をレポートしてますので、
短期間ゲームジャムにおけるゲーム作りの流れを汲めるかもしれません。

ゲームジャムルール

ルールとテーマ

4/28 10:30 ~ 4/29 15:00を開発期間として
「1人につき1ボタン用意されていて、2人以上で遊べる、かつ30秒以内にゲームの結果が決まるゲーム」をUnityで開発。
webGLで遊べるようにする必要あり。

メンバー構成

・Unityエンジニア役 (私+学生)
・デザイン役(学生)
・ステージ考案役(学生)
・サウンド役(学生)
・とりまとめ役(学生)

開発のながれ

事前準備1: 進行管理シートを用意

大まかな進行の流れ、各作業の細分化と進捗把握、明記すべきライセンスなどをまとめるGoogleSpreadSheetを用意しときました。

GSSは全ユーザーが同時に編集できるので、みんなここ読んだり書き込んだりしつつ作業進める感じです。

大まかな流れを事前に組んどいて作業をスムーズにー
あとからライセンスまとめるのめんどくさくならないようにー

事前準備2: ゲーム基盤部分作成

ゲームジャム的にOKかどうかは微妙ですが、ゲームの基盤となるプロジェクトを事前に用意しときました。

  • DOTweenとか、あったら便利なアセット突っ込んどく

  • 1Scene内で画面のオブジェクトのActive切り替えで画面遷移実現するべく、シーン遷移管理周り実装

    • シーンBase: ゲーム起動時、遷移時、Update、離脱時 関数を持たしとく

    • シーンマネージャー: 今のシーンが何なのか憶えて上記を発火させたり、シーン遷移させたりさせられるやつ。Singletonで鎮座させとく

  • システム音再生の作りを拝借https://github.com/wakepon/SoundManager?tab=readme-ov-file

チーム内自己紹介とアイスブレイク

メンバーに自己紹介させてロール決めました。決めたロールは進行シートに記載。

作るゲーム決め

GitMindを使ったブレーンストーミングで作るゲーム決めを行いました。
PCとGoogleアカウント持ってれば、一つのホワイトボードにアクセスできる優れもの。

<1:ブレストルール説明>
ブレストの事前ルールは詳細にしといたほうが軌道ズレ起こさなさそう...ってことでしっかり目に用意。

<ルール>
10~30秒でゲームが終わる、複数人プレイ、1人に1ボタン使って遊ぶゲームを考えよう。
フォーマットはEMSフレームワークを使います。
XXをXXして(手段)、XXをXXする(目的)ゲーム 

①アイデアに対して批判・否定をしない
②変わったアイデアを歓迎する
③質より量を重要視する

<2:ブレスト開始>
ツールの使い方を軽く教えて、10minぐらいアイデア出しさせました。

<3:アイデア整理>
各アイデアを読み上げてもらったあと少し掘り下げしてからジャンルごとに整理。

整理後

<4: アイデア投票>
投票により採用するアイデアを決めます。
今回は、
1. 1人2票持たせての投票で、一定票獲得しているアイデアを絞り込む
2. 1人1票での投票で上記アイデアから決める
といった流れで進行。ここの決め方はメンバー側でやってくれました。ナイス。

で今回決まったゲームは
「コース(それぞれが別のコースにいる)ギミックを協力して突破するゲーム」

<反省点>
EMSフレームワークを使わせる際、
「<誰々>が<どこどこ>で<何々>する<ほげほげ>ゲーム」
ぐらいに、世界観とかキャラとかの指定もさせたほうがよさそう。
そこをベースにゲームが固まりそう。

フワッとしたアイデアは見る人ごとに解釈が違っちゃって、その後のゲーム化が難しくなる。なった。

具体的なゲームの掘り下げ

上記で決まったゲームをもとに、プレイヤーがやることをホワイトボードに書き出しました。
その中で出てきた「もちつき」ってワードにより、
使うキャラをうさぎにしようとか、背景を宇宙とか月面にしよう、タイトルとオチはもちつきだ…
とかが決まっていきました。

ホワイトボードその1

<反省点>
事前準備した進行シート上には項目がなかった。
作るゲームのお題が決まったとて、画面構成とかにすぐは入れるかはお題の具体性に依存しちゃってそう。

世界観周りスムーズに決まらないとリソース用意とか難しくなるので、
お題出しタイミングで世界観まで決めとく方がよきかも

画面構成

それぞれのメンバーで考えたアイデアをホワイトボードに画面として記させて、具体的なゲームとして考えた際に不整合起きないかをチェックしました。

その過程で世界観、操作性、難易度など観点からマズイものを割り出したりできました。

結果として、ゲームの流れは以下のように。
クリア条件: 30秒以内にうさぎとギミックを操作してゴールし、餅をつかせればクリア。

0: タイトル
1: 1Pがうさぎを操作、2Pが動く足場を操作するアクションパート
2: 1Pが重力を操作、2Pがうさぎを操作するアクションパート
3: もちつき
4: リザルト

ホワイトボードその2
ホワイトボードその3

スプライト(絵)/フォント用意依頼

作るゲーム画面から必要そうなパーツを列挙、進行シートに記載してデザイン担当者に作業依頼。

<反省点>
画面構成決め直後、デザイン担当者とホワイトボード見て一緒に列挙していくべきだった。
「ここの表に必要な絵列挙したんでー」って投げ方は作業漏れ発生しやすく危険。


ホワイトボードに書き出してから進行シートに転記
絵リスト

SE・BGM用意依頼

必要な絵を洗い出したあと、同じ感じでSEとBGMも列挙。空いてるメンバーに用意を依頼。

BGM/SEリスト

プログラム実装

プログラム書けるメンバーと私で作業分担しつつゲーム実装を行いました。

分業方法としては、画面(Scene)ごとに触る人を決めて、
prefab化 -> ソース込みでUnityPackage化 -> USBメモリーで受け取って統合
って感じです。

うろ覚えクラス図。シングルトン多用もしたり相互依存もやっちゃうぜ


実装画面は進行シート上にて進捗管理

<反省点>
実装前にクラス図とか作れたら、作業分担とかしやすそう。
・2dプラットフォームアクションゲーム、考えないといけない部分多いので短期開発ゲージャムには向かないかも
・学生メンバー側の負担を抑えるべくタイトルシーンと餅つきゲーム部分の実装のみをお任せしていたが、
将来考えるとゲーム規模抑えて全体設計/実装までやってもらうべきではある

テストプレイとブラッシュアップ

各メンバーに触ってもらって改修を行っていきました。
・スピーディなプレイフィールを伸ばすため、1P/2Pの操作取替をおこなわないように。
・制限時間に対してステージ数足りてないので追加
・難易度調整
・餅つきシーン演出強化(押下ボタン示唆、お手付き、生声!)

<反省点>
・WebGLビルドを早めにやっておけば、みんな触れるようになるタイミングが早まりそう。テストプレイ期間が少なくご意見シートが機能していない。

完成と発表

締め切り1,2時間前に完成。
経験上完成させること自体難しいと考えていまして、余裕持っての完成は嬉しかったです。

<反省点>
発表タイミング中にゲームクリアすることに固執!
下手パターンを見せるべき...といったご指摘をいただいた。

実際ハイカジュの広告はプレイ下手なほうが数字いいらしいですし。
https://www.4gamer.net/games/999/G999905/20240308051/

締め

いろいろ勉強になりましたー。
ゲームプログラム教えるのも楽しかったし、ゲーム作る際のちょっとした流れ考えるのも楽しかったです。

前回からの反省として
・想定プレイ時間 x 1000~2000 = 開発時間
 スケール小さいほどイイ
・テーマ決めから開発開始までがグダるときつい
あたりを意識しての事前準備が結構功を奏したのもうれしい。
次のゲージャムは更に楽に作りたいな👀

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