トップ > 開発全般 > エイプリルフールイベントを事例に短期開発のために抑えたポイントをまとめてみた

エイプリルフールイベントを事例に短期開発のために抑えたポイントをまとめてみた

開発全般

サムネイル

はじめに

今回は、4月1日に「戦国炎舞 -KIZNA-」で実施されたエイプリルフールイベント「ぶろっくえんぶ -打倒！大ブロック天魔王-」(以下、ぶろっくえんぶ)を事例に短期開発のために抑えたポイントを書いていこうと思います。

「ぶろっくえんぶ」とは

実際にプレイしていない方に向けて、簡単に説明したいと思います。

ぶろっくえんぶは、戦国炎舞をモチーフに使用したブロック崩しです。
基本的な動作は一般的なブロック崩しと大体同じですが、Wave制で区切られたステージ(難易度)を進行していきます。
Wave内の全てのブロックを壊すことで突破でき、全てのWaveを突破するとステージクリアです。
ブロックには耐久値が存在し、戦国炎舞らしい「スキル」や「奥義」を駆使して、効率良くブロックを壊してステージクリアを目指し、ハイスコアを狙うゲームです。

ブロック炎舞 ブロック炎舞_プレイ画面

背景

ぶろっくえんぶの開発期間はモック開発含め1ヶ月程でした。
その間、C#バージョンアップを並行して対応していたため、実際はもっと短かったかと思います。

エイプリルフールイベントという事もありスケジュールを後ろ倒しに出来ない中、いかにリリースまで持っていくかを考えて抑えたポイントがあります。
実際、このボリュームを短期間でリリースまで漕ぎ着くことができ、無事リリース出来たので、短期開発のために抑えるポイントとして参考になればと思います。

モック作りで抑えたポイント

モック作りで抑えたポイントは下記3つです。

  1. ブロック崩しに必要な最低限の機能は実装する
  2. 早めの判断をしたい機能はモックの段階で実装する
  3. (良し悪しは別として)エンジンに任せられるものは一旦任せる

この3点を抑えることで、ぶろっくえんぶのモック開発期間は2,3日で完了させました。

１. ブロック崩しに必要な最低限の機能は実装する

ブロック崩しで最低限必要な機能としては下記と考えました。

  • ボールが反射される事（バーとの反射,壁との反射,ブロックとの反射）
  • ボールとブロックが衝突した際にブロックが壊れる事
  • スコア加算がされる事
  • バーの操作が出来る事

AssetBundleからのリソースロードやステージ生成,WIN/LOSE処理は後回しにし、ボールが下に落ちても反射するようにしました。
モック時に使用した画像はほどんど既存リソースで対応しました。

理由として、実際にプレイした触り心地や方向性の共通認識と、早めにGO判断のジャッジを出来る状態にして厳しそうな場合にすぐ方向転換出来るようにするためです。

２. 早めの判断をしたい機能はモックの段階で実装する

実際にプレイしてみないと判断出来ない機能は、モック段階で実装しました。
今回、早めに判断したかった機能は下記でした。

  • バイブレーション機能

ボールが落ちた時やブロックを壊した時など、想定されるタイミングは様々ですが、プレイ中に振動するのは邪魔にならないかの懸念があり、早めに判断したい項目でした。
結果として、本番には振動する機能は組み込まれないことになりました。

３. (良し悪しは別として)エンジンに任せられるものは一旦任せる

モック開発の目的は様々ですが、今回のモック開発の目的は「本当にブロック崩しで面白いのか、どこまで実装しきれるのか」だったので、早めに方向転換の判断が出来ようにプレイできる状態のアプリケーションが必要でした。
全てを実装するとモック開発の期間が延びてしまうので、ボールの移動周りや当たり判定の発火部分はエンジンに任せるように実装しました。
エンジンに任せられるものは一旦任せることでモック開発の時間を削減し、早めにプレイできる状態まで持っていきました。

本開発で抑えたポイント

本開発で抑えたポイントは下記4つです。

  1. ギリギリまで調整したいパラメータ系はアセバン化orCSV化する
  2. ステージのレベル設定するための機能は最小レベルでも用意しておく
  3. プランナーが調整するパラメータとほとんど調整しないパラメータは持ち方をなるべく分離する
  4. 周りを巻き込む

この4点を抑えることで、ぶろっくえんぶの本開発期間は3週間+αくらいで完了させました。

１. ギリギリまで調整したいパラメータ系はアセバン化orCSV化する

開発工数削減でパッケージに含めてしまうと、ギリギリまで難易度調整が出来なくなってしまいます。
その為、パッケージ申請後でも更新が出来るようにCSV化してAPIから受け取るようにしたり、ScriptableObjectでアセバン化してデータ更新をギリギリまで出来るようにしました。

２. ステージのレベル設定するための機能は最小レベルでも用意しておく

最初はステージ構成をCSV管理にしようかとも思っていました。
ただ、難易度調整は頻繁にTry&Errorを繰り返して微調整していくものなので、直感的に配置が出来た方がミスも減り分かりやすいだろうと考え、エディタ拡張して簡単な機能は用意しました。

  • ブロックの追加/削除
  • ブロックの一覧化
  • ブロック毎のパラメータ設定
  • ステージデータのインポート/エクスポート

など

３. プランナーが調整するパラメータとほとんど調整しないパラメータは持ち方をなるべく分離する

ヒューマンエラーによって余計なパラメータを変更しないように、調整頻度でデータの持ち方を分離しました。
難易度調整で頻繁的に更新するスキル排出率とステージ構築データはCSV,ScriptableObjectでまとめられています。
スキル効果や奥義効果は更新頻度多くないので、各種別毎にScriptableObjectとしてデータを持つようにしています。
実際にプレイ中に更新して調整したいボールの速度などはDefineクラスとして定数化してプレイ中にデバッグメニューで調整も出来るようになっています。

これによってデータの設定ミスは、あまり発生しませんでした。
設定ミスが頻繁に発生するような作りになっているとTry&Errorの回数が余分に増えるので、意外と工数削減に後押しした気がしています。

４. 周りを巻き込む

モック開発の段階では一人で実装していました。
ただ、プレイできるレベルまでのモック開発を2,3日で実装してしまったせいか、仕様のボリュームがだんだんと多くなってきたので、周りを巻き込むようにして進めました。
結果的に仕様をほぼ落とすことなく、寧ろ追加仕様も組み込んだ上でリリースまで漕ぎ着くことが出来ました。

一つの施策に対して人数を増やすと各々のスケジュール管理が必要になりデメリットもあるように感じます。
ただ、実装の抜け漏れを片方が拾ったり、設計の相談もしやすくなったので、一人でコツコツやらずに周りを巻き込む方が今回の場合はメリットが大きかったです。

まとめ

ここまで短期開発のために抑えたポイントを書いてきました。
短期開発で特に重要なポイントを簡単にまとめると、この3点だと思います。

  • Try&Errorのイテレーションを早くまわす
  • 不具合を出さないような配慮
  • 周りを巻き込む

求められる結果は同じでも実装方法は複数パターンあるので、個人的には短期開発関係なくTry&Errorのイテレーションを早く回すことに関しては常に大事だと思っています。