HeavyMachを
作り直した理由

私は開発者を3番目の職業として選んだ。2015年には雑誌社で記者として働き、2016年にはフィリピンで勤務した。2017年7月にiOS開発者へ転業した。ソフトウェアから遠い仕事をしながら経験した世界は、私にとって非決定論的で不合理だった。その生活を清算して別の職業を選んだ理由はいくつもある。

HeavyMachより大きな影響を与えた出来事は、雑誌社で経験した。代えの利きにくい技術を持つ編集デザイナーたちが集団で上に逆らい、その結果、労働条件が良くなった。月刊誌の締めを終える2日間を除けば、定時退勤が保障された。この経験は9号「抗命の代償」にも書いた。

1か月後、編集部の編集長が酒の席で爆発した。編集長は、6人で毎月、月刊誌3誌と日刊紙1紙を締め切り、さらに取材までこなすのは不可能で、全員が毎日残業していると話した。結果は逆だった。編集部全員に、1か月間は夜10時以前に退勤するなという指示が下った。正式な懲戒というより、気に障ることを言った者への報復的な勤務命令だった。

Rockwell Automation、B&R、横河電機のような工場自動化企業の役員に取材し、見聞きしたこともあった。工学技術によって自動化すると、どのような便益が得られるのかという話だった。この取材経験も、開発者を選ぶことに影響した。

知人と焼酎を飲むと、私が2015年と2016年の仕事を続けていたら、飛び降り自殺で生涯を終えていただろうと言われることがある。彼らが正しいのか、まだよく分からない。

HeavyMachを作った2人の制作者は、私の寿命を9年と3か月、さらに延ばしてくれた。

最近、私に残された時間は多くないと感じる。健康の問題でも、極端な無気力のためでもない。むしろ精神は、1か月前、2か月前、半年前より明瞭だと感じている。だから今、何を試し、何を残したいかを考える。私が選んだことの1つがHeavyMachの復元だ。かつて方向を示してくれたゲームを、開発者になった私が再び動かす。私はこのつながりを、結びが始まりへ戻ることだと思っている。

2009年に発売され、私に道を教えたゲームを2026年に作り直した。今ではApp Storeにもなく、周りにこのゲームを覚えている人も少ない。私はこのゲームを、今使っているiPhoneでまた動かしたかった。Codexにソースコードから新しく書かせ、原作と違う動きをする箇所を繰り返し指摘して直した。

似たプロジェクトを進めたmesablooという人がいた。彼はHeavyMach Defenseのアセットを入手し、ソースコードを一から書き直した。ユニット間の交戦アルゴリズムを実装している途中で止まったようだった。私は、ソースコードを一から書かなければならなかった彼より、出発点では恵まれていた。

週末に寝ていて夢を見た。夢の中で、iPod touchとCydiaに初めて触れた自分を第三者の視点から見ていた。起きてGoogleにheavy Machと打ち込んだ。Google検索のGeminiが、HeavyMachの原本をダウンロードできるウェブアーカイブ専門サイトを教えてくれた。それがこの復元プロジェクトの始まりだ。 Internet Archive（archive.org）のHeavyMachシリーズ集からダウンロードしたHeavyMach 1.13のビルドを基に、復元を始めた。

だから私は、自分がしたことはほとんどないと思う。これで金を稼ごうなどと考えてはいけないと、なおさら思うのもそのためだ。私がしたのは、自分の言い方を借りるなら、Codexが原本のソースコードと原作者の美的達成から外れ、勝手に誤った行動をしたとき、胸ぐらをつかんで平手打ちを食らわせただけだ。

もし原作者や他の利害関係者から公開停止を求められたら、私は未練なくこのリポジトリを消す。

このシリーズを作った開発者ピョン・ヘジュンとイラストレーターのパク・ジェチョルが、この復元プロジェクトをどう思うかは分からない。パク・ジェチョル本人のものと思われるメッセンジャーのプロフィールに、問い合わせを残した。開発者の弁にこのことを書いた時点では、まだ返信は来ていなかった。

復元を始めた当時、私が知っていた制作者はピョン・ヘジュンとパク・ジェチョルだった。だからまず2人の名前を記録した。Mesablooの復元プロジェクトは知っていたが、WeMadeがHeavyMachのIPを取得したことは、今回クレジットを整理して初めて知った。

2011年にWeMade Entertainmentの子会社WeMade Creativeが、HeavyMachとHeavyMach 2のIPを含むIndiappsの資産を取得した。クレジットには、原作の開発・イラストと、後の取得という役割を分けて記載した。

初期の実装では、戦車が発射したり被弾したりするたびに、ゲームがファイルを保存していた。弾薬や経験値が変わったという通知が、そのままファイル書き込みにつながっていた。私は「発射のたびにファイルを保存？」と聞いた。Codexはメモリ更新と保存を分け、スロット選択、次のステージ、ゲームオーバー、メニュー復帰のときに保存するよう直した。修正後の自動検査には、180フレームの射撃中に保存0回、メニュー復帰時に1回と記録された。

自分で正常な動作を確認した原作の実行版ではフレーム落ちがなかったが、初期の復元アプリでは起きた。私は、そもそもUIKitでゲームグラフィックスを描くことが妥当なのかと尋ね、既存の経路と比較させた。Codexは毎フレームCPUで画像を作っていた処理をOpenGLへ変え、テクスチャを事前に用意して再利用するようにした。

描画方式を変えた後も射撃時に遅延が起きたため、Codexが原因をさらに調べた。Codexは効果音を再開する呼び出しを測定し、AVAudioPlayerで再生を始めるコストを確認した。OpenALであらかじめ用意したバッファとソースを再利用する形に直した。武器を変えたときに音が出ない問題は、抜けていた効果音の再生呼び出しを追加して直した。

なぜ時間の蓄積計算を入れたのかも聞いた。遅延が起きると、画面表示の呼び出し間でゲームの状態を何度も更新する実装だった。元の移動と射撃の感覚が変わる問題だった。Codexは、画面を1回描画するごとにゲームの状態も1回更新するように直した。ロックとバックグラウンド移行時にはゲーム・音・押下状態を止め、戻った後はプレイヤーが手動で再開するようにした。

私は画像を拡大するのではなく、より広いワールドを見せるように言った。画面を広げるには、新たに見える左右の領域でもタッチした場所に射撃できる必要があった。メニュー背景とミッション結果画像も広い画面を埋める必要があった。自分で見て、画像の境界がつながっていない箇所や黒い線を指摘した。メニュー切り替え時に既存領域と追加領域が別々に開閉する問題も直させた。Codexは、扉のように閉じる4枚のパネルで画面全体を覆うようにした。

ミッション3-5では、航空機型ボスが左へ近づくのが速すぎ、右へうまく戻らなかった。Codexは最初、私が言った敵をヘリと取り違えた。航空機だと訂正して、ようやく該当ボスを比較した。画面が広くなったため、敵の表示条件と戦闘開始条件が早く成立していた。Codexは2つの条件を分離して直した。

航空支援攻撃がタッチした場所よりも戦車の後ろへ落ちる問題もあった。タッチを離すときに渡した偽の座標が、攻撃位置の計算に入っていた。Codexは入力解除と照準座標を分け、最後の攻撃位置を維持するようにした。私はチートアプリで全武器を検査する手順も要求した。コア計算が正しくても、実際に押して離す操作では違う結果が出た。

ミッション終了後のイラストは、私の記憶にも残っていた部分だ。画像が抜けていると指摘すると、Codexはリソース名のJPG・PNG接尾辞の対応を直した。その後、実機のスマートフォンで画像を確認した。広い画面ではイラストの外に戦場が見えたため、Codexは背景と表示領域を直し、結果画面が画面全体を覆うようにした。

iPhoneとiPad、Macでゲームコードとリソースを共有させた。移動や弾道、ダメージ、敵配置をデバイスごとにコピーしておくと、一方で直したことが他方で抜けることがある。Codexは共通C++コアとAppleランタイム、リソースバンドルを1つのworkspaceにまとめた。ゲームコードは静的frameworkで取り込み、画像・音源・マップは同じリソースバンドルを使う。MacはAppKitアプリにした。

iPhoneには横向き回転とタッチ・傾き・キーボードを、iPadにはタッチ・傾きとキーボードの併用を入れた。Macはウィンドウ表示とフルスクリーンに対応する。キーボードに移動・ジャンプ・砲身調整・射撃・武器選択・メニューを割り当て、Shiftで角度をより細かく調整できるようにした。

通常アプリとチート検証用アプリは別にインストールする。チートアプリではミッションや武器・パーツ・強化条件を指定できるので、同じ敵を見るためにゲームを最初から繰り返す必要がない。ただしゲームの移動と射撃は同じ処理経路を使う。アプリIDと保存領域も分けた。

Macの検査ツールが失敗したのに、Codexがゲーム全体に問題が起きたかのように説明したこともある。私は実際のゲームの検査から終えるように言った。CLIで署名が失敗したときも、その前にXcodeでは実行できたことを指摘した。Codexは成功した経路と失敗した経路のチーム・署名・デバイス状態を分けて確認してからインストールを進めた。

ヤク、ハリアー、F35を指定し、既存ユニットの色調と質感に従うように言った。外形を再解釈しろとは言っていない。ところがCodexは最初の生成指示に、実物に着想を得た機体、幅広く低いシルエット、誇張された装甲パネルといった条件を自分で入れた。既存ヘリの画像は参照したが、実機の写真や図面は入れなかった。

私は実際のモデルと形が違う理由を聞いた。Codexは実物の形状を保つルールを加えた。写真と図面は形状確認に、既存のゲーム画像は色調と質感を合わせるために使うよう分けた。機首、翼、尾翼、吸気口の位置と比率を照合した。新しい案を確認した後、今後現実のユニットを追加する際も、この手順で描くように言った。

美感・視覚要素・トーンという観点で見ると、Codexは完全に動くソースコードやアセット、スプライトのような視覚的ヒントがあっても、OpenAIの画像生成モデルの画風に依存しすぎると思う。ルクス・ルナエは比較的運の良い例だった。ヤク・ハリアー・F35では、人間なら原作デザインを見て似たように描くだろうと考えた。ヒントは既に完璧にそろっているのだから。ところが正反対のSF的な描写、しかも私のディレクションを無視した案を持ってきて、もみ合いをしなければならなかった。

私は2025年に最後の会社を辞めた後、バイクで全国を一周した。ソウルや京畿道とは違い、月光を頼りに地方の国道や誰もいない田畑の道を走ると、単なる旅行や気分転換とは違う感覚になる。自分の手さえ見えない暗闇で、月光とヘッドライトだけを頼りに道を見定めて走ると、世界には自分とバイクしかいないような錯覚に陥るほどだ。

狭い初めての道を時速120キロで走ると、人は生きるために自動的に頭を空にする。ある意味、死を目前にして身体が本能的に入る極限の瞑想状態に近づく、とでも言うのだろうか。一度も訪れたことのない場所で目の前に見えるのは月光だけで、その光を受け、完全に内へ沈み込む状態で走ると、人が変わるということだ。月光という言葉は、私の人生で不思議な象徴になった。

私が月光の下で全国一周をしたことと、ナムコが8のボスたちの編隊をルクス・ルナエと名づけたことは、どちらも偶然で、相関が0の独立した出来事だろう。待っていたゲームの主要な敵で、視覚的なインパクトを持つ象徴の1つがその名を持ったのも偶然だ。

ゲームプレイの観点で見ると、8は「もう少し後で死のう」という私の大前提を壊さなかった、よくできた作品だった。ルクス・ルナエは視覚的によくデザインされた外形と、それに見合う凄まじい実力、聞いていて楽しい俳優たちのセリフがうまく組み合わされた敵だった。ゲーム全体が総合的な完成度を見せ、その象徴の1つであるルクス・ルナエもそこに貢献したと言えばいい。

直接相手をして感じた脅威と魅力を再現しようとした。今の大衆文化を見ると、魅力ある主人公や善人だけでなく、歪んでいて強力なのに魅力的な悪役のほうが長く語られると私は思う。シカリオのジョシュ・ブローリンや、トランスフォーマーのF-22にもそういう意図があると思う。

F-22・Su-57・MiG-31は、8に登場するルクス・ルナエ編隊の中で、最も悪役らしく感じた機種だった。ただ、F-16やタイフーンのように1つくらい違うデザインを入れ、変化をつければよかったかとも思う。3種類は大きく見るとデザインが似ていると感じるからだ。

原作のボス戦は、かなり難しいボスユニット1体と、他のステージにも出る通常ユニットが協力して攻撃する形だ。私はこの構成を少し平凡だと思った。最初の職場である雑誌社に入る前、Netmarbleのゲーム企画職の書類選考に通ったこともある。今回もプレイヤーの経験、ゲーム企画という観点で考えた。

原作アセットとユニットの動作コード、元のゲーム体験への介入を最小限にしながら、2つの効果を作りたかった。ボス戦の難度を上げようとした。また、ボス戦とその前の区間に、既存の敵とデザイン言語を共有しながら外形と性能に異質さがあり、倒すのも難しい敵を出して緊張感を与えようとした。

垂直離着陸機3機種は、元の敵を置き換えず配置の間に入れた。既存ヘリの移動と武装を使い、Codexが計算した追加数は14サブミッションに113機だった。既存の敵配置1,182項目は維持した。ルクス・ルナエ塗装の戦闘機は、ボス戦と直前ミッションの最終区間に増援として入れた。

戦闘機は既存のヘリのミサイルを再利用し、連続発射を加えた。耐久力は通常ヘリの最大値の1.7倍、ミサイルの移動速度は25%増にした。連射速度の増加は、最初の25%から10%へ下げるように言った。通常アプリで機体が画面内に突然現れるのを見て直させ、今は機体全体が画面右側の外から入ってくる。

原作ソースをできるだけ変更・調整せず原作の感覚を生かすという観点では、ルクス・ルナエの動きと武器使用手順は原作を外れていないと思う。画面外から速く飛び込む速度は、私がディレクションしたものではない。だがエースコンバット8のルクス・ルナエが使った高速一撃離脱や悪辣な旋回戦をある程度思い出させたため、その点はフィードバックせず残した。当時、固まって進入していた編隊は、v0.16で生成位置と進入先を広げて修正した。戦闘が始まった後にプレイヤーの周囲へ再び集まる動作は残っている。

移動と回避にさらに気を配らせるだけでなく、原作なら操作と標準的な武装で時間をかければ倒せたボスを相手に、「これは本当に必殺技を使うか、一度深呼吸して集中しないといけない」という緊張感を与えたかった。必殺技をほとんど使わず、面倒なときだけ使っていた私も、追加した敵を相手にすると、実際にクリアするため積極的に必殺技を使うようになった。

マップ外へ逃げてから再び現れるような変則行動のアルゴリズムも考えるべきか、検討している。現在の戦闘機は画面外から進入するように直した状態で、離脱して戻る行動は今後考えるアイデアだ。

私がテキストだけでディレクションしたとき、どこまで正確にデザインを出せるのか。既存ソースコードを再利用して動く機能を作れるのか。既存アセットを再利用して動く視覚効果を作れるのか。デザインからユニットの動作まで、私の指示を無視する要素が何パーセント出るのか。それが技術的に見たかった点だった。

他のプロジェクトと違い、別途ハーネスやエージェントを設定せず、モデルの性能と既存ソースだけでどこまで結果を出せるかも見ようとした。実際に、既存ヘリの武装と動きを再利用した敵がゲームへ入った。同時に、機体形状と原作の色調・質感に従う指示を破った案は作り直させる必要があった。

個人的な意味の大きい作業でも、Codexが私の指示にどこまで正確に従うかを確認し続けた。既存コードと絵を正しく読んで再利用したか、望んだ外形と動作を実装したかを、直接結果を見て判断した。誤った案は作り直させ、戦闘機が高速で進入する動きは残した。

編隊の進入間隔は直したが戦闘中の密集は残っており、画面外へ出てから再攻撃する動作を入れるかも考えている。2つのゲームから受けた影響をHeavyMachの戦闘にも込めた。今後何を変えるかも、自分でプレイしながら判断している。

この記事で扱う公開版は、2026年10月29日時点のv0.16だ。地上ユニットとHUD編集、新アイコン、編隊進入間隔の修正が入っている。CodexがiPhone・iPadの通常アプリとチートアプリを無線更新し、既存のセーブとHUD配置を維持した。私が両方の機器で直接プレイした際には異常は見られなかった。

初期の復元段階でCodexがMac上で実行した戦闘・入力・表示・音声・全画面の検査は33件が通過し、開発証明書で署名したアプリのリークは0件だった。10月27日のiPhone・iPad自動検査はそれぞれ85件中84件が通過し、表示時間の比較1件が失敗した。10月29日の後続計測でも、iPadの編隊進入区間のフレーム呼び出し間隔p95は21.39msで、基準20msを超えた。修正前と同じ条件での比較は残っている。

HUD編集を追加した後、ローカルのad-hoc署名で計測すると、6条件中3条件で処理時間の基準16.67msを超えた。修正前も5条件が基準を超えていた。以前の開発証明書による署名と条件をそろえた再計測、ウィンドウ表示の遅延調査は残っている。

実際のBluetooth・USBキーボードを接続する操作検査、長時間の発熱とメモリ変化、追加敵を含む全キャンペーンの難度確認は残っている。アラームアプリを使って戻るとゲームの音が消える問題も新たに報告したので、原因を調べる必要がある。

自動照準の状態案内とチュートリアル0-0〜0-4はまだ実装していない。Androidはアイコンを用意し、共通C++コアを使う計画だ。AndroidアプリやAPKはない。編隊も進入時の間隔は確保したが、戦闘中ずっと隊形を維持するAIは追加していない。

原作を復元して遊べるようにすることへ集中し、ビルド警告は全面的に調べて直せていない。一部の警告は、現在は使用を推奨されていないAPIに関係すると推測している。正確な原因はさらに調べる必要がある。ダウンロードからリソース準備・ビルド・実行までまとめるスクリプトも作りたい。Mac実行とiPhone・iPadインストールを選び、ツールや開発チーム・署名設定を案内する形だ。

Codexに、他の人もリポジトリを取得してビルドできるかを聞いた。ソースがあっても、画像や音源、マップが私のコンピュータにしかなければ実行できないからだ。Codexは必要なリソースをGitとLFSへ入れ、ファイル一覧とハッシュを記録した。公開mainを新規cloneした後、既存の作業フォルダと原本パッケージへアクセスできない状態で、ビルドとシミュレータ実行を確認した。

Apple Silicon MacでXcode、CMake 3.20以上、Python 3、Git LFSを使う。リポジトリをcloneするか、v0.16 Releasesからソース・リソースアーカイブを取得すればよい。LFSリソースを取得して検査ツールを実行し、workspaceを開いて自分の開発チームと実行先を選ぶ。通常アプリとチートアプリの実行構成をそれぞれ用意した。コマンドと4つの実行構成はAppsのインストール説明に記載した。

版ごとの記録もv0.9からv0.16までGitHub Releasesにまとめた。v0.16の後には、Codexがタグのコードとリソースをまとめ、リリースノートとハッシュを用意するツールをmainに追加した。パッケージと失敗後の再開は検査した。このツールで新しいリリースを実際に公開するのは次の版で行う。ほかの人がダウンロードからビルド・実行まで一度に行えるツールはまだ作っていない。

ゲームコード・画像・音源・マップを一緒に置き、何を復元し、どの問題を発見して直したかを記録した。作業ブランチをdevelopへ、developをmainへマージし、mainのマージコミットにリリースタグを付ける。そのタグから同じ版を再ビルドできるようにした。

私のプレイ動画から抽出した画像8枚、GIF 2本、音声付きMP4 3本もある。GIFは元の速度で再生する。ジャンプし、武器を選び、強化する元のゲームの流れと、新しい戦闘機や自動照準を実際の画面で残した。

地上ユニットとHUD編集の画面は、その後、実機のチートアプリで別途撮影したものだ。

私はこの復元版で金を稼ぐつもりはない。開発者の弁には、「コードとアセットを一緒に公開し、他の人も直接ビルドしてプレイできるようにしたい。このゲームをどう復元し、何を直したかも記録に残したい」と書いた。

新たに書いたコードにはMITを適用した。原作由来の資料と外部コード・文書の適用範囲は分けてある。原作の画像・音源・ゲームデータと追加画像はリソース利用条件に、OpenAL Soft・stbなどは外部ライブラリ告知に従う。原作者の開発と作画、私が追加するよう企画した作業の主体も、クレジットに分けて記載した。

後にsass.studioのApp Storeアカウントを作ることになり、原作者と利害関係者が配布を許可したら、そのときも無料で提供する。

私には残された時間があまりなく、金はこの世でしか必要のないものだ。