はじめに
前回までで、タスクの作成方法について学びました。今回は、タスクを作成するマネージャーに向けて、どのようなタスクを追加すればよいのかのヒントを与えるため、タスクの特徴について書いていきます。
タスクの特徴
ゲーム開発におけるタスクには様々なものが存在します。仕様を決める際には、マネージャーがタスクごとの重さを考えて、出来るだけ軽い作業になるよう工夫したり、重い作業を1個以上に増やさないようにしましょう。同人プロジェクトの開発物についていうと、基本的には、複雑な大作より、良い感じに動くミニゲームの方が周りに楽しんでもらえる確率は高いです。
##炎上しやすいタスク
###複雑・少数
炎上しやすいタスクは「完成度が100%か0%か2択で、完成度80%は0%にカウントされる」という性質を抱えています。
具体例を挙げると、「戦闘システムが、自分の攻撃だけ完成しました」といった状況では、納品が出来ません。相手の攻撃も要りますし、アイテムを使ったりすることもあるでしょう。全部作らないと作っていない場合と同じという特性を持っています。
そして、このようなタスクは、分業が難しいタスクでもあります。なぜなら、システム内の多数の変数や関数が、相互に複雑に関連しあっているためです。本質的に複雑で巨大なシステムは、個々人で脳内の設計が異なりますし、分業のためのインターフェースの作成も難しいのです。
###自作のみ
複雑性が上がれば上がるほど、金の力で何とかならないような仕様が増えていきます。
「独特のシステム」「新感覚○○」などは非常に危険です。同人プロジェクトのゲームの独創性は、システムよりフレーバー面で出すことを勧めます。具体的には、「ハロウィンをテーマにする🎃」などゲームの雰囲気を重視した独創性を入れた方が、炎上確率は下がります。(ハロウィンに独創性はないですが...)
###依存関係が多い
「Aが終わらないとBが出来ない」というようなタスクは、炎上を生みやすいです。なぜなら、待ちが発生しやすいからです。仕様を作成したら仕事を割り当てる計画が必要ですが、依存関係がある仕事を受け持った人のモチベが枯れた場合に、その影響が外部に波及して、モチベのある人間の仕事を阻害するのです。この状況が起こると、他の人間のモチベが死んだり、仕事をしない人を非難したりしてチームの雰囲気が最悪になります。
また「待ち」の解消はマネージャーの仕事でもあるので、マネージャーの過労およびモチベーション消失にもつながります。
変更が多い
当たり前の話ですが、仕様が頻繁に変更されることが予想される、「ふわっとした要件」は炎上します。「なんかいい感じに戦う敵AI」などがいい例で、実装方法が何通りも考えられ、うまくいかなければ様々な実装を試す必要が生まれるのです。
時間が予測しにくい
ズルズルと開発が遅れまくる
具体例
以下のような、ルールの複雑さによってゲームの面白さを担保するようなものは、炎上するタスクを生みやすいです。
- プロシージャル系統(自動生成ステージなど)
- 賢いAI全般
- リアルタイム通信
- 格ゲー
- 3Dアクション
- 独特なシステムゲー(時間操作とか、磁石アクションとか、流体○○とか)
- レースゲーム
- 物理が絡むゲーム
- 本格シミュレーション
ただし、これらのうちそこそこのパターンが、「金でシステムを買う」という方法で対応することが可能です。お金での解決を選んだ場合には、難易度は一気に下がるでしょう。逆に、「自作ゲームで賢い敵AIを作りたい！」とか「当時の社会システムまで模倣したシミュレーションを作りたい」とかの要件の場合は相当厳しいプロジェクトが予想されます。
##炎上しにくいタスク
###単発・多数
キャラクターのステータスを生める単調作業を無限にする、といったタスクです。これはこれで特有の辛さがあるのは事実です。しかし、キャラの数を30から15にすることは可能ですし、シナリオの場合も無理やり終わらせれば10話構成を5話構成にすることが可能です。
つまり、完成度が100%から0%まで連続的な値をとるというのが「単発・多数」という性質の意味です。
さらに、多数の独立した仕事から構成されているので、複数人で一気に仕上げることもできます。
###代替可能
いったん仮の素材で埋めてしまえるタスクです。例えば、カードゲームの場合、大量の2D画像を使う必要がありますが、いったん適当な素材で埋めて余裕があれば自作するという手が取れます。
金の力での誤魔化しがきくタスクは、炎上する前にお金で火を消せます。
###依存関係がない
理想的な順番にタスクの依存関係を並べます。上のタスクが多いのがいいんですが、もちろんゲームである以上、下のタスクも存在します。最初に「骨」を作ろう！というのは、「モチベーションという資産をゲーム全体の完成を左右する部分にフル活用しよう」という目的のスローガンです。
- 「機能Aがなくてもゲームは完成する」：サブクエスト的なもの。ゲーム全体で希釈されるため、機能Aがなくてもプレイヤーは気づかない
- 「機能Aがないと機能Bがしょぼい」：戦闘における必殺技システムなど。無くなってしまうと、機能Bという範囲内で機能Aが消えるので、機能不足に気づかれてしまうが、プレイ自体に支障はない
- 「機能Aがないと最終的にゲームが完成しない」：依存関係があるものの、その被害・待ちが発生するのはゲーム開発終盤である
- 「機能Aがないと機能Bへ進めない」：依存関係があるが、最悪機能Aを別の人に交代させれば機能Bからはまっさらな状況から開発できる
- 「機能Aが巨大」：依存関係がある上に機能A内部で中途半端に開発が行われていた場合、負の遺産として残り続ける
具体例
以下のような、コンテンツの多さによってゲームの面白さを担保するようなものは、炎上しにくいタスクを生みやすいです。
- RPG
- シナリオゲーム
- カードゲーム
- 多数のステージ
- キャラゲー
- 多数のユニット
#おわりに
特定のタスクの難易度が上がってしまうのは仕方がないことです。独創性のあるアイデアというのは、やはり複雑なものです。なぜなら単純なアイデアなら誰かがやっているからです。したがって、複雑性のあるタスクをむやみに避けるのではなく、複雑性の要因のうち一部を我慢する(例：一部のシステムは購入して改造で出来る範囲に仕様変更)ことでメリハリをつけることが重要です。