初代『Fallout』手がけたベテラン開発者いわく、ゲーム開発の「スパゲッティコード化」はプログラマーの怠慢ではない。“綺麗なコード”が崩壊する、現場のリアル

ゲーム開発でもしばしば槍玉に挙がるスパゲッティコードについて、初代『Fallout』に携わったTimothy Cain氏が当時の「現場のリアル」を語っている。Cain氏によれば、スパゲッティコードは「愚かで怠惰なプログラマー」が生み出すものではなく、むしろ十分な開発時間が与えられないまま仕様変更が積み重なることで、誰が書いても発生しうるという。

Cain氏はかつてInterplay Entertainmentにて『Fallout』第1作のリードプログラマーなどを担当していたベテラン開発者だ。現在はObsidian Entertainmentに在籍しており、今もゲーム開発に携わっている。そんな同氏は自身のYouTubeチャンネルにて携わったタイトルの裏話などをさまざま披露してきた。

今回は動画「Spaghetti Code」の中で、ゲーム開発におけるスパゲッティコード化について説明。スパゲッティコードとは、食べ物のスパゲッティの麺のようにコードが複雑に入り組んだプログラムを指す言葉。処理の流れや構造が把握しづらく、トラブルが生じた際の原因特定や修正が困難になることでも問題視される。

[AD]

スパゲッティコード化については担当したプログラマーやプログラミングチームの責任とみなされることも多いものの、Cain氏によればゲーム開発においては一概に“愚かで怠惰なプログラマーが生み出すもの”とは言い切れないようだ。同氏はスパゲッティコード化が進む典型例として、自身の経験を踏まえてRPGの「ダメージ耐性（DR: Damage Resistance）」処理を取り上げている。Cain氏の説明によると、まず「DRは本来すごく単純」なところから始まり、たとえばDRが10%なら、20ダメージの攻撃を受けたとき2ダメージ分を軽減して、実ダメージは18になる。ここまでは計算も設計も明快だ。

そこでプログラマーは、装備している防具1点からDR値を取得する関数、たとえば「item armor get DR」のような処理を書いて終わる。Cain氏はこれを単機能で読みやすく、欠点のない美しいコードができあがるとし「ダイヤモンドみたいだ」と表現している。

しかし、ここからが現場の本番となるそうだ。せっかく“綺麗なコード”を書いても、現実には次から次へと変更が入り、後から要件が増えていく。「DRは装備品の値だけ見ればいい」という当初の状況が、制作が進むにつれて、たとえば「状態異常やバフ/デバフによるDR増減」、「例外的な効果（特定条件下のみDRが変動する等）」を追加するなどの変更が出てくるのだそうだ。

そして、Cain氏はある画面では「最終値」を表示したいが、別の画面では「装備品の素の値」だけを表示したいといったケースを例示。この際にはUI担当から「表示が合わない」と指摘され、仕様の解釈違いが発覚したりするとのこと。

このとき厄介なのは、要求が増えるだけでなく、要求同士が噛み合わないことがある点だそうで、Cain氏の例では、ステータス効果ぶんまで加味した値が内部的に正しくても、UI側が「それは欲しくない（見せたいのは装備品の値だけ）」と言い出して衝突したりするという。すると、同じDRでも「どの文脈のDRか」を分岐で切り替える必要が出て、当初シンプルだった関数が条件分岐と例外処理で膨らんでいくそうだ。

Cain氏の考えでは、こうして「スパゲッティコード化」が始まるのは、能力や姿勢の問題というより、短期間で「とにかく動くもの」を求められる開発環境の帰結だという。また同氏はこれは仮定の話ではなく、実際に起きてきたことだとも述べ、80年代から現在に至るまで同氏が繰り返し述べてきた持論のようだ。

Cain氏はまた、ゲームを単なる製品であると同時に「芸術」でもあるとの考えを述べている。限られた時間とリソースの中で完成を目指す以上、理想的な設計や美しいコード「だけ」を追い求めるのが常に正解とは限らない、という立場を示している。

なおゲーム開発においてはコードが綺麗かどうかは、プレイヤーからの評価や商業的成功に必ずしも影響するわけではないようだ。たとえば、ローグライクポーカーゲーム『Balatro』ではユーザーがコードにはif文が多用されていると報告し、いわゆる「力業」的な構造であると注目されることに。とはいえ『Balatro』は現在までに累計販売本数が500万本を突破し、ユーザー評価もSteamでは14万件以上のレビューの中で97％から好評を得る「圧倒的に好評」ステータスを獲得している。複雑なコードでも大きな問題なくゲームを完成させられる事例として共感も呼んでいた（関連記事）。

とはいえそうした個人開発作品とは違って、チーム開発では可読性や保守性を担保し、後の工程や運用を見据えた整理も重要となるだろう。開発規模によってはスパゲッティコードであることがバグ修正などの妨げになることも考えられる。ただCain氏いわく現場では仕様変更・追加要件・部門間の認識の違いなどが重なると、「後で直す」余裕が消え、まずは締切までに動かす判断が積み重なりがちになるようだ。ゲーム開発におけるスパゲッティコード化は、プログラマーチームだけでなく開発体制に起因する問題でもあるのだろう。