クリぼっちゲームジャム

どうもクリぼっちです。


学校主催のクリぼっちゲームジャムなるものに参加したので、今回はその振り返り。

クリスマスのたった1日でUnityやDirectXでゲームを作るというイベントで、本当に一瞬だった。
えっもう終わり?みたいな。

お題と、チームがランダムに発表されて、10:00企画開始16:00制作終了(〜16:30試遊会と投票)というとんでもないスケジュール。

ちなみにお題は「た つ」だった。来年が辰年だから?

決まったチームメンバーと合流して、いざスタート。


はじめまして。でも最初はやっぱり緊張


チームメンバーに知り合いは1人もいなかった。
3年生が3人と1年生が2人。2年生は自分だけ。
緊張。

と、こんなときのために作っておいたExcelのオリエンテンプレをメンバーに共有して、それに沿って自己紹介やアイデア出しをした。
おかげで出だしは好調だったと思う。

自己紹介シート


こういうのって作ってるときはやりすぎかなーとか思うんだけど、いざ始まると準備しておいてよかったなとなる。チーム制作は特に出だしが肝心だ。
メンバーの1人が事前にDiscordサーバーを用意してくれていたことも大きい。チャンネル分けもしてあってとても助かった。


それでも時間はかかる


アイデアと投票

みんなでブレストして出し合った単語をEMSフレームワーク形式でゲームアイデアにして、プレゼンして、それに投票して…決まらないから決選投票して…よしゲーム決まった!作ろう!


あれ、もう11:40じゃん…


うーん、まあ焦って企画テキトーに決めてしまうよりは全然良かったのかな。

決まったゲームの内容は、ブレストの「建物」「建つ」から着想を得たアイデア「敵の上に建物を建てて潰すゲーム」から広がっていって、
       ↓
「建物を上から落として敵を潰すゲーム」
       ↓
「建物を上から落として敵を潰したり、バリケードにして敵の侵攻を防ぐゲーム」
       ↓
「建物を上から落として敵を潰したり、バリケードにして敵の侵攻を防ぎながら制限時間いっぱいまで生き残るゲーム」
       ↓
「建物を上から落として全方位から侵攻してくる敵を潰したり、バリケードにして敵の侵攻を防ぎながら制限時間いっぱいまで画面中央のキャラクターを守りきる見下ろし視点のゲーム」
       ↓
「建物を上から落として全方位から侵攻してくる敵を潰したり、倒れないようにうまく建たせることで(倒れると崩れて消えてしまう)バリケードにして敵の侵攻を防ぎながら制限時間いっぱいまで画面中央のキャラクターを守りきる見下ろし視点のゲーム」

となった。

パワポで画面イメージの共有
制限時間生き残ればゲームクリア、HPが0になったらゲームオーバー


全員Unityを触ったことのあるプログラマー(一部プランナー志望)だったので、6人全員でプログラム作業を分担した。

大雑把に要素分けして分担した


担当割り振りはパパッと決めた。
残り時間を気にして多少焦っていたのだ。

それが今回の反省点に繋がるとも知らずに…


なんか思ってたよりも順調?


14:00にzoom上で全チームの途中経過報告会があったので、まずはそれに向けて制作を進めた。

自分の担当は操作部分だったので、ちょっと時間かかってしまうかも…と思っていたのだが、やってみたら意外とすぐに終わった。
同時進行でDirectXのチーム制作をしている最中だったので、ゲームエンジンの素晴らしさを改めて痛感した。


USBにデータを入れてマージ先のメンバーに渡して、それからの自分は1年生のメンバーに教えたり3年生のメンバーの様子を伺ったりしてずっと立ちっぱなしだった。
(学校入りたての1年生もいたので、gitを使うのは諦めた)


建物を上から落とす様子のみではあるものの、14:00の途中経過報告会では動く成果物を共有できた。
敵やUIに関しては、まだマージできていないだけでほぼほぼ出来上がっているみたいだったので、意外といける気がしていた。


ついに問題発生


カメラまわりのデータはメインのプロジェクトにマージできたようだ。
体力と残り時間のデータは、敵を担当しているメンバーのプロジェクトで一旦マージさせることにした。

マージ作業は順調に思えた。


が、その敵を担当しているメンバーのマージがなかなか終わらない。


体力との紐づけに時間がかかっているみたいだったので、自分や手が空いたメンバーで助けに入る。

どうやら敵担当のメンバーは、実際のところあまりUnityに慣れていないようだった。
彼のプロジェクトで一旦マージさせるという判断は間違っていた。
いや、そもそも彼に敵を担当させるのが申し訳なかったかな。敵の実装は意外と難しい。


時刻は15:00過ぎ。
ようやく終わったようなので、今度はメインのプロジェクトの担当者に渡してマージ。


するとここでも問題発生。


いざマージしてみるとエラーが連発して、1つ1つの対処に時間がかかる。
残り40分、残り30分…と時間が迫る中、みんなの中で焦りが大きくなっていく。
だが、この段階だとメインプロジェクトのメンバー以外はただただ見守ることしかできない。

ちなみに、裏でプレイヤーや敵の見た目、BGMやタイトル画面のデータまで用意ができていたのだが、このマージ作業に残り時間の全てを費やしたことで実装ならずとなってしまった。


時間切れ。試遊会へ


ついに終了時刻の16:00になり、すぐに試遊会開始となったが、自分たちのチームはまだあと少しエラーが取れずにいた。


10分遅れくらいでなんとか動くものにはできたので、急いで他のメンバーのPCにプロジェクトデータごと渡すことにしたのだが、当然ファイルの圧縮・展開に時間がかかる。

このときは自分含めみんな焦りすぎていて気づかなかったが、今思うと普通にビルドして渡した方が早かっただろう…。


試遊会は30分しかなかったので、自分は最初に少し運営して、あとは他のメンバーと交代して急いで他のチームのゲームを見に行った。

みんな6時間弱しかなかったはずなのに完成度が高くて恐ろしい…。
なかでも、今回2年制クラスのチームはDirectX限定だったのだが、Unityチームよりも比較的クオリティが高くてびっくりした。さすがっす。


試遊会終了。いよいよ投票結果発表…


投票結果発表。自分たちは4年制のチーム4だが、結果はいかに…

お?


なんと2位!

見た目や完成度は正直一番微妙な気がしていたのだが、これだけ評価してもらえたということは、プレイ体験でウケたのだろう。
プレイ体験を最も大事にしたい自分としては嬉しい結果となった。

1位のチームは動物タワーバトルのような落ちもの系2Dゲームで、手軽な面白さがありつつ完成度も高かった。


総括


これだけ短い時間で、しかも出会ったばかりの人たちとゲームを作ったのは初だったので、新鮮な体験で楽しかった。

反省点としては、メンバーの能力値と各作業の重さをしっかり吟味していなかったことによるアサインミス。
担当決めはもっと慎重に行う必要があるという教訓を得た。

また、敵と体力のマージが怪しいとなった時点で自分が席を代わって引き継げばもっと効率良くできたのかもしれない。
メインのプロジェクト担当者に渡す前に想定されるエラーや挙動を修正できただろうし、渡したときに中身の構造を詳しく説明できただろう。

それと、メンバーがせっかく探してくれた素材を取り込めなかったのは悔やまれる。


おまけ


なので、家に帰ってから個人的に素材を取り込んだり調整を加えてブラッシュアップしたデータをみんなに送った。


うん、ゲームっぽくなったかな。





あとやっぱり画面の振動って大事だね。

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