「UE4ぷちコン ゲームジャム」に参加してきた話

はじめに

Unreal Engine 4作品コンテストである「第8回UE4ぷちコン」にあわせて開催された「UE4ぷちコン ゲームジャム」に参加してきました。

この記事は「UE4ぷちコン ゲームジャム」についての自分用の振り返りメモとして考えたこと・やったことをまとめた記事です。

ちなみにゲームジャムに参加するのは今回が2度目で、初めて参加したゲームジャムである「Global Game Jam 2017」については以下の記事でまとめています。

zeal404.hatenablog.com

目次

イベントの概要

イベント名 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段階の学習ステップを用意し、ただクリアするだけでなく最適化を進めるところまで誘導することを狙いました。

学習ステップについては、例えば、ステージ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にアップしましたが、見づらく、失敗でした。。)
    • ひとつの仕様を複数人で担当する際に不便

これらのデメリットについてもわからないではないですが、(仕様担当者が妥当な管理をおこなえば)少人数で仕様毎に担当を割り振ることの多いゲームジャムではそこまで問題にならないと考えています。


実際に書いた仕様書

ここからは、実際に書いた仕様書を時系列順に見ながら考えたことなどを書いていきたいと思います。

かなりの悪筆なので読みにくかったりすると思いますが、ご容赦ください。

「概要」

f:id:zeal404:20170925011514j:plain

今回のゲームジャムでの作品の概要をまとめたものです。

当初は今の形よりもかなりギミックに重点をおいていたことがわかります。

書きながら、「あれ?でもこれ60秒でクリアできる謎作るの難しくね?」と思ったのを覚えています。


「キャラ」

f:id:zeal404:20170925011539j:plain

プレイヤーキャラクターについての仕様をまとめたものです。

後に書く仕様書と同じように、左上に見出しをつけることでパッと見で何に関する仕様書かわかるようにしています。

工数削減を狙ってサードパーソンテンプレートをそのまま使用するようにしました。

あわせて、移動速度、ジャンプなどもデフォルトを指定しています。

これは決してサボったわけではなく、多くの人が一度はプレイしたことがあり、基本操作や今作で重要になる操作感に対する学習コストが低いことを見越したものです。


「ステージ全体構成」

f:id:zeal404:20170925011626j:plain

ステージの設計をまとめたものです。

この時点では色んな死に方をさせるプレイを想定していたことがわかります。

ステージの広さはデフォルトレベルの広さとほぼ同じです。デフォルトレベルで実際に計測してみると端から端が4秒くらいだったので、ステージ設計上色々と都合が良いということで採用しました。

ステージ数は上記の4秒を基準に、3人で作れるステージ数の上限&ギミックをクリアする時間のバッファを考慮して5ステージとしました。


「リソース」

f:id:zeal404:20170925011648j:plain

「Global Game Jam 2017」でも作成したリソース表みたいなのを手元で書き散らしたものです。どれくらいの分量を用意しないといけないかを見積もるときに使用しました。

この内容は最終的にGoogle Spread Sheet上にリソース表を作成して共有しました。→ petitcon-fox - Google スプレッドシート

よく漏れるライセンス関係も一緒に管理していると楽ですね。


「画面フロー」

f:id:zeal404:20170925011816j:plain

全体の画面遷移をまとめています。

「どのゲームでもだいたいこんなもんやろ」という感じですが、こういうのを書くのは認識をすり合わせるためにとても大事だと思います。

(とは言え、この仕様書は遷移ルールちゃんと書いてないの我ながら本当にクソなので真似しないでください。)


「ギミック」

f:id:zeal404:20170925011958j:plain

f:id:zeal404:20170925012020j:plain

ステージ4、5で出てきたボタンと実装できなかった電気のギミックです。

今回、ステージ内で完結するギミックについては共通化するより個人の責任において自分で実装する方が圧倒的に早いなと思いました。

ここについてはUE4を使ったチーム開発/ゲームジャムの経験の有無が大きく影響しそうに感じました。


「ステージ」

f:id:zeal404:20170925012047j:plain

f:id:zeal404:20170925012121j:plain

f:id:zeal404:20170925012145j:plain

f:id:zeal404:20170925012245j:plain

f:id:zeal404:20170925012405j:plain

案出しの意味を込めてかなりの枚数を書きました。

各レベルでのプレイヤーに学習してほしいこと、目標秒数、ステージの大まかな構成と詳細をまとめています。

これらの意図については冒頭に書いたとおりです。


最後に

このような素晴らしいイベントを開いてくださった株式会社ヒストリア様をはじめ、協賛各社様に深く感謝いたします。

本当にありがとうございました。

Global Game Jam 2017に参加してきた話

はじめに

ゲーム開発をおこなうハッカソンとして世界最大の規模を誇る「Global Game Jam 2017」にプランナーとして参加してきました。

「Global Game Jam」への参加は初めてだったので、参加して感じたことと、実際に書いた仕様書などのドキュメントを公開します。

基本的には自分の考えたこと・やったことの振り返りですが、今後ゲームジャムに参加しようと思う方の参考になれば幸いです。

はじめに書いておきますが、糞長いです。

また、関連として、同じチームで一緒にゲームを作ったとりすーぷさんのQiita記事が公開されているので、そちらも合わせて読むとより面白く読めると思います。この記事のなかでも適宜参照しています。

イベントの概要

イベント名 Global Game Jam 2017
日程 2017/1/20(金)18:00 〜 2017/1/22(日)19:00
参加会場 東京 茅場町会場
イベントURL Global Game Jam Japan
お題 WAVE

作成したゲームについて

お題の「WAVE」を衝撃波と解釈し、マッチョがヒップドロップした衝撃波で敵を場外に吹き飛ばすゲームを作成しました。

正直何を言っているかわからないと思うので、サマリーと動画を用意しました。

今回完成したゲームは以下です。

タイトル Muscle Drop
ジャンル 3Dアクション
プレイ人数 2〜4人
お題の解釈 衝撃波
実行ファイル(Winのみ) URL
プレイ動画
Muscle Drop(GGJ2017)

なんとなくどういうゲームか察していただけたかと思います。

最も表現したかったのはヒップドロップで敵をふっ飛ばすときの爽快感です。

モーションが間に合わず女の子っぽい走り方になっていたり(ユニティちゃんSDモデルのデータを借用)、もはやヒップドロップではない点を除けば割りとコンセプトに忠実にできていると思います。

補足

「お題」について、「Global Game Jam」ではイベントごとに毎回異なる「お題」が提示され、ジャムで作成するゲームの内容は必ずその「お題」に基づいて制作する必要があります。

ただし、この「お題」は割りと広い解釈が認められるので、こじつけ的なものもOKなようです。

(というより、是非のジャッジは当事者に委ねられるため、実質なんでもアリっぽいです)


メンバー

  • プログラマ 4名
  • プランナー 2名
  • グラフィッカー 1名

ジャムを終えて振り返ってみると、割りとバランスの良い構成だったように感じました。

主な職種としてはサウンドがいませんでしたが、Asset Storeのパワーでなんとかなりました。Asset Storeは偉大。


担当した箇所

担当した箇所は以下の通りです。抜けや忘れてしまっている箇所があるかもしれません。

共同の記載はもうひとりのプランナーの方と共同で全体をまとめた部分、それ以外は担当した部分です。

  1. ゲーム内容の企画
  2. ギミック案出し(共同)
  3. ギミック仕様作成(共同)
  4. レイアウト仕様作成(バトル、リザルト)
  5. サウンド周り(BGM,SE選定)
  6. パラメータ調整(キャラ挙動)
  7. レベルデザイン(共同)

見ての通り、普段のゲーム開発で行っているような作業を一通り行っていることがわかります。

その意味で、ゲームジャムであってもプランナーに求められる能力は基本的に変わらないようでした。

※スケジュールについてはプログラマーの方にまとめていただきました。ありがたや。


仕様

普段のゲーム開発とは違い、ゲームジャムではどの仕様を詳細化してどの部分をざっくりとしたものにするかの判断が求められるように感じました。

そのため、この項では主にどう考えたか、どうやって判断が行われたかを書きます。

ゲームのメインロジック(キャラの挙動・ふっ飛ばしの部分)

ゲームの核となるメインロジックについては、Unityの物理エンジンを使うことが企画段階で決まっていました。

物理エンジンを採用した理由
  • 細かい部分の挙動まで指定・実装していた場合、時間が足りない
  • 物理エンジンの予想しにくい挙動自体である程度のウケが狙える

そのため、企画発表が終わって制作に移るタイミングでどのようなパラメータを必要とするかの認識をプログラマとすりあわせた後はほとんど指定することはなく、終盤(確か二日目の夜)に実装されたキャラクターを動かしながら調整した程度でした。

ただし、物理エンジンで理想の挙動を表現することが思っていたより難しく、プレイヤーの挙動についてはまだまだブラッシュアップの余地のある出来になってしまいました。

現時点での私のスキルではトレードオフにならざるを得ない部分でしたが、慣れてしまえば48時間でももうちょっとマシな出来になりそうではあります。

ギミック(衝撃波の伝播、即死トゲ)

企画の段階でステージ上にギミックを置きたいよねという話になっていました。

そこで、企画発表終了後、プログラマーの要請に応えて実装したいギミックのリストを書き出しました。

前述のとりすーぷさんの記事でも言及がありましたが、アイディアを後出しで入れることは現実的に不可能であると伝えられていたため、プランナー二人で結構な時間を割いた覚えがあります。

具体的には、以下の手順で実装したいギミックを決めていきました。

手順

1. 二人でバラバラにギミックを思いつく限り付箋に書き出す

A:即死トゲ、プロテインで強大化、回転ハンマー、ダメージで崩壊する床、衝撃波が伝播するオブジェクト、ダンベルでジャンプ力アップ
B:ツルツルの床、バンパー、ベルトコンベア、衝撃波が伝播するオブジェクト、即死トゲ、ヒップドロップでアイテム出現

1. 二人で書き出したギミックを照らし合わせ、似たアイディアをまとめる

衝撃波が伝播するオブジェクト×2、即死トゲ×2など

1. ギミックの種類でおおまかなカテゴリを作成し、出てきたアイディアをグルーピング

設置オブジェクト系・・・即死トゲ、回転ハンマー、衝撃波が伝播するオブジェクト、ベルトコンベア、ツルツルの床、バンパー
ヒップドロップで起動する系・・・ヒップドロップでアイテム出現
アイテム系・・・プロテイン、ダンベル

1. カテゴリ毎に各アイディアの面白さを検討し、コスパの良いアイディアの順で優先度を設定

下図参照

1. プログラマと相談

(このあと翌朝までに仕様の実装に耐えうるクラス設計が完成されていました。すごい。)

こうすることで、3.の段階でステージ上にどういうギミックが必要かの大枠が定まり、各アイディアの実装優先度の比較対象がカテゴリ内に限定されたため、時間の削減につながりました。

割りと妥当な決め方であったと思います。

この手順で実際に作成されたアイディアとその実装優先度は以下です。

f:id:zeal404:20170127022326j:plain:w200

かなり関係のないアイディアも並んでいますが、アイテム、HD起動(ヒップドロップ起動・・・)、設置型の3列で上から順に優先度の高い順に並んでいます。

ここで決まった案をもとに、二日目の朝にはもうひとりのプランナーの方が詳細仕様のたたき台を書き上げてくれたので、多少の修正をおこなっただけでほぼギミック詳細案が完成しました。

詳細案は以下です。

f:id:zeal404:20170128153359p:plain:w200

実際にゲームに登場した仕様①です。当初は上からヒップドロップで起動する形で考えられていましたが、わかりづらいのでカットされました。

f:id:zeal404:20170128153410p:plain:w200

実際にゲームに登場した仕様②です。ほぼ仕様どおりの内容になっています。後からバリエーション付けを狙って静止していないバージョンも作成しましたが、どちらも非常によく機能したと思います。

f:id:zeal404:20170128153413p:plain:w200

実現に至らなかった設置物の仕様です。優先度を落とした理由としては、モデルが必要になる、吹き飛ぶくらいの速度で回したら意味不明になるのでは、吹っ飛ぶ要因が衝撃波に集約されない、などでした。(たしか)

f:id:zeal404:20170128153417p:plain:w200

これもやりたかったですが実現に至らなかった仕様です。物理エンジンでカオス的な面白さを表現するにあたり、ステージ上の内容が動的に変化するのはそのままプレイバリューの増加に直結するので、拡張するとすれば是非入れたい要素です。

f:id:zeal404:20170128153420p:plain:w200

アイテムの仕様です。アイテムの実装作業は最終日まで進められていたのですが、難しいというところでステージギミックの作業に集中する変更が行われました。最終的な完成物を見ても、この判断で救われた面が大きかったように感じます。

f:id:zeal404:20170128153424p:plain:w200

f:id:zeal404:20170128153427p:plain:w200

f:id:zeal404:20170128153433p:plain:w200

その他、実装に至らなかった仕様たち


レイアウト

仕様とギミックが決まった後に、必要な画面レイアウトを洗い出しました。

画面数自体少なかったので、洗い出し自体は非常に簡単でした。

あとはシーンをいくつに切るのかをプログラマーと決めた上で各画面の担当を割り振り、ざっくりレイアウト仕様を書いた後にサイドプログラマーと実装のすりあわせを行ってFIXしました。

ここで作成した仕様書は以下です。

f:id:zeal404:20170128153603p:plain:w200

シーンと各画面の結びつきをまとめています。汚くて自分でも嫌になるレベルw

f:id:zeal404:20170128153616p:plain:w200

バトル中のレイアウトです。よくある仕様の集まりなので、特に気をつけることもなかったです。状態異常については実装を見越して書いていましたが、我ながら意味不明ですw

f:id:zeal404:20170128153621p:plain:w200

リザルト画面のレイアウトです。スマブラの丸パクリとも言います。この工数規模のなかでは割りと複雑な挙動を指定しましたが、バッチリ仕様書通りの実装で素晴らしいと感じました。レイアウト仕様などと言いながら、落とした/落とされたの判定という重要な仕様を付け足しているのがキモです。


まとめ

最後に、良かった点と反省して次回に活かしたい点をあげておきます。

良かった点
  • 楽しくゲームを作ることができた点
  • 多くの人に楽しんでもらうことができた、楽しんでいるところを実際に見ることができた点
  • 日常の業務と離れた作業で、自分のスキルに改めて気付けた点(工数感とか全体の洗い出しとか仕様書とか)
  • 今までつながりのなかった人と一緒にゲームを作ったりお酒を飲んだりして刺激になった点
反省点
  • ところどころプランナーの手が余ってしまうタイミングがあった

次に何をすべきか、何が足りていないかをイメージしておかないといけなかったのが、目の前の作業で手一杯になってしまったことで疎かになってしまいました。

それにより、とりあえず作業は終わったけど次は何をすればいいんだろう、という状況が発生してしまいました。

次回以降はざっくりでも全体のスケジュールを区切った上で作業をすすめることで、今何が足りていないかを意識しながら作業することで改善していきたいなと思いました。

  • リソースの指定漏れが多かった

終盤になってからSEの指定が大量に漏れていることが発覚しました。

ギミックやレイアウトの仕様を書いた段階で想定すべきだったので、次回以降はざっくり仕様にサウンドの項目を加えたいと思います。

全体として、今回「Global Game Jam 2017」に参加して本当によかったと感じています。

来年以降もずっと参加し続けていこうと思えるほど充実したイベントでした。