Foundこの広告は、90日以上更新していないブログに表示しています。ゲームジャム」に参加してきました。ゲームジャム」についての自分用の振り返りメモとして考えたこと・やったことをまとめた記事です。2017」については以下の記事でまとめています。ゲームジャム」会場の試遊会で撮影されたものです。音声も会場のものがそのまま録音されているので、会場の盛り上がりが伝わると嬉しいです。この記事で一番書きたかったことかなり長くなってしまったので、書きたかったことを2点にまとめました。レベルデザインについて今作のレベルデザインでは、プレイヤーの段階的な学習を誘導するデザインになるよう心がけました。具体的には、各ステージに行動の学習+行動の最適化の2段階の学習ステップを用意し、ただクリアするだけでなく最適化を進めるところまで誘導することを狙いました。学習ステップについては、例えば、ステージ2ではジャンプを使うことでステージをクリアできます(行動の学習)が、あえて最初にジャンプせずに次の足場に移ることで時間が節約できます(行動の最適化)。普通にクリア出来てしまうステージをわざわざ最適化してプレイするとは考えられません。そこで、本作ではステージ4に最難関となるステージ(羽根の回るステージ)を置きました。最難関のステージをゲームの終盤に置くことで、道中で上記のような最適化テクニックを見つけて時間を節約し、試行錯誤の回数を増やす必要がある、という流れを作るためです。会場では激ムズと言われまくりましたが、デザイン上は大体狙い通りであったわけです。このように、各ステージをただクリアすればOKな対象ではなく、時間を短縮するためにプレイヤーが解を探すゲームにすることで、ゲームの奥行きを出すようにしています。実際、会場での試遊でも最後には最適化した戦略を持って挑んでくださった方も居たので、ある程度狙いは成功したように思います。実際のステージでプレイヤーに学習してもらいたかった狙いを書いていくと以下のようになります。解を覚えるこのような流れになっていました。ステージ設計について今回は後からバランスを調整する時に楽ができるよう、各ステージで失敗したときの被害の大きさを見積もることができるようにしていました。ステージの最小クリア時間4秒+ギミッククリアにかかる時間=レベルクリアにかかる時間であるため、バッファは60-(レベルクリアにかかる時間×5)になります。1ステージ10秒クリアの場合、1回死んだらカツカツになりますが、5秒クリアであれば数回死んでも余裕でクリアできるくらいの余裕ができます。今回は時間が短かったのもあって通しプレイがほとんどできずかなり難しいゲームになってしまいましたが、それでもゲームとしてギリギリクリアできるバランスに収まったのは、この設計が根底にあったからだと考えています。(https://twitter.com/yashinut)の3名でした。2017」では7名での開発だったので、今回はチーム規模がかなり小さくなりました。作成サウンド周りのリソース収集レベルデザイン案出しレベルデザイン(ステージ4~5)進行管理っぽいこと(?)企画内容チームが決まってからチームメンバーでお昼を食べながら色々と企画について話し合いました。その中で、ギミックの配置されたステージを60秒以内にクリアするゲーム、という方向性が浮かんだので、それに基づいて仕様を作成しました。2017」に引き続き、今回も紙に仕様を書いていく形で作業を進めました。紙に仕様を書くメリットはざっくり以下の2点であると考えています。メリットノートPCでデスクトップの表示領域が限られるため、紙渡しの方が邪魔にならない(裏に戻ったりせずに済む)仕様に簡単な図を入れたり加筆修正したりといった作業が(こだわらなければ)楽且つ早いつまり、今回は紙に仕様書を書くことによって「仕様がないせいで実装者の手が止まってしまわないようにすること」と「作業者に負担をかけないようにすること」を意図していました。実際、開発が終了後に同じチームの方から紙仕様書が良かったという意見もいただいたので、ある程度狙い通り機能したかなと考えています。このようにゲームジャム向きの特性を持つ紙仕様書ですが、一方であえてデメリットを挙げるならば以下の2点が上げられると考えています。デメリットデジタル化が面倒ゆえに、検索性、一覧性の面で劣る(今回は全部スマホで撮影してSlackにアップしましたが、見づらく、失敗でした。)ひとつの仕様を複数人で担当する際に不便これらのデメリットについてもわからないではないですが、(仕様担当者が妥当な管理をおこなえば)少人数で仕様毎に担当を割り振ることの多いゲームジャムではそこまで問題にならないと考えています。実際に書いた仕様書ここからは、実際に書いた仕様書を時系列順に見ながら考えたことなどを書いていきたいと思います。かなりの悪筆なので読みにくかったりすると思いますが、ご容赦ください。今回のゲームジャムでの作品の概要をまとめたものです。当初は今の形よりもかなりギミックに重点をおいていたことがわかります。書きながら、「あれ?でもこれ60秒でクリアできる謎作るの難しくね?」と思ったのを覚えています。「キャラ」プレイヤーキャラクターについての仕様をまとめたものです。後に書く仕様書と同じように、左上に見出しをつけることでパッと見で何に関する仕様書かわかるようにしています。工数削減を狙ってサードパーソンテンプレートをそのまま使用するようにしました。あわせて、移動速度、ジャンプなどもデフォルトを指定しています。これは決してサボったわけではなく、多くの人が一度はプレイしたことがあり、基本操作や今作で重要になる操作感に対する学習コストが低いことを見越したものです。「ステージ全体構成」ステージの設計をまとめたものです。この時点では色んな死に方をさせるプレイを想定していたことがわかります。ステージの広さはデフォルトレベルの広さとほぼ同じです。デフォルトレベルで実際に計測してみると端から端が4秒くらいだったので、ステージ設計上色々と都合が良いということで採用しました。ステージ数は上記の4秒を基準に、3人で作れるステージ数の上限&ギミックをクリアする時間のバッファを考慮して5ステージとしました。2017」でも作成したリソース表みたいなのを手元で書き散らしたものです。どれくらいの分量を用意しないといけないかを見積もるときに使用しました。Sheet上にリソース表を作成して共有しました。スプレッドシートよく漏れるライセンス関係も一緒に管理していると楽ですね。全体の画面遷移をまとめています。「どのゲームでもだいたいこんなもんやろ」という感じですが、こういうのを書くのは認識をすり合わせるためにとても大事だと思います。(とは言え、この仕様書は遷移ルールちゃんと書いてないの我ながら本当にクソなので真似しないでください。)「ギミック」ステージ4、5で出てきたボタンと実装できなかった電気のギミックです。今回、ステージ内で完結するギミックについては共通化するより個人の責任において自分で実装する方が圧倒的に早いなと思いました。ここについてはUE4を使ったチーム開発/ゲームジャムの経験の有無が大きく影響しそうに感じました。案出しの意味を込めてかなりの枚数を書きました。各レベルでのプレイヤーに学習してほしいこと、目標秒数、ステージの大まかな構成と詳細をまとめています。これらの意図については冒頭に書いたとおりです。最後にこのような素晴らしいイベントを開いてくださった株式会社ヒストリア様をはじめ、協賛各社様に深く感謝いたします。本当にありがとうございました。2017」にプランナーとして参加してきました。Jam」への参加は初めてだったので、参加して感じたことと、実際に書いた仕様書などのドキュメントを公開します。基本的には自分の考えたこと・やったことの振り返りですが、今後ゲームジャムに参加しようと思う方の参考になれば幸いです。はじめに書いておきますが、糞長いです。関連として、同じチームで一緒にゲームを作ったとりすーぷさんのQiita記事が公開されているので、そちらも合わせて読むとより面白く読めると思います。この記事のなかでも適宜参照しています。WAVE作成したゲームについてお題の「WAVE」を衝撃波と解釈し、マッチョがヒップドロップした衝撃波で敵を場外に吹き飛ばすゲームを作成しました。何を言っているかわからないと思うので、サマリーと動画を用意しました。今回完成したゲームは以下です。Drop(GGJ2017)なんとなくどういうゲームか察していただけたかと思います。表現したかったのはヒップドロップで敵をふっ飛ばすときの爽快感です。モーションが間に合わず女の子っぽい走り方になっていたり(ユニティちゃんSDモデルのデータを借用)、もはやヒップドロップではない点を除けば割りとコンセプトに忠実にできていると思います。Jam」ではイベントごとに毎回異なる「お題」が提示され、ジャムで作成するゲームの内容は必ずその「お題」に基づいて制作する必要があります。この「お題」は割りと広い解釈が認められるので、こじつけ的なものもOKなようです。1名ジャムを終えて振り返ってみると、割りとバランスの良い構成だったように感じました。Storeのパワーでなんとかなりました。担当した箇所は以下の通りです。抜けや忘れてしまっている箇所があるかもしれません。共同の記載はもうひとりのプランナーの方と共同で全体をまとめた部分、それ以外は担当した部分です。ゲーム内容の企画ギミック案出し(共同)ギミック仕様作成(共同)レイアウト仕様作成(バトル、リザルト)サウンド周り(BGM,SE選定)パラメータ調整(キャラ挙動)レベルデザイン(共同)見ての通り、普段のゲーム開発で行っているような作業を一通り行っていることがわかります。その意味で、ゲームジャムであってもプランナーに求められる能力は基本的に変わらないようでした。※スケジュールについてはプログラマーの方にまとめていただきました。普段のゲーム開発とは違い、ゲームジャムではどの仕様を詳細化してどの部分をざっくりとしたものにするかの判断が求められるように感じました。そのため、この項では主にどう考えたか、どうやって判断が行われたかを書きます。ゲームのメインロジック(キャラの挙動・ふっ飛ばしの部分)ゲームの核となるメインロジックについては、Unityの物理エンジンを使うことが企画段階で決まっていました。細かい部分の挙動まで指定・実装していた場合、時間が足りない物理エンジンの予想しにくい挙動自体である程度のウケが狙えるそのため、企画発表が終わって制作に移るタイミングでどのようなパラメータを必要とするかの認識をプログラマとすりあわせた後はほとんど指定することはなく、終盤(確か二日目の夜)に実装されたキャラクターを動かしながら調整した程度でした。物理エンジンで理想の挙動を表現することが思っていたより難しく、プレイヤーの挙動についてはまだまだブラッシュアップの余地のある出来になってしまいました。現時点での私のスキルではトレードオフにならざるを得ない部分でしたが、慣れてしまえば48時間でももうちょっとマシな出来になりそうではあります。ギミック(衝撃波の伝播、即死トゲ)企画の段階でステージ上にギミックを置きたいよねという話になっていました。プログラマーの要請に応えて実装したいギミックのリストを書き出しました。前述のとりすーぷさんの記事でも言及がありましたが、アイディアを後出しで入れることは現実的に不可能であると伝えられていたため、プランナー二人で結構な時間を割いた覚えがあります。具体的には、以下の手順で実装したいギミックを決めていきました。プログラマと相談(このあと翌朝までに仕様の実装に耐えうるクラス設計が完成されていました。)こうすることで、3.の段階でステージ上にどういうギミックが必要かの大枠が定まり、各アイディアの実装優先度の比較対象がカテゴリ内に限定されたため、時間の削減につながりました。割りと妥当な決め方であったと思います。この手順で実際に作成されたアイディアとその実装優先度は以下です。関係のないアイディアも並んでいますが、アイテム、HD起動(ヒップドロップ起動・・・)、設置型の3列で上から順に優先度の高い順に並んでいます。ここで決まった案をもとに、二日目の朝にはもうひとりのプランナーの方が詳細仕様のたたき台を書き上げてくれたので、多少の修正をおこなっただけでほぼギミック詳細案が完成しました。実際にゲームに登場した仕様1です。当初は上からヒップドロップで起動する形で考えられていましたが、わかりづらいのでカットされました。実際にゲームに登場した仕様2です。仕様どおりの内容になっています。後からバリエーション付けを狙って静止していないバージョンも作成しましたが、どちらも非常によく機能したと思います。実現に至らなかった設置物の仕様です。優先度を落とした理由としては、モデルが必要になる、吹き飛ぶくらいの速度で回したら意味不明になるのでは、吹っ飛ぶ要因が衝撃波に集約されない、などでした。(たしか)これもやりたかったですが実現に至らなかった仕様です。物理エンジンでカオス的な面白さを表現するにあたり、ステージ上の内容が動的に変化するのはそのままプレイバリューの増加に直結するので、拡張するとすれば是非入れたい要素です。アイテムの実装作業は最終日まで進められていたのですが、難しいというところでステージギミックの作業に集中する変更が行われました。最終的な完成物を見ても、この判断で救われた面が大きかったように感じます。その他、実装に至らなかった仕様たちレイアウト仕様とギミックが決まった後に、必要な画面レイアウトを洗い出しました。画面数自体少なかったので、洗い出し自体は非常に簡単でした。あとはシーンをいくつに切るのかをプログラマーと決めた上で各画面の担当を割り振り、ざっくりレイアウト仕様を書いた後にサイドプログラマーと実装のすりあわせを行ってFIXしました。ここで作成した仕様書は以下です。シーンと各画面の結びつきをまとめています。汚くて自分でも嫌になるレベルwバトル中のレイアウトです。ある仕様の集まりなので、特に気をつけることもなかったです。状態異常については実装を見越して書いていましたが、我ながら意味不明ですwリザルト画面のレイアウトです。スマブラの丸パクリとも言います。この工数規模のなかでは割りと複雑な挙動を指定しましたが、バッチリ仕様書通りの実装で素晴らしいと感じました。レイアウト仕様などと言いながら、落とした/落とされたの判定という重要な仕様を付け足しているのがキモです。まとめ最後に、良かった点と反省して次回に活かしたい点をあげておきます。反省点ところどころプランナーの手が余ってしまうタイミングがあった次に何をすべきか、何が足りていないかをイメージしておかないといけなかったのが、目の前の作業で手一杯になってしまったことで疎かになってしまいました。それにより、とりあえず作業は終わったけど次は何をすればいいんだろう、という状況が発生してしまいました。次回以降はざっくりでも全体のスケジュールを区切った上で作業をすすめることで、今何が足りていないかを意識しながら作業することで改善していきたいなと思いました。リソースの指定漏れが多かった終盤になってからSEの指定が大量に漏れていることが発覚しました。ギミックやレイアウトの仕様を書いた段階で想定すべきだったので、次回以降はざっくり仕様にサウンドの項目を加えたいと思います。2017」に参加して本当によかったと感じています。来年以降もずっと参加し続けていこうと思えるほど充実したイベントでした。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。