SOUTH+BRIDGE
Games AI翻訳

借りたエンジンへの請求書

エンジンはツールではなく、賃貸人となった。インディは発売前に自らの成功の持分を差し出す。釜山でゲームを一本作るということは、今や誰の土地の上で作るかという問題だ。

1UP · 2026年6月15日 · 約5分

AI要約

ゲームエンジンのビジネスモデルは、買い切りツールから継続課金モデルへと変化し、開発者の成功が負債となる構造を生んでいる。エンジンは技術ではなくエコシステムとして開発者を囲い込み、移行コストが賃料の上限を決定する。釜山のような小規模インディチームが生き残るには、初回プロジェクトから脱出口を設計変数として組み込む必要がある。

借りたエンジンへの請求書

Unityが2023年にランタイム料金制を発表したとき、私はそれが単なる値上げのニュースだと思った。インストール1回ごとに課金するという発想。開発者たちが立ち上がり、会社は数日で撤回した。CEOが交代し、政策は廃止された。事件は終わったように見えた。

しかし、その騒動が明らかにしたのは価格ではなかった。構造だった。エンジンが私のゲームの出荷ではなく、私のゲームの運命に課金すると宣言した瞬間、ツールと使用者の関係が何であったかが露呈した。エンジンはハンマーではなかった。エンジンは私の作業場の地主だった。

ツール代と賃料は違う請求書だ

伝統的にゲームエンジンはツールを売っていた。ライセンスを買えば、それで作ったゲームは自分のものだった。Unrealのロイヤリティモデルでさえ明快だった。一定売上を超えれば5パーセント。成功した分だけ取られるが、ルールはゲーム発売前に固定されていた。私は自分が何を譲歩するか知った上でスタートした。

サブスクリプションとランタイム課金は、その契約の時制を変える。ツール代は作る前に払う費用だ。賃料は作った後に、しかもうまく作れば作るほど多く流出する費用だ。インストール単位課金という発想があれほど恐ろしかったのは金額が大きいからではない。自分のゲームがヒットするほど、自分がコントロールできない請求書が膨らむからだ。成功がすなわち負債となる設計。インディ開発者にとって、これは単なるコスト問題ではなく、自らの成功の持分を事前に、そして永久に差し出す取引だ。

ツール代(従来型ライセンス)賃料(サブスク・ランタイム)
支払時期作る前に支払う作った後、成功するほど増える
ルール確定リリース前に確定(Unreal 5%)リリース後に判明
成功は即ち自分のもの負債
入口は滑らかで出口は粘着質―この非対称性が賃貸モデルのエンジン

批評家として私はゲーム内の経済をよく観察する。よく作られたゲームは、プレイヤーにリスクとリワードの関係を正直に示す。これだけ賭ければこれだけ返す。ランタイム課金モデルは正反対だ。開発者が何を賭けるかは明確だが、何を失うかは発売後にならないと分からない。カジノでチップを買うのに、換金レートをゲームが終わった後に教えられるようなものだ。

インディはなぜその刃を握らせるのか

それなら使わなければいいのでは。この反論は正当であり、半分だけ正しい。

Godotのようなオープンソースエンジンがある。MITライセンス、ロイヤリティゼロ、ランタイム課金ゼロ。Unity騒動直後にGodotへの支援が急増したのは偶然ではない。技術的にインディはすでに脱出口を握っている。2Dゲームならば、Godotは十分に成熟しており、ある面ではより軽快で速い。

問題はエンジンがコードを動かすプログラムではないことにある。エンジンはエコシステムだ。チュートリアル、アセットストア、採用市場で通用するキャリア、外注を出すときに話が通じる標準。釜山の小さなチームがUnityを捨てられないのは、ランタイム料金が怖いからではなく、Unityを知る同僚を探しやすく、Unityで作ったポートフォリオが次の仕事を運んでくれるからだ。依存は技術ではなく、人的資本と経路依存性によって固定される。エンジン企業はこの点を知っている。だから賃料を課すことができる。

ここで真の設計の狡猾さが見える。エンジン企業は開発者をツールで縛らない。開発者が積み上げてきた時間で縛る。私が5年間習得したワークフロー、私の手に染み付いたショートカット、私の会社wikiに記されたノウハウ。これを捨てるコストがすなわちスイッチングコストであり、そのスイッチングコストの大きさがすなわちエンジン企業が徴収できる賃料の上限だ。

摩擦をどこに置くか

私は常に、面白さは摩擦から生まれると書いている。良いゲームはプレイヤーに意図された拒絶を突きつける。ダークソウルが親切でないからこそ、その勝利が価値あるものであるように。ツールも同じだ。滑らかすぎるツールは、あなたをその滑らかさに馴らす。

エンジン依存の本質は摩擦の配置の問題だ。作るときの摩擦をなくす代償として、去るときの摩擦を増やす。入口は滑らかで出口は粘つく。この非対称性が賃貸モデルのエンジンだ。だからインディが考えるべきは、どのエンジンがより便利かではなく、どこに摩擦を置くかだ。今少し不便なオープンソースを選んで去る自由を確保するか、今便利な商用エンジンを選んで自分の成功の持分を担保に差し出すか。

釜山インディシーンにとって、これは抽象的な話ではない。ここのチームは大抵小さい。2、3人、多くても5、6人。1人が去ればワークフロー全体が揺らぐ規模だ。そんなチームほどスイッチングコストの衝撃が大きく、だから賃貸モデルにより深く縛られる。大手スタジオは自社エンジンを作る余裕がある。小さなチームにその選択肢はない。

私の提案はシンプルだ。最初のプロジェクトから出口を設計変数として組み込め。コアロジックをエンジンに依存しない純粋なコードとして分離し、アセットパイプラインを標準フォーマットで維持し、少なくとも次のプロジェクト1本はオープンソースエンジンで作ってみろ。これは理想主義ではなく交渉力だ。去ることができる者だけが、留まる値段を下げられる。ゲームをうまく作ることと、うまく作ったゲームの取り分を守ることは別の技術だ。釜山の小さなチームが次の10年を生き延びるには、2番目の技術を最初のプロジェクトから練習しなければならない。

この記事はAIが韓国語の原文を自動翻訳したものです。正確な内容は韓国語の原文をご確認ください。

韓国語の原文を読む →