第48話 マイルストーン
デバッグが開始された。
期間は一月中旬から二月いっぱいの二ヶ月を予定しており、そのための資料も
バグ対応といっても、単純な不具合を直すというわけにはいかないものも多い。
そのバグの原因が仕様の穴であったり、そのバグを直すことによって他の箇所に影響が出てしまう場合、それらを総合的に見てどのように仕様を変更するのかの判断を委ねられるのが矢切の立場だった。
チャットで不具合や修正の確認、仕様変更について詰めて指示を出し、その合間に実装状態の確認作業を行い、調整してほしい箇所の指示を出し、デバッグ会社が上げてくる不具合や質問に対応していく。
矢切だけではなく、全員がてんてこまいの忙しさとなり、日曜日に出勤する者も出たが、泊まりこみでの作業はほぼゼロで対応できているのは、伏野の事前の準備と、仕様をこまごとまとアップデートして、ゲームの実装状態との
バグ、すなわち不具合といっても、内容や深刻度によってランク分けが成される。
Ｓランクは、ゲームの進行が不可能となる類のバグである。
フリーズするのはもちろん、ゲームはプレイできても、なんらかの理由で最後まで到達できなくなる、いわゆる「ハマリ」と呼ばれる現象もこれに相当する。
もちろん修正必須である。
Ａランクは、ゲームは進行できるが重篤な不具合である。
画面の表示がおかしくなる、装備した武装の性能がまったく異なる、与えるダメージの数値がおかしくなるなどである。
以後、ゲームに与える影響度合から、「Ｂランク」「Ｃランク」、テキストの誤字・脱字などのミス用の、「Ｔランク」という定義のものも会社によっては存在する。
バグが発見されると、デバッグ会社から、詳細な報告がネットのバグトラッキングシステムと呼ばれるバグを管理するデータベースシステムで、一つのバグが一つのチケットとしてアップされる。
バグが挙げられると、開発側では各自自分の担当と思われるチケットを見つけては、担当者の項目を自分に変更して対応していくわけだが、複数の担当者を経ることも多い。
修正されたバグは、チケットのステータスを『修正済』に変更し、修正したリビジョンとそれを確認できるＲＯＭバージョンを記載して、デバッグ会社に回す。
デバッグ会社では、原則バグを報告したスタッフが、再現試行を行い、そのバグが再現しなければステータスを『終了』とする。
これが、おおむね一つのバグが発見、報告され、修正して終了となるまでの流れである。
また、デバッグ会社では、ただ闇雲にゲームをプレイしているのではない。
現在のゲームのボリュームはファミコン時代とは比べものにならないほどに膨大になっているため、まず、ゲーム全体を大きな要素ごとにプレイして、不具合が無いか、仕様と実装されている内容が一致しているかを確認していく。
この中で、仕様書と実装状態が異なる場合、『仕様相違』としてバグ報告が上がってくる。
たとえゲームの実装状態の方が正しいのだと予想がついたとしても、渡された仕様書と挙動が異なる以上、デバッグ会社としてはバグ報告を挙げざるを得ないのだ。
こういった、「何が正しい状態か」がわからない要素は、面倒でもいちいち開発側に仕様を確認せざるをえない。
この手間を省くため、会社やプロジェクトにもよっては「仕様相違があった場合、実装されている状態を仕様にする」ということを方針とするプロジェクトは珍しいことではない。
今まで経験してきたプロジェクトでは山のようにあったこれらの『仕様相違』のバグ報告は、このＨＳＧではあまり見られなかった。
伏野の方針で、実装状態との乖離がないようにコツコツと仕様書を更新してきたのが功を奏している。
伏野はデバッグ作業の開始にあたっても、全体のコンテンツのチェックすべき内容と、仕様書だけではわかりづらい、特に注意して見てもらいたい箇所などもあらかじめチェックリストとしてまとめ、デバッグ会社に提出しており、それを参照しながらデバッグ会社はチェックを進めている。
ゲーム本編はまず順調、と言っていい進捗を見せていたが、後から追加した『放浪モード』のバランス調整はまだ粗削り、という状態である。
ゲームのバランス調整というものは、適当に数値等を設定し、とりあえずプレイして気になったところをなんとなく調整する、というわけにはいかない。
バランス調整とは、実際にゲームをプレイし、調整設計書のイメージ通りになっているかを確認して数値を文字通り調整していく作業なのである。
だが、伏野の調整したバランスが今一つ芳しくない、とゲームをプレイした矢切は感じた。
調整設計の担当者である伏野自身が通しでゲームをプレイする時間を、なかなか確保できないからであった。
無理もない、と矢切は思う。
何せ伏野は、ディレクターである矢切の意向を汲み取り、それを実務に落とし込んでいくリードプランナー的な役割に加え、もちろん自分のプランナーとして作業も持ちつつ全体のスケジュール管理も請け負い、デバッグの基本窓口にもなっているのだ。
自然にそうなっていったとしか言いようがない。
プロジェクトマネージャー兼リードプランナー兼プランナーという兼任そのものは中小のゲーム開発会社ではままある事態だが、このプロジェクトではその負荷はより大きなものがある。
何せ寄せ集めのチームで、おまけにディレクターである自分は方向性は示せているが具体性にかけることが多く、それを丹念なヒアリングで掘り起こし、ディレクションたらしめているのは伏野だったし、得意分野はあるものの、実務経験についてはまだルーキーと言っていい前戸の面倒も見ている。
加えて、挙がってきたバグ報告のチケットの中で、担当者が判然としないものや、プランナーの仕様的な問題のあるものは伏野が捌いていくれているのだ。
『放浪モード』をじっくりプレイする時間など、とれようはずもなかった。
矢切自身は、伏野に言われた通り、デバッグ対応を行いつつゲーム本編や『放浪モード』をプレイしては気になる点をメモし、それを伏野や前戸に調整依頼をかけていたのだが、伏野がそれに対応しきれなくなっていた。
「すいません矢切さん……。僕も、もうなかなか時間が取れなくなって」
そう申し訳なさそうにする伏野を見て、矢切は『放浪モード』については自分自身が手を加えていくことを申し出た。
伏野が少し不安な表情を浮かべたものの了承してくれたのは、少しは自分を信用してくれたのだろうかと矢切は思った。
伏野は、ディレクターは現場の細かい作業に入りすぎてはいけない、もっとゲーム全体の完成度を見渡して修正や調整指示を出すべきだという主義の持ち主で、矢切自身があまり現場の細かい作業にタッチすることにいい顔をしないのである。
（自分から作業をかって出るなんて初めてだ）
矢切は苦笑した。
だが、せっかく皆の力を借りて実装した『放浪モード』である。
納得のいくバランス調整にしなければ、意図した面白さをプレイヤーに提供できない。
どんなによくできたゲームシステムでも、バランス調整で失敗すれば台無しになる。
（ここまで来て、中途半端にしてたまるか）
矢切は
『放浪モード』を頭からプレイし、イメージと異なるところ、気になるところを上げていく。
思いつきではいけない。調整設計を変えるなら変える。
数値や配置に問題があるならそれを調整する。
それによって影響を受けた別の箇所がまた気になる。
またどうするか考えていく……。
伏野が細かく調整設計の変更点を書面に反映しておいてくれたおかげで、実際にプレイしてその方針に沿っているかどうかが判断基準として機能した。
（調整設計ではここで一度に二人が仲間になるけど……、整備のレベルが上がるノルト少尉は別にして、ありがたみをもっと感じられるようにしよう）
（ここで得られる補給物資は計算で想定した数値ではちょっと少なすぎるな。少し整備用部品を増やす）
プレイして得られる感覚を言葉にして、ゲーム全体を見渡しながら対応するかしないか、対応するならどう対応するかの自己判断を下す。
『放浪モード』は細かなバグが露見するようになり、作業もたびたび中断する。
だが矢切は連日深夜まで作業にいそしんだ。
こうして、デバッグが開始して三週間が経過するころになると、『放浪モード』も致命的なバグはなかなか発生しづらくなり、バランス調整もかなりこなれたものになってきて、矢切がゴールを見据えられるようになったころ、
「また要望か！
金矢が憮然とした表情で言った。
会議室に全員で集まり、嵯峨から届いた要望を矢切が説明したところだった。
嵯峨からの要望は、やはり『放浪モード』についてのもので、ＵＩと操作性についてのものと、バランスについてのもの、さらに新たな仕様の追加要望だった。
『放浪モードに偵察の要素を入れてほしい。原作でも索敵や情報収集は大事なこととして描かれている。放浪モードは救出がくるまで、部隊を率いて生き残るのが目的のゲームで、ポイントに侵攻するのもそのためだが、現在は何となく侵攻先を選んでいる。偵察の要素を入れて、マップポイントに攻め込む際の指針にしたい』。
それが嵯峨が要求する新たな仕様だった。
「ほかのＵＩや操作についての要望もそうだけど、『放浪モード』はゼロから作って動作確認できるようになって間もないですからね……問題や、気になるところはそれは出ても当たり前っていうか」
伏野が嘆息しながら言う。
ゲーム開発は、仕様書に基づいて素材を作り、プログラムを組み、実装してはい終わり、ではない。
大抵、仕様変更が入る。
そして、一旦は「これでＯＫ」としていた仕様も開発が進むにつれて、別の問題点が浮かび上がったり、気になる点が出てきたりする。
それらをどう処理していくかがマネージャーやディレクター、ひいてはチームとしての開発力の見せ所ではあるのだが、デバッグ期間に入ると、おいそれと新規の要素を追加したり、仕様を変更するわけにはいかない。
仕様変更をかける場合は、その重要性や影響範囲を見て、残り日数から間に合うかどうか、問題がないかどうかを十分考えなければならない。
ちょっとした修正でも、それが及ぼす影響範囲が広い場合や、デバッグを終えたところを再度やりなおす必要がある場合は、見送る。
「どうなんスか、これどれくらいでできそうなんスかね？ なんかおもろくなりそうッスけど」
「それは仕様によりますよ、まずはそれを決めてもらわないと」
プログラマーの鳥羽としては、このレベルの情報だけでは何に影響があるか、大ざっぱな判断しかしようがない。
嵯峨の要望はまだアイデアレベルだ。
偵察という要素を入れる、といっても、部隊から偵察キャラなどを派遣して情報を得るのか。
それとも物資などを消費する代わりに、ポイントの情報を参照するのか。
どんな形でこの「偵察・情報収集」というアイデアをゲームに落とし込むのか。
それをまずははっきりとさせてもらわなければならない。
「それじゃあ、僕が仕様まとめます」
伏野がそう言ったが、その表情は明らかに疲れている。無理もない。
「おいおい、『放浪モード』については俺がやるってことにしただろ、任せてくれ」
矢切がそう言うと、伏野はそうでしたねと苦笑した。
新規登録で充実の読書を
- マイページ
- 読書の状況から作品を自動で分類して簡単に管理できる
- 小説の未読話数がひと目でわかり前回の続きから読める
- フォローしたユーザーの活動を追える
- 通知
- 小説の更新や作者の新作の情報を受け取れる
- 閲覧履歴
- 以前読んだ小説が一覧で見つけやすい
アカウントをお持ちの方はログイン
ビューワー設定
文字サイズ
背景色
フォント
組み方向
機能をオンにすると、画面の下部をタップする度に自動的にスクロールして読み進められます。
応援すると応援コメントも書けます