オンラインゲームのオフライン化はなぜ難しいのか

『The Crew』の終了をきっかけに、欧米では「Stop Killing Games」のような動きが広がりました。遊べなくなった作品を残してほしい、という要望が強くなるのは自然です。
ただ、『オンライン版をオフライン版に作り替える』ときに、現場で何が起きるのかはあまり共有されていません。

タイトル画面の先で止まるとか、ログインだけ通らないとか、その程度の話ではありません。進行、所持品、敵の挙動、報酬、乱数、認証、不正対策まで、オンラインではサーバーが支えていた部分が広く入っています。見た目は同じゲームでも、成立の仕方はローカルゲームとはかなり違います。

このあたりが共有されないまま議論が進むと、開発の怠慢なのか、企業の都合なのか、という見え方にもなりやすいです。実際には、もう少し作業の中身を見てからでないと判断しにくい部分があります。

ここで書きたいのは、新しく作るゲームを最初からオフライン化前提にすべきか、という話ではありません。そうではなく、もともとオフライン化を想定していないオンラインゲームを後からオフライン化しようとすると、どんな困難が出るのか。その中身を整理してみます。

想定以上に重いサーバーの役割

オンラインゲームでは、ゲームの正しさをサーバーが握っていることが多いです。

たとえば、クエストの進行状態をどこまで許可するか。アイテムを何個持っているか。敵を倒した結果として何を配るか。乱数の扱いをどこで決めるか。認証した利用者にどのデータを返すか。こうした処理がサーバー側に集まっていると、クライアントは見た目を表示して入力を受ける役割が中心になります。

この状態のゲームをあとからオフライン化する場合、サーバーの責任をどこに移すかを決め直さないといけません。クライアントに寄せれば遊べるようには見えますが、そのままではセーブ改ざん、報酬の不整合、復帰時の破綻が出やすくなります。逆に、元の仕組みをなるべく維持しようとすると、今度はローカルで持つには重すぎる構成になります。

外から見ると、この作業は見えにくいです。通信を切る作業ではなく、成立条件の置き場所を組み替える作業だからです。

マルチ前提のゲームはゲームデザインから組み替える

もう一つ大変なのは、オンラインゲームではゲームデザイン自体が通信前提で組まれていることです。

複数人で遊ぶことを想定していれば、難易度の置き方が違います。報酬の量も違います。待ち時間の許容も違います。イベントの回し方も変わります。誰かと役割分担する前提で作られた戦闘を、そのまま一人用に落とすと、単調になるか、極端に厳しくなるか、そのどちらかになりやすいです。

そのため、見直す対象は通信処理だけではありません。ソロで成立するテンポにするのか。人が担っていた役割をAIで置き換えるのか。報酬をどう調整するのか。保存設計をどうするのか。ここまで触らないと、動くけれど面白くない状態になりがちです。

ここは実務でも線引きが難しいところです。技術的に起動することと、商品として成立することは別だからです。最低限遊べる形を残すのか、元の体験に近づけるのかで、必要な工数はかなり変わります。

コード以外にも必要な後付け変更

もともとオフライン化を想定していないタイトルでは、運営中に必要だった要件が優先されて積み上がっています。イベント対応、障害対応、不正対策、性能対策、外部サービス連携。現実の開発では、その時点で必要なものから順に積まれていきます。

そのため、サービス終了が見えてきた段階でオフライン化を検討すると、コード変更だけでは済みません。どの機能を残すのか。どこを諦めるのか。保存データは何を持てば成立するのか。復帰時に壊れないのか。仕様の整理から入り直す場面も多いです。

他の方からは、開発管理の面でも難しさがある、という意見も頂きました。サービス終了が見えているタイトルでは、その前段階で開発体制がかなり縮小されていることがあります。主要な開発者がすでに別案件へ移っていたり、会社を離れていたりすることもあります。協力会社を含む体制だった場合は、なおさら当時の設計意図や実装の経緯をたどりにくくなります。結果として、最低限の運営を続けるための少人数体制に、重い改修を載せる形になりやすいです。

ひとつ直すと別の部分が崩れることもあります。サーバー側で吸収していた不整合が、ローカルに寄せた瞬間に表に出るからです。そこを一つずつ埋めていく作業は、見た目以上に地道です。

新機能追加というより、ゲームの土台の置き換えに近いです。工数が膨れやすいのは、そのためです。

サーバー公開で済む話にはなりにくい

では、終了するならサーバーを公開して有志に任せればよいのか。こうした意見も出てきます。

ただ、サーバー側にはゲームの処理だけが入っているわけではありません。認証、不正対策、監視、運用のノウハウ、障害対応の仕組みなど、運営そのものに関わるものが含まれます。外部ミドルウェアや契約上の制約が混ざっていることもあります。そこを切り分けずにそのまま出すのは、かなり難しいです。

加えて、終了したタイトルで使われていた仕組みが、別の現役タイトルや今後の開発につながっていることもあります。利用者から見ると過去の作品でも、企業側から見ると技術資産の一部です。そこを丸ごと公開しにくいのは不自然ではありません。

また、有志に任せれば残せる、という話もそこまで単純ではない、という意見も頂いた事があります。仮に引き継いだ先で致命的な不具合が出たり、善意か悪意かを問わず介入によってバランスが大きく変わったりすると、それを元の作品と同じものとして扱ってよいのか、という問題が残ります。遊べる形が残ることと、そのタイトルとしての価値や体験が保たれることは、必ずしも一致しません。この点を気にして、公開や移管に慎重になる判断もありえます。

作品を残したいという要望にも筋はあります。公開に慎重になる企業判断にも事情があります。ただ、その間にある作業や制約は、外から見えるよりかなり多いです。

まとめ

上記で見てきたように、オンラインゲームのオフライン化は、通信を外せば終わる作業ではありません。サーバーが持っていた責任をどこに移すのかを考え、マルチ前提の遊びをどう成立させ直すかを考え、保存や整合性まで組み替えていく必要があります。

なので、後からオフライン版を作ってほしいという要望に対して、対応できないタイトルが多いのは不思議ではありません。そこには、タイトルを残したいという話だけでは片づかない、大きな現実があります。

おわりに

X（旧Twitter）やBlueskyを中心に日々発信しております。
ご興味をお持ちいただけましたら、ぜひ弊社Webサイトや私のXもご覧いただけますと幸甚でございます。

https://www.tatsu-mi-systemsolution.jp/
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social