ゲームジャムのマネジメント

この記事は『ボイゲ Advent Calendar 2019』の2日目の記事です。1日目はかいふさんの『盛り上がってる！！「VOICEROID等二次創作ゲーム界隈」の話｜かいふ｜note』でした

ボイゲコミュニティのエンドコンテンツ「ボイゲジャム」に備えて、短期間でゲームを開発するときの考えを共有すべく書きました。ですので、ここでは1～2週間程度で行うゲームジャムを想定しています。対象読者はゲーム開発経験がいくらかあるけど、短期間開発だと上手くいかないぐらいのレベルを想定しています。短期間開発の実績？としては、過去には初回ボイゲジャムにて『Ankoro Hazard』、第4回にて『琴葉あのね』を製作しています。

• 計画フェーズ

  • コンセプトを決める
  • プロジェクトを計画する
  • 作業計画を立てる

• 開発フェーズ

  • 意外と長い開発期間とつきあう
  • トラブルに柔軟に対処する
  • 素材使いまわす
  • 定期的にビルドする
• おわりに

開発期間が始まったら実際に開発する前に計画に少しだけ時間を裂きましょう。

お題が決まって開発期間が決まったらまずはコンセプトを決めましょう。 コンセプトを決めることは、後の作業の取捨選択に役に立ちます。 コンセプトとはゲームで重視することです。10～20文字程度でゲームを表現できるのが理想です。

ゲームで重視したい事柄は製作者によって千差万別です。キャラクターのかわいさをアピールしたい、落ち着いたゲームにしたい、人と繋がれるゲームにしたい、難しいゲームにしたい...などなど。これらのコンセプトを実現するための手法は多岐に渡りますので、本記事ではコンセプトの実現の方法には触れません。一方で、ゲームを完成させることやゲームを多くの人に遊んでもらうための方法は、どんなゲームでも一様に適用できるものです。

ゲームのコンセプトが決まったら、コンセプトを元にプロジェクトの計画を立てます。 個人での開発であれば、どんなゲームにするか以外に、概ね、以下の事柄を決めれば良いと思います。

• 想定するプレイヤー

  • 特に、ゲーム初心者なのか熟練者なのか
• 使える時間
• ゲームの頒布形式

ごく短期間のプロジェクトになりますので、厳密にプロジェクト管理する必要はありませんが、どこかにメモっておきましょう。作業中にこれらの計画からズレたり、計画を変更したりすると一気に完成が難しくなります。

想定するプレイヤーは開発者自身に近いほど難易度が下がります。ですが、開発者自身は作成するゲームに特化して習熟することになるので、自身をプレイヤーと想定する場合、開発期間が始まる前の自分自身と設定しましょう。 自分と異なるタイプの人を対象にする場合、モデルケースとなる人をひとり決めましょう。その人にテストプレイを協力してもらえるとなお良いですね。

使える時間は想定していた時間よりも実際に稼働できる時間が少なくなる場合、完成はとても難しくなります。予めゲーム開発に集中できて邪魔の入らない期間を確保できるのが最適です[1]。

ゲームの頒布形式は、なるべくプレイヤーが気軽にプレイしやすいものが望ましいです。ゲームを遊ぶためにダウンロードやランタイムが必要なのは多くの人に遊んでもらうという観点からはあまり推奨されません[2]。PC向けならブラウザで、スマホアプリならAndroid,iPhoneの両方に対応するのが望ましいです[3]。いずれの場合もアプリ自体が軽量であればあるほど良いですね。

また、少しずつ積み重ねて開発する方法を推奨するので、「期間終了時に〇〇の機能が実装できている」などの品質にかかわる目標は立てない方が無難です。

いろいろな想定ができてきたら、次は大まかな作業計画を立てます。 時間が有限である以上、全てに時間をかけることはできません。

まずは、ゲームとして完成させるために必須の作業と、必須ではない作業を洗い出して分離します。必須の作業は以下で、これ以外のものは無くてもゲームとして成り立ちます。

• インゲームの基本メカニクス
• リリースのためのビルドおよびアップロード
• マニュアル等のドキュメント作成

基本メカニクスとは、ゲームがゲームとして成立するためのゲームの仕組みです。どこまでが基本でどこからが基本でないかは判断しづらいですが、ゲーム上の状態の変化ごとに1メカニクスとカウントするのが良いと思います。ジャンプボタンでキャラが縦方向に移動すると1メカニクス、アイテムに触れてスコアが加算されると1メカニクス...。短期間開発では2～4メカニクスぐらいを目安にすると良いと思います。おそらくそれ以上はゲームとして成立するために必須ではないでしょう。

ビルド作業やドキュメント作成は慣れていなければ意外なほど時間がかかります。計画段階で時間がかかることを織り込んでおきす。

必須でない作業も洗い出して、以下に分類しておきます。

• ユーザーフレンドリーの作業
• コンセプトを実現するための作業
• その他の作業

ユーザーフレンドリーの作業は、プレイヤーが遊びやすくするための配慮に相当する作業です。ここに分類される作業は多く、アウトゲームの実装、チュートリアルの実装、エフェクトや効果音などの演出系、BGMの追加、UIのレイアウトなど、多岐に渡ります。いくつかの作業項目は後述のコンセプトを実現するための作業と重複します。

コンセプトを実現するための作業は、立てたコンセプトを実現するためのゲームデザインや素材を用意する作業です。例えば「かわいい茜ちゃんのゲーム」を作るときは、プレイヤーキャラクターをかわいい茜ちゃんにしたり、かわいいモーションを作る作業がこれにあたります。

その他の作業は以上に該当しない作業です。ここに分類されるものは「あった方がいい」作業になりますが、短期間の開発ではここに分類されたものは全て切り捨てます。多くの場合において、ボリュームやバリエーションはここに該当します。

まずは全体の6～7割をマージン期間に割り当てます。 慣れてくれば見積もりの精度が上がり、もっと少ないマージンで計画を立てても完成させることができるようになりますが、慣れないうちは期間全体の6～7割程度はマージンに当てましょう。期間が1週間ならゲームは2～3日で作ってください。それぐらいを想定しないと無理です。

次に必須の作業を見積もって時間を割り当てます。もし、この時点でマージン期間を除く期間を食いつぶしてしまうような計画だった場合、作ろうとしているものは短期間開発に向きません。もっと企画をシンプルにしてみてください。

最後に残った作業時間にコンセプト実現の作業とユーザーフレンドリーの作業をバランス良く割り当てます。ここでコンセプトを重視すると尖ったゲームになり、ユーザーフレンドリーを重視すると遊びやすいゲームになります。もちろん全てのタスクが消化できるのが望ましいですが、そんなことはまずありません。優先度を決めてこれと思うものから順番に割り当てることになります。

ユーザーフレンドリーの作業の優先度のヒントとして、以下の作業優先度を上げると時間対効果が高く、一見してクオリティの高いものに仕上がりやすいです。

• 一般的なゲームが当然のように実装しているもの

  • アウトゲーム
  • BGM

• ユーザーへの細部のフィードバック

  • エフェクト
  • 効果音

ここで入れきれなかった作業はどこかに残作業リストとしてストックしておきます。マージン期間が余ったらここから優先度の高そうなものをピックアップして実装してクオリティを上げます。最初の計画時点ではマージン期間を使ってはいけません。

計画が終わったら、ようやく開発に入ります。 とはいえ、開発は計画で洗い出した作業を淡々とこなせばゲームは完成するはずです。しかし、そううまくはいきません。

1～2週間というのは短いようでとても集中が維持できる期間ではありません。

開発期間中、常に全力を出し続けることはできないことに留意しましょう。ほとんどの人はゲーム開発以外にも予定があることでしょう。それに、仮に全力を出し続けて開発期間中は高いパフォーマンスを発揮できたとしても、開発期間後には必ず失速してしまいます。ゲームジャムが終わった後、ほとんどの場合は期間中にできなかったブラッシュアップをするでしょうし、開発期間後も大切な時間です。

マラソンで開幕ダッシュをするような全力の出し方をせず、生活に支障が出ない程度に開発しましょう。

計画どおりに作業が進めばみんなゲームを作れるはずですよね。ゲームが完成しないのはなんと計画通りに作業が進まないからなのです！

作業を始めると予想よりも時間がかかることがあります。幸いにも作業を始めた直後にこの事実に気付いた場合、その作業が必須項目である場合を除いて、後回しにしてしまいましょう。

途中で気付いた場合も途中まで進めたのに勿体ないという気持ちを抑えて、無かったことにしてしまったり、自動化してしまった方が結果上手くいくことが多くあります。勇気をもって切り捨てましょう。

ちなみに個人的にこの状況に陥りやすいタスクは、文章やデータの入力をするときです。特にデータ入力は思ったより時間がかかることが多い印象です。

通常、バグが出ることを予め予測することはできません。なので、解決困難なバグが発生すると計画が狂いやすいです。致命的なバグでない場合は、バグは無視することを推奨します。

バグを修正する作業は計画の中ではユーザーフレンドリーの作業に分類されます。短期間開発においてはバグを修正する作業と他に新しく実装する作業を比べたとき、よっぽど酷いバグでない限りプロダクト全体に与える影響は後者の方が大きいはずです。開発者が思っているよりもバグの影響は小さいんです。

とはいえ、ゲームが落ちるとかプレイヤーを破壊するようなバグの場合は他の作業より優先順位が高くなりますよね。

開発中にバグが見つかったり、計画中に見落とした作業が見つかることがあります。そのような作業はすぐに着手せずに最初に計画したときに作成した残作業リストに追加しておきます。

計画に乗せた全ての作業が終わったら（あるいは全ての作業が終わらなくてもキリの良いタイミングで）残作業リストから優先度の最も高いと思われるものをひとつピックアップして、計画に載せます。

マージンを大きくとり、タスクをひとつづつ計画に載せることで、ひとつの作業が終わる度に優先度の高いタスクを処理することになるので、変化に強い柔軟な開発計画を手に入れることができます。[4]

開発を進めていると素材が必要になります。もちろん自分で用意しても構わないのですが、短期間で全ての素材を自前で揃えるのは無理でしょう。ゲームジャムは素材を利用するのが前提となっています。

素材ですが、テーマに沿った素材を探すのは意外なほど時間がかかります。ですから、使う素材を減らすという対策と予め用意しておくという対策が必要になります。

まずはUIは、素材が無くても作れるようなものが理想です。 具体的にはフラットなシンプルなデザインのボタン等であれば、素材が無くてもスクリプトからプロシージャル生成できるかもしれません。

例えば、『琴葉あのね』のUIパーツはほとんどがプロシージャル生成です。

他にも効果音は同時に鳴らしたりピッチシフトやフィルターをかけることで印象を変えられます。私がよく使うのは、「基本音」＋「正解音」でプレイヤーが小さな成功(スコアを獲得)を表現し、「基本音」＋「ダメージ音」でプレイヤーの小さな失敗を表現する効果音を作る等です。 先の『琴葉あのね』でもパネル置き換えの時の音が成功時は「パリン」＋「ピロン」となっていて、失敗時が「パリン」＋「ドゴッ」という音の組み合わせでできています。

また、少ない素材でも音ハメやスクリプト制御による動きを合わせることで、結構見れるようになったりします。色々なテクがありますが、基本はプログラム制御と遷移と組み合わせによる少ない素材の使いまわしです。もしスクリプトに強くないなら素材を作ったり集めたりした方が早いかもしれませんね。

どんなゲームでも使いまわしが効く素材は予めストックしておきましょう。 個人的に使いまわしやすいと思う素材は以下になります。

• フォント
• エフェクト
• 効果音
• 背景
• スクリプト

これらの素材は予め良く使うものやお気に入りのものをストックしておくと、いざというときにスムーズに進められます。

なるべく本番に近い環境で定期的に動作を確認しておきましょう。いざビルドしてみると開発環境と動作が違う...ということが結構あります。ビルド時間にもよりますが、1日1回ビルドするぐらいの間隔が良いと思います。ついでにビルドした環境を公開してフィードバックを貰える仕組みを作っておくとなお良いです。ゲーム自体を公開しなくても、ビルドしたもので動画を撮ってアップロードするのを日課としても良いですね。

本当は期間の前後にやっておくと良いことがいっぱいあります。しかし、記事がとんでもなく長くなってしまうので割愛しました。もっと色々知りたいと思うなら、是非プロジェクトマネジメントを学んでください。ここで書いたことは、プロジェクトマネジメントの技法を自分用にゲームジャム向けにアレンジしたものです。持論なので、是非自分だけの開発技法を確立して、教えてください。

なんやかんや色々書きましたが結局のところ楽しんで開発するのが一番かと思います。 仮にうまくいかなくても浪費するのは1,2週間ですから、気軽に挑むのがいいでしょう。

2020年のゲームジャムでも楽しくゲームを作りましょう(お題回収)！