EVE Onlineが240万行のPython 2をPython 3へ移行開始

CCP Gamesは2026年8月25日、EVE OnlineをPython 2からPython 3へ移行し始めた。ゲーム自身の サイトに載った開発者向け投稿によるものだ。古いコードを保守する人にとって興味深いのは、規模と 手法である。約2万ファイルにわたる240万行を、ゲームを稼働させたまま移す。

EVEは2010年からStackless Python 2.7の上で動いている。Stackless Pythonは、非常に高い並行性の ために作られたPythonの改変版だ。CCPの投稿は、その「軽量な『タスクレット』」のおかげで「1つの サーバーノードが数千人のパイロットを同時にさばく」ことができるとしている。タスクレットは、 プログラムが安く一時停止して再開できる小さな作業単位である。だから1台の機械が、1人につき 1スレッドを持たずに多数のプレイヤーを追える。

すでに直った部分と、まだの部分

CCPの投稿にある数字が役に立つ部分だ。同社によれば、コードベースの95.9%はすでにPython 2と Python 3の両方で構文解析できる。構文解析とは、1行を実行する前に、インタープリタがファイルを そもそも読めることを指す。

そこで問題が2つ残る。約3,300行はPython 3ではまだ構文解析に失敗し、書き直しが必要だ。もっと 大きな集合、約2万行は問題なく構文解析できるが、2つのバージョンで挙動が異なる。後者のほうが やりにくい。どこにあるかを教えてくれるクラッシュが起きないからだ。

CCPは段階を分けて進めている。いま動いている第1段階は、ゲームをPython 2.7に置いたまま、両方で 有効になるようコードを書き換える。まだ来ていない第2段階は、挙動が異なる行を扱う。投稿によれば、 Futurizeのように広いPythonコミュニティがすでに作った道具を使う段階もある。EVE固有の機能を 狙う段階もある。

Stackless Pythonが行き止まりである理由

とどまるのは現実的な選択ではなかった。Stacklessプロジェクトは2025年2月、読み取り専用として アーカイブされた。CCPの2025年Fanfest講演をまとめたThe Nosy Gamerの記事によるものだ。 アーカイブされたプロジェクトは以降のリリースを出さない。だからその上に築いたものも動かなくなる。

同じ記事は、CCPがエンジン層で既に終えた移行を扱っている。これは今週のニュースと分けて考える 価値がある。CARBONはCCPの各ゲームが共有するエンジンだ。2023年11月にStackless Python 2.7から Stackless Python 3.8.1へ移った。その後、標準のPython 3.12へ移り、2024年6月にまずEVE Frontierで 出荷された。The Nosy Gamerは、CCPがエンジン性能で平均20%の改善を計測したと報じている。記事は 2つ目の、より静かな利点にも触れる。Python 3.12にはtracemallocが同梱される。メモリ追跡の 組み込みツールで、CCP社内のツールよりうまくリークを見つけた。The Nosy Gamerは移行の率直な人員面の 理由も挙げている。CCPに入る新しいプログラマーがPython 2.7の経験を持っていないことだ。

時期	何が移ったか
2007年	EVEがStackless Python 2.5へ
2010年	EVEがStackless Python 2.7へ
2023年11月	CARBONエンジンがStackless Python 3.8.1に到達
2024年6月	CARBONがPython 3.12に到達、EVE Frontierで出荷
2025年2月	Stackless Pythonがアーカイブ、読み取り専用に
2026年7月	EVEの移行をテストサーバーSingularityで検証
2026年8月25日	第1段階が本番サーバーTranquilityで稼働

プレイヤーが今得るもの

何もない。CCPはそうはっきり述べている。短期的にプレイヤーには何が変わるのかという問いに、 投稿はこう答える。「短期的には何も変わらない。そしてそれは設計どおりだ」。約束された見返りは 後から来る。平たい言葉で示されている。バグ修正が速くなり、道具が良くなり、新機能の余地が生まれ、 時間をかけてゲームが速くなる。

開発者にとっての意味

95.9%という数字が、借用すべき数字である。CCPが追っているのは「移行済みの割合」ではない。 両方のバージョンで同時に構文解析できる割合を追っており、それは今日CI上で走らせられる計測だ。 対象のインタープリタで全ファイルをコンパイルし、失敗を数える。すると、あいまいな見積もりの 代わりにバーンダウンの図が手に入る。怖い移行が、数えられる移行に変わる。

CCPがどちらを本当の作業と見ているかに注意したい。構文解析できない3,300行は、騒がしく、そして 有限だ。単に挙動が違うだけの2万行がリスクである。整数の除算、辞書の順序、文字列とバイト列の 違いは、エラーではなく誤った答えを生むからだ。似た移行を計画するなら、何も投げられなかったことだけを 確かめるテストではなく、値を確かめるテストに投資すること。

二重稼働の戦略は、多くのチームが飛ばしがちで、飛ばすべきでない部分だ。インタープリタを 切り替える前に両方のバージョンで有効なコードにしておけば、すべての変更が普段のリリース経路を 通る。古いランタイムの上で、一斉切り替えの日を作らずに進む。紙の上では遅く、実際にはずっと 安全だ。止められないサービスでは特にそうである。

最後に、ランタイムの上流の健全さを本物の依存として扱うこと。CCPの制約はPython 2ではなく、 いまアーカイブされたフォークであるStacklessだった。今日ある問題を見事に解くフォークは、明日には 自分のプラットフォームの上限になる。だから重要なフォークが最近何を出荷したかを確認すること。