皆さんこんにちは！トイロジックプログラマーのO野です。今回は、プログラマーがアクションゲームのギミック実装タスクをひとつ終えるまでの流れについて紹介します！

プログラマーの実装タスクと聞くと、「仕様書で書かれた通りに実装して終わり！」と思ってしまいがちですが、実際はそうではありません。ゲームを面白くするため、また効率よく開発を進めるために、実装するだけにとどまらない仕事もあったりします。これらを意識しないまま工数を見積もると、いざ取り組んだときに「思ったよりやることがあって期間内に終わらない！」なんてことにもなり得ます。（自分はなりました）

この記事では、ひとつのタスクを終えるまでをざっくり3つのフェーズに分けて、それぞれどのようなことをするのか紹介していきます。
他セクションとの相談や工数見積もりの際に、実際にプログラマーがどんなことを意識、想定しているのかをイメージする取っ掛かりになればうれしいです。

※今回紹介する内容はあくまで一例です。タスクの流れは、プロジェクトや状況によって変わる可能性があります。
 

①相談フェーズ

このフェーズ開始時点では、「〇〇なギミックを作りたい」のような概要レベルの内容しか決まっていません。ここから各パートの関係者で相談を重ねて、詳細な仕様を詰めていきます。
 

仕様相談

まずは、プランナーが今回実装するギミックについての仕様を作成します。

ここで「ギミックがどんな挙動をするか」「演出のためにどんなリソースが必要か」などの方針が決まっていくので、それぞれの方針についてどのように実現するかをプログラマー、プランナー、デザイナーで相談します。

プログラマー目線で相談の際に意識しているのは、以下のようなポイントです。

 

状態遷移のフローや条件に抜けがないか

実際に実装作業や、ゲームプレイをイメージしてみて、「あれっ、この場合の挙動はどうなるんだろう？」というような疑問点があればこの時点で解決しておきましょう。こういった疑問はこれ以降のフェーズで改めて気づく場合もあるので、その都度相談して解決します。
 

実装にかかる工数が現実的かどうか

タスクにかかる工数は人それぞれではありますが、ゲームをリリースするのに必要なタスクはひとつではありません。他のタスクの工数や実装締めの期日などを鑑みて、実装の量が現実的かどうかを気にする必要があります。

 

仕様に処理負荷的な問題がないか

大量にオブジェクトを生成するような仕様をそのまま実装してしまうと、処理落ちなどでゲームプレイに影響が出てしまいます。そのような場合は処理負荷を抑えるために仕様側を調整してもらうか、実装側で処理負荷を抑えるように工夫することになります。

前者はプランナーやデザイナーの意図したビジュアルを作れなくなる可能性があり、後者はどうしても負荷を抑える限界があり、工夫する分工数もかかります。その仕様の重要さやプロジェクトの残り期間によってどちらを選ぶかを決めていきます。

 

他のギミックやプレイヤーのアクションと組み合わせたときに不都合が生じないか

アクションゲームは多数のオブジェクトの組み合わせで構成されています。ギミック単体の挙動としては問題なくても、他のオブジェクトと影響しあったときに問題が発生する可能性があります。

例をあげると

• 地面にそって移動するギミックが、プレイヤーが設置したトラップギミックを轢いたときはどうなるのか？
• プレイヤーがスキルを使うのと同時にジャンプ台ギミックに乗ったらどうなるのか？

といった問題です。これらの挙動について都度考えるとキリがないので、「移動物と設置物の接触ルール」や「ギミックがアクションを中断するルール」のように事前にルールを決めておけるとやり取りがスムーズです。

仕様に対して何かしら意見を出して調整してもらう場合は、問題点に加えて「それを解決するための案」も合わせて出せるとよいです。プログラマー目線で「こういう仕様の方が都合がいい」というものでもよいですし、ゲームクリエイター目線で「こうしたらもっと面白くならないかな？」という案でもよいです。

プログラムだけがゲームプログラマーの仕事ではありません。ゲームをより面白くしていくための意見出しも積極的に行っていきましょう！
 

仕様完成

仕様相談の結果をもとに、プランナーが仕様書を完成させます。その後関係者間で内容を共有して改めて認識をすり合わせます。

この時点で作るものとその作り方が大方決まるので、後はどれくらい工数がかかるかを見積もって実装フェーズに移ります。
 

②実装フェーズ

ここからプログラマーのメインのお仕事である、実装作業に入ります！
 

機能実装

完成した仕様の通りにプログラム実装を行います。不具合や処理落ちなどが発生しないようにしっかりと実装確認をしましょう。

実装中にも、仕様相談時に見落としていた問題に気づく場合があるので、その時は都度方針をプランナーに確認するとよいです。仕様によっては他のプログラマーと協力しながら実装することもあります。
 

リソース組み込み

スケジュールとの兼ね合いによっては、実装作業の際に本番用のデザインアセットがなく、仮アセットで実装を行う場合もあります。なるべく仮アセットで挙動が確認できるようにし、本番用のアセットが届き次第差し替えるだけで済むようにするのが望ましいです。

見積もりの時点でアセットの差し替えが発生しそうであれば、その分の工数も見積もっておけるとよいですね。
 

デバッグコマンド実装

ゲームの機能実装を行っていると、実装確認用にデバッグ機能が欲しくなることがあります。

例えば「プレイヤーが10秒インタラクトボタンを長押しすると起動するギミック」の場合、起動したときの挙動を確認するために毎回10秒かかってしまいます。プログラマーであれば確認のためにソースコード側で長押し時間の変数の値を1秒に変えることもできますが、それだとプログラマー以外が確認するときに不便になってしまいます。

そういった場合にインタラクト時間を変更するデバッグコマンドがあれば、誰でも短時間でギミックの挙動を確認できるようになります。実際のプロジェクトだとImguiなどを使って開発ビルド専用のウィンドウを実装し、そこからデバッグコマンドを起動できるようにすることが多いです。

デバッグコマンドは実装確認時の時間短縮につながる大事な機能なので、積極的に作成しましょう！
 

③確認フェーズ

実装が終わったら、ギミックの動作を確認するフェーズに入ります。
 

テストプレイ

実装したものを自分で遊んだり、他の人に遊んでもらいます。マルチプレイに対応したゲームであれば複数人で遊んでみます。

実装確認のために動かすのではなく、実際に遊んでみることによって気になる点や思わぬ不具合が発見できることがあります。
 

フィードバック対応

実際に作ったものを遊んでみることで改善点が見つかり、それがフィードバックとして返ってきます。ゲームをより良くするために、工数が許す限りはフィードバックに対応していきます。

このようなフィードバック対応のための工数は必ずしも必要になるわけではありません。例えば仕様相談の時点でギミックのおもしろさや手触りをしっかりと検討し、完璧に実装できれば、そのままOKがでることもあるかもしれません。

しかし、いざ対応が必要になったときに工数が残っていないとなると、その改善点が治せないまま次のタスクに取り掛からなければいけない……ということになってしまいます。そんなことにならないためにも、フィードバック対応のためのバッファ工数は必ず取っておきましょう。
 

タスク完了

フィードバック対応まで終われば、そのギミックの実装は終了です！
 

まとめ

今回はアクションゲームのギミックを実装することを想定して、タスクをひとつ完了するまでの流れを紹介しました。

工数を見積もる際に見落としがちなのは、デバッグコマンド実装とフィードバック対応です。これらは工数を取らなくても大丈夫な場合もありますが、不足の事態を避けるためにも必ず見積もるように意識しておきたいですね。

また、プログラマーもゲーム開発チームの一員です。開発しているゲームをより面白くしていくため、仕様相談やテストプレイの際は積極的に意見を出していきましょう！

未来の新人プログラマーと、過去の自分にこの記事が届きますように……