![見出し画像](https://assets.st-note.com/production/uploads/images/68741449/rectangle_large_type_2_c299cf85e44d716d250c926ea9a4f748.png?width=1200)
unity1weekで作った『JusticeTowerBattle』について
JusticeTowerBattleというゲームをどんな風に作ったのかを語ります。
JusticeTowerBattle | フリーゲーム投稿サイト #unityroom https://t.co/u5KLwpR3l0 #unity1week
— あやは401【シェーダー開発中】 (@ayaha__401) December 26, 2021
オフライン2人対戦ゲームを一週間で作りました!
兄弟や家族と対戦しよう!
日程
![](https://assets.st-note.com/img/1640678469425-jUxnnHn3Nl.png?width=1200)
7日間ありましたがゲームを作り始めたのは2日目からです。実質6日でゲームを作りました。
脳内予定では最初の2日でメインゲーム部分を完成させ、残りの期間はWebGL形式でのビルド方法の確認やゲームの見た目を良くすることに時間を使おうとしました。
ゲーム部分ほぼできたね#unity1week pic.twitter.com/UeT2FnkOp9
— あやは401【シェーダー開発中】 (@ayaha__401) December 23, 2021
これの正の字が降ってきてターンが変わる部分は5時間で作ったりとにかく速さを意識しました。
実際この時間の割り振り方で成功しました。
音を探したりUIの配置や絵を描く作業が思いのほか時間がかかり苦戦しました。「プログラミングのほうが楽だ~」なんて思ったりもしちゃいましたね。
またWebGL形式でのビルドをしたことがなく、そこでのエラーで進行が止まるのが物凄く怖かったので余裕を持った日程にしててよかったです。
プログラミング
それらしいクラス設計はしてないです。
スパゲッティコードを書いてどこでエラーが起きてるのかわからなくて制作の進行が止まるのが嫌だったので今回の制作でのプログラミングルールを作ってそれに基づいて設計しました。
そのルールを紹介します。
相互参照しない、循環参照も
SerializeFieldで極力GameObjectを取得しない
相互参照しない、循環参照も
当たり前ですがゲームジャムだからといってやっちゃうと危ないと思ったのでやらないようにどうにかしました。
![](https://assets.st-note.com/img/1640679903746-dgT8APZFJ5.png?width=1200)
相互参照しないように中央のTurnManagerはほかのスクリプトのことを一方的に知っています。矢印が刺さってるスクリプトはpublicメソッドを持っていてそれを中央のTurnManagerが呼び出すようになっています。
参照する方法はSerializeFieldを使います。
クラス間にInterfaceを挟んでZenjectなどでくっつけるのがいいですがコンポーネント(機能)をつけるたびにInterfaceを作って結合する作業が入ってしまってジャムに間に合う気がしなかったので止めました。
それとまだZenjectに慣れてなくてZenject側でエラーが出たときに対処ができないのも使わなかった理由です
SerializeFieldで極力GameObjectを取得しない
当たり前のことですがジャムだからといって適当にすると事故のもとだと思ったのでこうしました。
上記した通りクラスを参照する方法はSerializeFieldですがここでなんでもGetComponentできるGameObjectで取ってしまうとUnity上でアタッチするミスが起きてしまうのでクラスを指定してアタッチミスを防ぎました。
![](https://assets.st-note.com/img/1640737385629-RyvoDWGXoi.png)
空のGameObjectにスクリプトをくっつけてスクリプトとオブジェクトを1対1の関係にしてアタッチミスを防ぎます。
プログラミングのエラーならどこでエラーしてるのか分かりやすいですがUnityでのアタッチミスでのエラーは割と見つけにくいと思っており、それで開発速度が落ちるのが嫌だったのでこのようにしました。
演出
いいかんじ
— あやは401【シェーダー開発中】 (@ayaha__401) December 23, 2021
後は演出のほうを頑張りたい#unity1week pic.twitter.com/xBiEsUZMXO
左側のプレイヤーのターン開始時は文字が左から、右の時は右から出てきます。
勝者が決まった時も勝った人のほうからUIが出てきます。
左右どちらのターンなのかを自覚させる方法が思いつかなかったのでUIを出す方向で自覚させようと思ってこのようにしました。
UIの移動についてはすべてDOTweenで行っています。
![](https://assets.st-note.com/img/1640738366128-HCRecYqJBk.png)
チュートリアルシーンを作る時間も、うまく教える方法も思いつかなかったので操作方法に関して、常に操作方法を表示させる方法をとりました。(赤線の中)
白い線から出た場所に正の字を落としたら負けになるルールも両端にバツをつけることで伝えようとしました。(緑の中)
アクションゲームで落ちちゃいけない穴などに警告マークが描いてあることがよくあるなと思い、それを参考にしました。
シェーダー
![](https://assets.st-note.com/img/1640738894662-UE6puh6LB1.png)
背景のマス目を作るのに使っています。
マス目程度手書きでいいんじゃないかと思うと思いますが以下の理由でシェーダーにしました。
Unity上で自由にマス目の大きさを変えれる
Unity上で色を簡単に変えれる
Unity上で自由にマス目の大きさを変えれる
![](https://assets.st-note.com/img/1640739125710-JVBHl9uyRN.png?width=1200)
![](https://assets.st-note.com/img/1640739135173-pGNpYHYQu3.png?width=1200)
シェーダーですのでパラメータを調節するだけですぐにマス目の大きさを変更できます。
ペイントソフトで描いたものだとジャギーの心配をしたり(ここは設定でどうにかなるはず)画像サイズのことを考えたりしなくてはいけないですが、
シェーダーなら計算によって図形を作ってるのでジャギーの心配はないです。(負荷はかかる)
Unity上で色を簡単に変えれる
![](https://assets.st-note.com/img/1640739382988-THUYdhahL8.png?width=1200)
線の色と背景の色を自由に変えれます。色を変更したくなってペイントソフトとUnityを行ったり来たりする必要が無くなります。
作るゲームの全体が決まっていて配色や必要なUIがわかってるならペイントソフトで作れるのですがジャムでゲームの全体像をはっきりさせないまま作り始めたのでいつでも設定を変更できるシェーダーを使うことにしました。
ゲームデザイン
どうぶつタワーバトルからどうぶつを引き算しただけです。
テーマに沿ったもっと斬新なアイデアのゲームを作りたかったのですが1日遅れで制作する時点で企画を考える時間が無いと思い企画にこだわらないようになってしまいました。
デザイン
楽そうな白黒の統一されたデザインにしよう!と思って白黒にしたのですが、白黒にするとそれ以外の色が使えないのが不便だなと感じました。
背景を黒、プレイヤー1を白、プレイヤー2を何色にすればいいのだろうと考えたりしました。(結局二人とも白色にした)
デザイン難しいですね。
まとめ
何よりも6日間でゲームが完成してよかったです。
次の機会があれば今度はチーム制作にしたいですね。特に今回企画がダメだったのでそこら辺をどうにかしてくれそうな友達を誘って…
この記事が気に入ったらサポートをしてみませんか?