「UE4ぷちコン ゲームジャム」に参加してきた話
はじめに
Unreal Engine 4作品コンテストである「第8回UE4ぷちコン」にあわせて開催された「UE4ぷちコン ゲームジャム」に参加してきました。
この記事は「UE4ぷちコン ゲームジャム」についての自分用の振り返りメモとして考えたこと・やったことをまとめた記事です。
ちなみにゲームジャムに参加するのは今回が２度目で、初めて参加したゲームジャムである「Global Game Jam 2017」については以下の記事でまとめています。
目次
イベントの概要
| イベント名 | UE4ぷちコン ゲームジャム |
|---|---|
| 日程 | 2017/09/09 (土) 10:30 ～ 2017/09/10 (日) 20:00 |
| イベントページURL | http://historia.co.jp/archives/6900 |
| お題 | 60秒 |
作成したゲームについて
| タイトル | 60SEC DASH |
|---|---|
| ジャンル | 3Dプラットフォーマー |
| プレイ人数 | 1人 |
| 実行ファイル（Win） | Dropbox - 60secdash.zip |
| プレイ動画 | 【第8回UE4ぷちコン応募作品】60 SEC DASH |
今回のプレイ動画は、「UE4ぷちコン ゲームジャム」会場の試遊会で撮影されたものです。 音声も会場のものがそのまま録音されているので、会場の盛り上がりが伝わると嬉しいです。
この記事で一番書きたかったこと
かなり長くなってしまったので、書きたかったことを２点にまとめました。
レベルデザインについて
今作のレベルデザインでは、プレイヤーの段階的な学習を誘導するデザインになるよう心がけました。
具体的には、各ステージに行動の学習＋行動の最適化の2段階の学習ステップを用意し、ただクリアするだけでなく最適化を進めるところまで誘導することを狙いました。
学習ステップについては、例えば、ステージ2ではジャンプを使うことでステージをクリアできます（行動の学習）が、あえて最初にジャンプせずに次の足場に移ることで時間が節約できます（行動の最適化）。
しかし、普通にクリア出来てしまうステージをわざわざ最適化してプレイするとは考えられません。
そこで、本作ではステージ4に最難関となるステージ（羽根の回るステージ）を置きました。
最難関のステージをゲームの終盤に置くことで、道中で上記のような最適化テクニックを見つけて時間を節約し、試行錯誤の回数を増やす必要がある、という流れを作るためです。
会場では激ムズと言われまくりましたが、デザイン上は大体狙い通りであったわけです。
このように、各ステージをただクリアすればOKな対象ではなく、時間を短縮するためにプレイヤーが解を探すゲームにすることで、ゲームの奥行きを出すようにしています。
実際、会場での試遊でも最後には最適化した戦略を持って挑んでくださった方も居たので、ある程度狙いは成功したように思います。
実際のステージでプレイヤーに学習してもらいたかった狙いを書いていくと以下のようになります。
| ステージ | 第一段階（学習） | 第二段階（最適化） |
|---|---|---|
| 1 | 基本操作（移動） | 道なりに走らず、ジャンプしてショートカットする |
| 2 | 基本操作（ジャンプ） | ジャンプをしないことで滞空時間を減らす |
| 3 | ステージ2の発展 タイミングを合わせたジャンプ | なし（時間足らず。。） |
| 4 | ステージ3の発展 タイミングを合わせたジャンプ＋ボタン操作 | ステージの壁まで伸びている足場を狙う |
| 5 | ステージ4の発展 ボタン操作による謎解き | 解を覚える |
このような流れになっていました。
ステージ設計について
今回は後からバランスを調整する時に楽ができるよう、各ステージで失敗したときの被害の大きさを見積もることができるようにしていました。
ステージの最小クリア時間4秒＋ギミッククリアにかかる時間＝レベルクリアにかかる時間であるため、バッファは60－（レベルクリアにかかる時間×5）になります。
例えば、1ステージ10秒クリアの場合、1回死んだらカツカツになりますが、5秒クリアであれば数回死んでも余裕でクリアできるくらいの余裕ができます。
今回は時間が短かったのもあって通しプレイがほとんどできずかなり難しいゲームになってしまいましたが、それでもゲームとしてギリギリクリアできるバランスに収まったのは、この設計が根底にあったからだと考えています。
メンバー
チーム名：きつねさんチーム
| 職種 | 名前 |
|---|---|
| プランナー | zeal (https://twitter.com/zeal404) |
| プログラマー | akoto (https://twitter.com/akoto) |
| プログラマー | なっつー (https://twitter.com/yashinut) |
の3名でした。
冒頭に書いた「Global Game Jam 2017」では7名での開発だったので、今回はチーム規模がかなり小さくなりました。
この人数規模で実装できる仕様の量はかなり限られてしまうことが予想できたため、途中かなり夢を見た仕様も書きつつ、デザイン側で面白さを出せるように考えました。
担当箇所
企画内容
チームが決まってからチームメンバーでお昼を食べながら色々と企画について話し合いました。
その中で、ギミックの配置されたステージを60秒以内にクリアするゲーム、という方向性が浮かんだので、それに基づいて仕様を作成しました。
紙の仕様書について
「Global Game Jam 2017」に引き続き、今回も紙に仕様を書いていく形で作業を進めました。
紙に仕様を書くメリットはざっくり以下の2点であると考えています。
- メリット
- ノートPCでデスクトップの表示領域が限られるため、紙渡しの方が邪魔にならない（裏に戻ったりせずに済む）
- 仕様に簡単な図を入れたり加筆修正したりといった作業が（こだわらなければ）楽且つ早い
つまり、今回は紙に仕様書を書くことによって「仕様がないせいで実装者の手が止まってしまわないようにすること」と「作業者に負担をかけないようにすること」を意図していました。
実際、開発が終了後に同じチームの方から紙仕様書が良かったという意見もいただいたので、ある程度狙い通り機能したかなと考えています。
このようにゲームジャム向きの特性を持つ紙仕様書ですが、一方であえてデメリットを挙げるならば以下の2点が上げられると考えています。
- デメリット
- デジタル化が面倒ゆえに、検索性、一覧性の面で劣る（今回は全部スマホで撮影してSlackにアップしましたが、見づらく、失敗でした。。）
- ひとつの仕様を複数人で担当する際に不便
これらのデメリットについてもわからないではないですが、（仕様担当者が妥当な管理をおこなえば）少人数で仕様毎に担当を割り振ることの多いゲームジャムではそこまで問題にならないと考えています。
実際に書いた仕様書
ここからは、実際に書いた仕様書を時系列順に見ながら考えたことなどを書いていきたいと思います。
かなりの悪筆なので読みにくかったりすると思いますが、ご容赦ください。
「概要」
今回のゲームジャムでの作品の概要をまとめたものです。
当初は今の形よりもかなりギミックに重点をおいていたことがわかります。
書きながら、「あれ？でもこれ60秒でクリアできる謎作るの難しくね？」と思ったのを覚えています。
「キャラ」
プレイヤーキャラクターについての仕様をまとめたものです。
後に書く仕様書と同じように、左上に見出しをつけることでパッと見で何に関する仕様書かわかるようにしています。
工数削減を狙ってサードパーソンテンプレートをそのまま使用するようにしました。
あわせて、移動速度、ジャンプなどもデフォルトを指定しています。
これは決してサボったわけではなく、多くの人が一度はプレイしたことがあり、基本操作や今作で重要になる操作感に対する学習コストが低いことを見越したものです。
「ステージ全体構成」
ステージの設計をまとめたものです。
この時点では色んな死に方をさせるプレイを想定していたことがわかります。
ステージの広さはデフォルトレベルの広さとほぼ同じです。デフォルトレベルで実際に計測してみると端から端が4秒くらいだったので、ステージ設計上色々と都合が良いということで採用しました。
ステージ数は上記の4秒を基準に、3人で作れるステージ数の上限＆ギミックをクリアする時間のバッファを考慮して5ステージとしました。
「リソース」
「Global Game Jam 2017」でも作成したリソース表みたいなのを手元で書き散らしたものです。どれくらいの分量を用意しないといけないかを見積もるときに使用しました。
この内容は最終的にGoogle Spread Sheet上にリソース表を作成して共有しました。→ petitcon-fox - Google スプレッドシート
よく漏れるライセンス関係も一緒に管理していると楽ですね。
「画面フロー」
全体の画面遷移をまとめています。
「どのゲームでもだいたいこんなもんやろ」という感じですが、こういうのを書くのは認識をすり合わせるためにとても大事だと思います。
（とは言え、この仕様書は遷移ルールちゃんと書いてないの我ながら本当にクソなので真似しないでください。）
「ギミック」
ステージ4、5で出てきたボタンと実装できなかった電気のギミックです。
今回、ステージ内で完結するギミックについては共通化するより個人の責任において自分で実装する方が圧倒的に早いなと思いました。
ここについてはUE4を使ったチーム開発／ゲームジャムの経験の有無が大きく影響しそうに感じました。
「ステージ」
案出しの意味を込めてかなりの枚数を書きました。
各レベルでのプレイヤーに学習してほしいこと、目標秒数、ステージの大まかな構成と詳細をまとめています。
これらの意図については冒頭に書いたとおりです。
最後に
このような素晴らしいイベントを開いてくださった株式会社ヒストリア様をはじめ、協賛各社様に深く感謝いたします。
本当にありがとうございました。
