ゲーム開発の調整工数を減らす「ツールづくり」の視点

ゲーム開発では、プログラムが完成してからも、調整の作業が長く続きます。

敵の動き、ステージの配置、UIの見え方、アニメーションのタイミング、スクリプトで制御する演出。こうしたものは、一度決めたら終わりではなく、実際に触ってみて、違和感を見つけて、また直す作業が何度も発生します。

プログラムを書く工数ももちろん大きいです。ただ、ゲーム開発では、実装そのものとは別に、コンテンツ制作と調整の工数が大きくなりやすいです。特にレベルデザイン、スクリプト、アニメーション、UIのように、体験の手触りに近い部分では、細かな確認と修正が積み重なります。

ここで作業の流れが重いと、調整したい人がすぐに確認できません。結果として、良し悪しの判断まで時間がかかります。

調整のたびにビルドが必要になる問題

あるプロジェクトで、レベルデザイナーが敵の挙動を微調整したいという場面がありました。

このとき、何も仕組みがなければ、開発フローはかなり遅くなりますj。データを直す。エンジニアに依頼する。ビルドを作る。ゲームを起動する。該当ステージまで進める。そこでやっと、調整した内容を確認できます。

一回だけなら、それほど大きな問題には見えないかもしれません。けれども、レベルデザインの調整は一回で終わりません。敵の移動速度を少し変える。攻撃の間隔を変える。反応距離を変える。プレイヤーが気づくタイミングを変える。こうした確認を毎回同じ手順で行うと、調整そのものよりも、確認の待ち時間が増えていきます。

この状態では、レベルデザイナーが自分の判断で試しにくくなります。エンジニア側も、調整依頼のたびに作業を差し込むことになります。誰かが悪いというより、確認までの手順が重いことで、チーム全体の作業が進めにくくなります。

クリエイターが直接触れる仕組みを用意する

たいていの現場では、こうした問題を減らすために、レベルデザイナーが直接触れる調整ツールを用意します。

今回の事例では、ゲームプログラマーが少し踏み込んで確認しました。過去の類似タイトルでは、どのような調整が行われていたのか。レベルデザイナーだけでなく、アーティストや他職種がどの項目を触りたくなるのか。実装担当者の想像だけで決めず、実際に使う人の作業を見て、必要になりそうな調整項目を洗い出しました。

そのうえで、ゲームを起動したまま敵の挙動やパラメータを変えられる、簡易的なアクションゲーム制作ツールのような仕組みを作りました。

立派な専用ツールを作る必要はありません。調整したい人が、自分の目で確認しながら数値や挙動を触れる状態にすることです。敵の動きが速すぎるのか。攻撃前の間が短いのか。プレイヤーに気づく距離が長すぎるのか。こうした判断は、画面上で実際に動かしてみないと分かりにくいことがあります。

クリエイティブ職がその場で触れるようになると、調整の粒度が変わります。依頼文を作る前に試せます。試した結果を見て、次に直す項目を確認できます。レビュー時にも、何を変えたのかを会話しやすくなります。

「ツール開発に一週間かかる」≠「開発が一週間遅れる」

このツール開発によって、そのゲームプログラマーのタスクは一週間ほどずれ込みました。

この一週間だけを見ると、予定が遅れたように見えます。短期の進捗管理では、実装タスクが予定通り終わったかどうかに目が向きやすいです。もちろん、スケジュールを無視してよいわけではありません。

ただ、ゲーム開発では、その後に何回調整が発生するかも見ておく必要があります。

敵の挙動を一度直して終わりなら、専用の仕組みを作る意味は薄いです。けれども、ステージが増え、敵の種類が増え、難易度ごとの差分が増えるなら、確認の手順が重いままだと、毎回同じ負担が発生します。

ツールを作ったことで、レベルデザイナーやクリエイティブ職は、数値や挙動を触りながら、その場で体感を調整できるようになりました。ビルドを待つ時間が減り、エンジニアへの細かな依頼も減ります。レビューで見るポイントも揃えやすくなります。

一週間の遅れが良い判断だったかどうかは、その後の調整回数と、どれだけ多くの職種が使うかで変わります。ここを見ずに、単純に「遅れた」とだけ見ると、開発全体の作業量を判断しにくくなります。

ゲームプログラマーの仕事は実装だけではない

ゲームのパフォーマンスを上げることは、ゲームプログラマーの大切な仕事です。

フレームレートを安定させる。ロード時間を短くする。処理落ちの原因を切り分ける。メモリ使用量を抑える。こうした技術は、遊びやすさに直結します。

ただ、チーム全体の作業を進める仕組みを整えることも、同じくらい大切な仕事です。クリエイターが自分で確認できる。レビューで変更点を追いやすい。調整のたびにビルドを待たなくてよい。こうした状態を作ることで、ゲームの体験そのものを詰める時間が増えます。

実装担当者だけが触れる仕組みになっていると、調整したい人が毎回依頼する形になります。依頼内容が曖昧だと、エンジニア側もどこまで直せばよいか確認に時間がかかります。数値の変更で済む話なのか、挙動そのものを直す話なのかも分かりにくくなります。

クリエイターが触れるツールがあると、この切り分けがしやすくなります。数値を変えて解決するのか。仕様を見直す必要があるのか。実装側に相談するべき不具合なのか。次に確認する内容が分かりやすくなります。

調整ツールを見るときの確認ポイント

こうした仕組みを作るかどうかは、ツールを作る工数だけでは判断しにくいです。次のような点を見ると、判断しやすくなります。

・同じ種類の調整が、今後も何度も発生するか
・調整したい人が、エンジニアを介さずに確認できる項目か
・ゲームを起動したまま変更できると、確認時間がどれだけ減るか
・ビルド待ちやステージ到達までの時間が、調整回数に対して重くなっていないか
・レベルデザイナー、アーティスト、QAなど、複数の職種が同じ仕組みを使えるか
・変更履歴や設定値を残せるか
・不具合調査時に、どの値を変えたのか追えるか

ゲーム開発では、コードを書くことと同じくらい、確認しながら作れる状態を整えることが大きな意味を持ちます。

画面を見ながら触れる。違和感が出たら、その場で数値を変えられる。レビュー時に、何を変えたのかを確認できる。そういう仕組みがあると、調整のたびに作業が止まりにくくなります。

ゲームプログラマーの技術は、処理を速くするだけではありません。チームがゲームの手触りを確認しながら作れる状態を用意することも、ゲームを良くするための技術だと思います。