为何选择 Unity 的企业易陷“赤字体质”：从 Flash 历史看技术选型的结构性风险

※关于本文
本文基于笔者在游戏开发一线所面临的课题感与经验，通过与AI（Antigravity / Gemini）进行陪练与讨论，由AI整理并撰写而成。

前言：为何“改用Unity就能更快制作”难以实现

在游戏开发现场，在新项目的技术选型中，仅因“现在很流行”或“更容易招募到有经验的人才”而选择Unity的情况并不少见。

其中往往寄托着以下期待。

• “使用Unity的话，开发周期应该能缩短一半。”
• “即使人员稀少，也能制作出内容丰富、高品质的游戏。”

然而，在实际的商业开发现场，我们听到的往往不是“开发周期缩短了”的说法，而是“由于过度追求丰富的表现力，导致需求标准通货膨胀，反而使开发周期和工时膨胀” 的声音。

本文并非要批判特定的引擎，而是从“业务盈亏平衡点”、“CI/自动化运维成本”以及“企业级开发的前提条件” 这些结构性视角出发，梳理为何仅因“流行就选择Unity”这种轻率的决策容易让一线团队疲惫不堪，以及如何采取务实的生存策略，避免重蹈昔日 Adobe Flash 的历史覆辙。

1. 容易被忽视的“许可证固定费用”与盈亏平衡点的上升

在技术选型的讨论中，人们往往只关注功能和渲染性能，但从商业角度来看，有一个不容忽视的事实是：“许可证的固定费用会直接推高业务的盈亏平衡点” 。

面向包括非工程师在内的“全岗位许可证分发”的过度投资

在具有一定规模的开发组织（例如数十至百人规模的团队）中全面采用 Unity 时，许可证不仅分发给工程师，还会分发给以下各类岗位，从而导致组织中大部分人员（接近80%）都持有付费席位 的情况频发。

• 工程师 / 技术美术
• 导演 / 策划
• 关卡设计师
• 设计师
• QA（质量保证）

假设以数十至80人的规模签约Unity Pro（1个席位年费约34万日元），从开发开始之前起，每年都会产生数千万日元规模的固定费用。

「必要売上」が高くなるという構造的リスク

本来、昔ながらの C++ ベースの実装や自社エンジン、あるいは cocos2d-x や Godot のようなライセンス費ゼロの環境で開発していれば、人件費と最低限のインフラ費だけで済むため、小〜中規模のヒットでも十分に黒字化できます。

しかし、高額なライセンス固定費が毎年乗ることで、「最低限確保しなければならない売上ライン（損益分岐点）」が跳ね上がり、一定以上の大ヒットを出さないと利益が出ないハイリスクな体質 へと変化してしまいます。

2. 「CI/E2E自動テスト」を回そうとした瞬間に直面する三重苦

近年では、AI（VLM：視覚言語モデル）を使ったUIのレイアウト崩れチェック、レベルデザイン調整のためのバトル周回シミュレーション、特定画面の自動スクリーンショット撮影などを CI（GitHub Actions 等）で回したいというニーズが高まっています。

ところが、Unity でこれを実現しようとすると、Web開発の感覚では想像できないほどの「ライセンス制約」と「インフラ構築の手間」が立ちはだかります。

① 并行执行数量限制导致许可证消耗

对于有一定收入的企业，即使在 CI 上使用免费版（Personal）也违反服务条款。此外，在使用 Unity Test Framework 等工具以批处理模式启动 Unity 编辑器进行端到端（E2E）测试的并行执行时，需要与同时启动的容器或机器数量相匹配的付费许可证（Pro 或 Build Server）。

无法像 Web 开发那样“轻松地在 10 个、20 个免费 Docker 容器中并行运行测试”。

② 因不同职能流程差异导致的“构建等待拥堵”

为了将许可证消耗控制在 1 行（仅用于构建），可以配置“在一台机器上构建，然后将生成的二进制分发给多个测试运行器”的结构。然而，在实际工作中，由于多名开发者会同时提交 PR，最终仍会出现 “构建排队拥堵”。

而且，各职能需要确认的关注点各不相同。

如果将这些全部纳入统一的沉重 Unity 构建管线，只会徒增等待时间，因此现场不得不将大量工程工时耗费在与游戏本质无关的基础设施黑客式手段上，例如“缓存主分支基线构建并仅外部注入数据与资源”或“通过 PR 标签进行触发分流”。

③ 厚重状态（Library 文件夹）的维护成本

管理膨胀至数 GB 至数十 GB 的 Library 文件夹缓存，以及维持 macOS 构建专用的 Runner 等，原本应用于开发游戏内容的宝贵时间与成本，被环境维护工作不断吞噬。

[Web開発 / C++・自社エンジン / cocos2d-x / Godot]
  コードPush ─> 軽量コンテナを並列起動（ライセンス費 ¥0） ─> 即座にテスト・検証完了

[Unity (商業開発)]
  コードPush ─> ライセンス枠の空き待ち ─> 巨大なLibraryキャッシュ復元 ─> 重いビルド
                    └─ これを回避するための独自基盤開発にエンジニア工数が奪われる

3. “小规模团队能快速打造丰富内容”这一幻想的实质

然而，人们经常反驳说：“个人开发者或小规模团队不也在用 Unity 在短时间内制作出内容丰富的游戏吗？”

但是，这里被忽视的是 “个人开发（独立游戏）”与“一般企业的商业开发”之间决定性的前提条件差异。

个人开发之所以能够以“快速、低成本且内容丰富”的方式制作游戏，最大的原因在于可以充分利用资产商店的现成素材和通用插件。

对于商业作品而言，必须避免与其他产品外观雷同；而对于着眼于长期运营的企业级开发，则希望避开黑盒化的外部工具。在这类情况下，无法享受Unity的最大优势——“通过资产商店实现捷径”。结果就是所有东西都必须自行开发，最终只有工具的丰富功能和沉重负担会压在项目上。

4. “为人才获取而使用Unity”这一自相矛盾之处，以及重演的Flash历史

公司方面推动“因为流行所以用Unity”的最大理由是“更容易招聘到人才”。确实，传统基于C++的自研引擎或cocos2d-x等技术的工程师数量在减少，市场上拥有Unity经验的人才较多也是事实。

然而，这里潜藏着一种自相矛盾（鸡生蛋、蛋生鸡的恶性循环）。

「选择 Unity 是为了确保人才，但之所以需要大量人才，是因为游戏的丰富化导致开发规模膨胀」

本来应该制作那些可以用少人数、低成本（C++、自研引擎、cocos2d-x、Godot 等）完成的范围的游戏，这样就不需要确保大量人才和高额的许可证费用。然而，由于过于以“丰富化”为前提，陷入了以下恶性循环：

1. 追求丰富的表现，导致开发规模和工期膨胀
2. 人手不足，于是选择了容易招聘的 Unity
3. 因为使用了 Unity，要求标准（期望值）进一步提高，演出和工时随之增加
4. 为了收回面向所有职位的许可证费用和增加的人力成本，转向追求更高销量的大作方向

与曾经的 Adobe Flash 完全重合的进程

这一结构与 2000 年代后半至 2010 年代初浏览器游戏全盛时期的 Adobe Flash 的兴衰起伏惊人地一致。

1. 凭借‘易于采用、易于协作’形成的单一强势格局: 业界标准变为，只要雇佣 Flash 工匠，就能与设计师协作制作出丰富的游戏。
2. 因丰富化竞争导致的膨胀: 起初由数人在数周内即可完成的轻量级游戏，为了差异化而将演出和动画极致丰富化，导致开发成本飙升。
3. 对特定企业的完全锁定: 从内部框架、资产到人才技能，完全依赖特定企业的专有规格，结果在规格变更或方针转变时无法脱身。
4. 向轻量、开放标准的回归: 变得厚重庞大的 Flash 最终被轻量且开放的 HTML5 / JavaScript（以及原生）夺走了主角地位。

如今，面对“过于沉重、受许可证束缚的 Unity”，人们开始重新评价“轻量且不受许可证限制的 C++ 基础、自研实现，或者开源（MIT 许可证）的 Godot 及 cocos2d-x 系（如 Axmol 等）”，这一趋势正是当年“Flash vs HTML5”格局的翻版。

5. 作为现场工程师的现实生存策略

那么，在这种结构性陷阱之中，一线的工程师以及参与技术选型的人应当如何应对呢？现实可行的做法大致有两个。

战略①：从盈亏平衡点（必要销售额）出发选择引擎的组合

不是把所有项目都一律套用高成本的结构，而是要有“根据目标销售额规模和范围来区分使用引擎”的视角。

• 可望获得高收益的大型 3D 项目：发挥招聘能力和 SDK 支持速度的优势，采用 Unity。
• 2D 中心・小〜中規模・運用型案件: ライセンス費ゼロで CI も軽快に回る 昔ながらの C++ / 自社エンジン実装 や cocos2d-x、あるいは Godot といった環境を活かし、「低い売上でも確実に黒字になる体質」を守る。

特にすでに社内に C++ ベースの自社エンジンや cocos2d-x の知見・資産がある場合、それは他社が今から真似しようとしてもできない「低コスト開発の強力な武器」です。流行に流されて軽量開発ラインの火を完全に消してしまうと、将来採算が合わなくなった際に戻れる場所を失います。

戦略②：それでも Unity を使うなら「クリーンアーキテクチャ + DI」で脱Unity依存を徹底する

事業判断として Unity を使う場合でも、「社内フレームワークやゲームのコアロジックまで Unity（MonoBehaviour や UnityEngine 名前空間）に密結合させない」 ことが極めて重要です。

┌───────────────────────────────────────────────────────────┐
│ Unity 依存層 (Adapter / View / Composition Root)          │
│   - MonoBehaviour, SpriteRenderer, UI, サウンド再生       │
│   - VContainer / Zenject 等での DI 組み立て               │
└─────────────────────────────┬─────────────────────────────┘
                              │ Interface 経由で接続
                              ▼
┌───────────────────────────────────────────────────────────┐
│ 純粋な C# (.NET Standard 2.1) コア層                      │
│   - バトル計算・ステートマシン・マスターデータ管理        │
│   - 通信基盤・暗号化・社内共通フレームワーク              │
│   ※ using UnityEngine; を一切禁止 (asmdef で強制分離)     │
└───────────────────────────────────────────────────────────┘
         │
         └─> CI 上では Unity ライセンス不要の `dotnet test` で
             無料コンテナを使って無制限・高速に並列周回テスト可能！

1. コアロジックと社内基盤を純粋な C# に分離する: asmdef（Assembly Definition）で UnityEngine への参照をコンパイルレベルで禁止し、バトル計算やデータ管理を独立させます。これにより、Unity ライセンスを 1 つも消費せず dotnet test だけでバトル周回やバランス検証を無制限に並列実行 できます。
2. エンジン機能は Interface で抽象化する: 時間経過（ITimeProvider）やアセット読み込み（IAssetLoader）などをインターフェース越しに扱い、テスト時はモックを差し込めるようにします。
3. DI 应限定为构造函数注入: 如果不在领域层引入特定 DI 框架固有的属性（如[Inject]等），而是仅通过标准 C# 的构造函数进行接收的设计，那么在将来万一迁移到其他支持 C# 的引擎（如 Godot C#）时，核心资产可以直接移植。
4. 减少非工程师的许可证数量: 通过将总监、QA、关卡设计师的画面确认和数据调整工作转移到“CI 自动生成的实机构建分发”和“Web 管理界面/电子表格”，可以大幅压缩编辑器许可证的合同数量。

总结

• “选择 Unity 就能更快更便宜地制作”这一说法，只有在允许复用资产的独立开发前提，或存在严格范围限制的情况下才成立。
• 在商业开发中，若因“流行”而无意识地选择 Unity，并展开向所有职位分发许可证以及追求功能丰富化的竞争，将导致许可证固定费用、CI 构建工时、开发周期呈滚雪球式膨胀，从而推高事业的盈亏平衡点。
• 从历史角度来看，这与曾经 Adobe Flash 所经历的‘易于采用 → 因功能丰富化而膨胀 → 锁定’的流程 同型。
• 作为现场应采取的措施，是「不消除传统 C++ 实现、使用自研引擎或轻量级引擎（如 Godot / cocos2d-x 等）进行低成本开发的选项」，以及 「即使使用 Unity，也要通过整洁架构 + DI 将核心资产从引擎中分离，构建出不会因特定商业平台而陷入困境的结构」。