BETA

ゲームジャムでのUnity開発の進め方

投稿日:2018-10-14
最終更新:2018-10-24
※この記事は外部サイト(https://qiita.com/orange634z/items/2519cee...)からのクロス投稿です

前までゲームジャムで、うまく行かずまとまらなかったり、完成させることが出来ませんでした。 最近完成させることが出来るようになってきました。 その時にUnityの開発方法について話していきます。

私のスペック

私ですが普段はサーバーやインフラ系を中心にお仕事しています。 仕事ではUnityは全く触らないし、プライベートもそこまで時間を割いてUnityの学習をしているわけではありません。 レベルとしてはUnity初心者以上中級未満です。 なので、Unityは分かって来たけどゲームが上手く開発出来ないという方にも参考になると思います。

開発の流れ

注意ですが、あくまで私流でこのやり方が一番いいというわけではありません。 また、エンジニア目線なのでデザイナーやプランナーだとどう動けばいいかについては触れていません。 ちなみに製作時間は企画から始めて全部で8時間くらいを想定しています。

企画決め

企画を決めます。 たぶんテーマが与えられるので、それに沿ってチームで案を出して行くと思います。 この時、話が盛り上がって内容が膨れてしまいがち、なので適度に完成できる形に落とし込む必要があります。 以下のことを意識しながら形にしていくとまとまると思います。

  • 画面はタイトル・インゲーム・リザルトのみ
  • インゲームで使えるユーザーの操作方法は一種類のみ(タッチ、スワイプ、十字キーetc)

8時間での開発だとこれくらいが限度だと思います。 それ以上になると時間内に完成は難しくなります。本当に実装可能か一度見直してみる必要があります。 ゲームによっては調整しますが、だいたい上の2点を意識して形にして行きます。

あとこの段階で話し合いながら、Unityのバージョンや解像度、gitのリポジトリを決めておいた方がいいです。 時間も限られていますので、同時並行で出来ることはやっておいた方がいいです。 解像度はUIの調節等で一致している方が何かと便利です。

作業開始

開発時一番注意したいのは「コンフリクト」です。 コンフリクトで作業が巻き戻しになったり、手こずって時間がかかってしまします。 ただのタイムロスにつながるのでコンフリクトを起こさないように注意して開発していきましょう。

設計・共通部分の開発

まず、どのような設計にして、どうやって実現するかを話し合います。 ここできちんと話し合うことで開発方法の認識を合わせます。 ここで認識がズレていると、コンフリクトの元になります。

共通部分は同時に触るとコンフリクトする危険があるので、はじめは一つのPCでペア・モブプロ形式で作業をしていきます。 ドライバーとなる人はチームで一番Unityが出来る人がいいと思います。 私の場合はまずシーンの遷移を作ります。 どういう風にゲームが流れるかチームで共有できるし、作業分担をシーンごとに分けることが可能でコンフリクトの心配が減ります。

役割の分担・作業

共通部分が出来上がって来ると自然と割り振りが出来ると思います。 インゲーム部分は一人の人が作業した方がコンフリクトの心配がないので安心です。 少なくともシーンを触る人は一人にした方が無難です。 他の人でタイトルやリザルトなどを作成します。 プログラマーの人数が多い場合は素材集めやプレゼン作成に回りましょう。

コミットに関しては都度pushすることをおすすめします。 小さい範囲のコンフリクトならわりと解決できますが、範囲が大きいとコンフリクトをうまく解決できなく苦労します。 定期的にお互いに声をかけあいながらpush・merge・pullを細かく行いましょう。 共通で使うプレハブがある場合もコンフリクトしないように注意が必要です。

調整

ラスト1時間くらいになったら、もう一度ペア・モブプロ状態に戻ります。 ここからコンフリクトしたら、時間がない中修正しないといけなくなるので、焦りがちです。 なので、最後のブラシュアップは一つのPCでやることをオススメします。 作業が終わっておらず時間的に並列して作業する必要がある場合は、触るクラスやシーンをきっちり決めてコンフリクトがないようにしましょう。

発表

順調にいけば見せることが出来るものが出来ていると思います。

ひな形プロジェクト

以上のことから次回以降に使えそうなUnityのテンプレートプロジェクトを作って見ました。 https://github.com/orange634/GameJamTemplate

どういったものかを軽く説明します。 ちなみに、もっと上手く作れるかもしれませんが、とりあえずゲームジャム用なので動けばOKということで勘弁してください……

ひな形の中身は随時更新していこうと考えています。

ちなみに、パッケージ化しようとしたらDataStoreのプレハブが壊れてしまい、正しくパッケージ化できません……

シーン

シーンはTitle、Main、Resultの3つあります。 それぞれTitle->Main->Result->Titleの順番で遷移します。 Title->Mainはボタンを押すことで、Main->Result、Result->Titleはキーボードのスペースキーを叩くことで遷移します。

アスペクト比の固定

Cnavasのアスペクト比固定

TitleSceneにボタンをuGUIで実装してます。 Cnavasのアスペクト比を固定するためにデフォルトと異なる設定をしています。 こちらを参考に設定しています。 http://tsubakit1.hateblo.jp/entry/2014/12/11/223427

カメラのアスペクト比固定

カメラもアスペクト比を固定する必要があります。 こちらのコードを参考に実装しています。 https://meideru.com/archives/556

DataStore

シングルトンで実装しており、シーンをまたぐデータを一時的に入れておける箱的な感じです。 例えばMainシーンでの得点をResultシーンで表示させる際に使います。 今は中の実装がない空の状態です。

受け渡したいデータがある場合は、publicでプロパティを追加して使ってください。 本当は厳密にした方がいいですが、ゲームジャムなのでよっぽど複雑なデータの受け渡しをしない限り、これくらいシンプルに実装しても大丈夫でしょう。

ゲームジャムに参加しよう!

といった感じで色々話しましたが、一番重要なのはゲームジャムに参加して場数を踏むことです。 慣れているとどれくらいに規模のゲームなら大丈夫か、どれくらいにペース配分で作業すれば間に合うか等の感覚が出来ます。 そういった感覚は実際にゲームジャムに参加して慣れていかないと難しいと思っています。 なので、臆せずどんどん参加していきましょう! 何より、開発する過程を楽しむのがゲームジャムの魅力だと思っています。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@orange634nty の技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!