跳到正文
Qiita · Unity 开发社区· 来源· sator_imaging·· 2 小时前AI 评分53

AI生成多视角反论：Unity企业赤字体质论的局限与替代方案陷阱

🤖「Unityを選ぶ企業は赤字体質である。」に対する反論

正文 · AI 翻译

前言

我被这篇文章的标题所吸引，在仅粗略阅读了开头、尚未阅读全文之前，向 Gemini / Claude 发送了以下提示词。

Unityを選ぶ企業は赤字体質である。
https://qiita.com/roripika/items/bdeb5537efc1f27af726

これを読んで、例えば (UE|Godot) なら上手くいくのか、という視点で反論記事を書いて。
反論自体を目的とせず、認めるべきは認めること。
また隣の芝生は青く見えるという視点を持って論を展開すること
（つまりそんなうまい話は無いのではないか、と私が思っているという事）

我对本文的看法仅限于 👆 中的提示词，以下内容是未经任何润色或对话交互的 AI 直接输出，并非意在表达或暗示任何内容。

  • 想要不同的视角
  • 不如先让 AI 生成后再阅读？
  • 既然这样，干脆上传一下吧

这是一份基于轻松心态的内容。请在理解这一点的基础上阅读。

🤖 【Claude】如果Unity成本高，换成UE不就行了吗？——数一数隔壁的草

对《“选择Unity的企业具有赤字体质。”（Qiita, 2026-11-13）》的回应。数据基于截至2026年11月的官方页面等。

先谈谈原文中我同意的部分

原文称这是“将作者的问题意识与AI整理后的结果”，但我认为其诊断框架相当准确。

  • Unity的席位费用是固定成本，人数越多，盈亏平衡点就越高。截至2026年，Unity Pro为每席位每年2,310美元。原文中换算成日元约34万日元的数字是合理的。
  • 盈利企业同样无法在 CI 中使用 Personal 版本，并行数受许可证数量限制的约束确实存在。
  • “小团队也能快速实现丰富内容”这一说法，往往基于个人开发者可以复用资产商店资源的前提。而企业开发的前提则不同。
  • 被特定供应商绑定条件的风险也确实存在。Unity 曾发布过运行时费用后又予以撤回，随后改回按席位收费模式，Pro/Enterprise 版本于 2026 年 1 月上涨了 5%。

让我在意的是另一个方面。原文的开药方是自家 C++、cocos2d-x 和 Godot，并未推荐 UE。尽管如此，现场最常出现的疑问依然是：“如果 Unity 太重，换一家大厂不就能解决了吗？”对于游戏而言，UE 席位费为零，源代码默认可读，仅从许可证角度看，它是最具优势的“邻家草坪”。那么，我们将原文的论点直接套用到 UE 上试试。先说结论：成本并不会消失，只是转移了位置。

1. 固定成本不会消失，而是转化为可变成本

UE 的游戏许可证无需席位费，对超过 100 万美元的产品终身总收入部分收取 5%，通过 Epic Games Store 的销售则免除费用。这确实是极好的条件，从结构上回应了原文中“必要销售额会飙升”的问题。对于小规模成功或未成功的作品，UE 具有优势。这一点我坦率承认。

ただし、売上が伸びると話が逆転します。ざっくり試算します（前提：1ドル=150円、80席、運用3年、$1M=1.5億円）。

  • Unity：80席 × $2,310 ≈ 2,770万円/年。3年で約 8,300万円。
  • UE：生涯グロス L に対して 5% × (L − 1.5億円)。
  • 逆転点は L ≒ 18億円。生涯グロス100億円なら UE のロイヤリティは約4.9億円で、Unity の席料の約6倍。

なお UE のロイヤリティは、ストアが徴収した分も含めた総売上が対象です（EGS を除く）。

つまり UE は 下振れに強く、上振れに弱い。元記事の「大ヒットしないと黒字にならない体質」の裏返しが「大ヒットしても取り分が目減りする体質」です。どちらが良いかは、そのタイトルの売上の期待値の分布で決まります。

还有一点。我们来看看席位费本身的规模。假设每人每年的总成本为1,000万日元，80人就是每年8亿日元。Unity的席位费2,770万日元约占其中的3.5%。影响盈亏平衡点的主要因素是人数×时长，而许可费用则是次要因素。这与原文第4章指出的“随着画面丰富化，开发规模膨胀”的观点是一致的。真正起作用的是需求标准，正如原文战略②所述，席位数量是可以精简的。

2. CI：许可费会消失，但负担不会消失

这里也从值得认可的地方说起。UE没有CI的许可限制。即使增加容器或构建代理，产生的费用仅仅是机器成本。官方也提供了Horde、BuildGraph、UBA（Unreal Build Accelerator）等分布式构建工具。原文②中提到的“并行数消耗许可”在UE上几乎不适用。

但是，原文真正困扰的问题在于“构建等待的拥堵”和“沉重状态的维持”。在这方面，UE反而更重。

  • 根据开源构建工具Ludus的前提条件记载，针对专用服务器的构建需要使用从源代码构建的引擎，而非启动器版本。有报告称包含调试信息的完整构建超过350GB，也有报告称首次构建需要数小时甚至超过10小时（取决于硬件）。
  • Epic官方论坛上也有报告称，大型项目的开发构建约需8小时，生产构建约需18小时。另一方面，如果整备好Horde + UBA + 缓存，编辑器的CI构建可以在10分钟以内完成。虽然可以变快，但这种整备工作本身会成为专业人员的职责。
  • 作为与 Unity 的 Library 缓存问题相当的情况，UE 存在 DDC/Zen、Intermediate、cook 结果、着色器编译。这一点同样需要 macOS/iOS 专用的 runner。

原文中“工程师工时被夺走用于与游戏本质无关的基础设施黑客行为”这一结构，在 UE 中只是从许可证方面转移到了工时方面，有时甚至会增多。即使可以免费进行 20 个并行任务，但如果一个作业需要数小时才能完成，拥堵也不会得到解决。

不同职能的流程差异（例如策划希望无需构建即可运行等）属于引擎非依赖的话题。这由数据驱动的程度和分离设计决定，更换引擎也无法解决。

我们也来考虑一下战略②（将纯粹的核心层分离并在引擎外进行测试）的 UE 版本。创建纯 C++ 核心层并在 UE 外部进行测试是可能的（也可以通过 Build.cs 的模块依赖来限制引用方向）。不过据我理解，UE 的 C++ 以 UObject、反射、GC 等独特的类型系统为前提，因此要保持引擎非依赖的核心，需要比 C# + asmdef 更多的有意识的设计纪律。Unity 的“通过 asmdef 在编译时强制禁止 UnityEngine 引用，并通过 dotnet test 运行”在这方面属于相当廉价的一类。

3. “少人数实现丰富”：UE 的预期膨胀可能更强

正如原文第3章所述，企业开发的架构难以复用商店资源。UE 的 Fab（Marketplace）情况也是如此。

此外，UE5 在 Lumen、Nanite、World Partition 等技术的加持下，即使默认设置也能呈现出出色的视觉效果。如果默认效果已经很好，那么竞争对手也会提供类似的视觉效果。这样一来，“丰富性”就成了最低标准。原文中提到的“转向 Unity 后要求标准进一步提高”，在 UE 环境下应该会表现得更为强烈（这是我的推测，尚未得到证实）。

相反，以 2D 为主、中小规模运营的项目并非 UE 的强项。多年来一直有报告指出，即使在移动端创建一个空项目，其包体积也会达到数十到一百多 MB（由于多为旧版报告的记录，需确认当前版本的情况）。原文中关于“2D 及中小规模项目应选择轻量级引擎”的观点，与 UE 相比也是合理的。

4. 人才与锁定：Flash 的教训同样适用于 UE

人才。 在日本的移动游戏和运营领域，通常认为拥有 Unity 经验的人才更为充裕（尚未核实市场统计数据）。UE 基于 C++，招聘和培养成本往往较高。原文中提到的“为确保人才而使用 Unity 这一自相矛盾的现象”，敏锐地指出了丰富化导致人员膨胀的问题。然而，即使转向轻量级引擎或自建 C++ 引擎，人才问题也不会消失。选择人才市场较小的技术，意味着将人才风险留给自己承担，原文也承认了能够处理 C++ 自建引擎的人才正在减少。

ロックイン。 Epic も条件を変えてきました。UE 5.4 から非ゲーム向けに席課金が導入され、2026年5月27日からは Unreal Subscription に Twinmotion と RealityScan が含まれなくなりました。ゲーム向けのロイヤリティは据え置きですが、「条件は変わりうる」は Unity だけの話ではありません。

Flash との同型性。 警告としては有効です。ただ Flash の衰退は、iOS 非対応を含むプラットフォーム側の転換が大きな要因とされ、「重さ」だけでは説明できません。Unity や UE はネイティブにビルドするので、ブラウザプラグインだった Flash とは構造も違います。同型とまでは言い切れないと思います。

まとめ：元記事の論点を UE に当てはめると

論点 Unity UE
ライセンスの形 固定成本相当于席位数量 无席位费 + 终身销售额超过100万美元时收取5%
小规模成功的情况 固定成本负担重 有利
大获成功的情况 席位费相对较小 版税较大（粗略估算超过约18亿日元，实现逆转）
CI 的许可限制 有 几乎没有
CI 的重量与环境维护 Library 缓存等 源码构建、DDC/Zen、cook 等反而更重
引擎无关的设计 使用 C# + asmdef 相对容易 可行，但需要更强的设计纪律
2D / 小型运营型 经验积累深厚 并非核心技能
日本的人才市场 以深厚著称 由于以C++为前提，招聘成本往往较高

结论：成本只是被保存了下来

更换引擎的操作，本质上是将成本放置的位置进行转换。从Unity迁移到UE时，固定成本会转化为可变成本，许可费用会变成基础设施的工作量，而人才市场的厚度则会以表达能力的提升为代价来换取。这些成本都不会‘消失’。

我认为原文的诊断（固定成本、CI 限制、前提条件的差异、供应商依赖）大体上是正确的。处方中，战略②（将核心从引擎中分离出来）对任何引擎都有效，因此我觉得它是最强的。比起选择引擎，在设计中决定不依赖于引擎的资产比例，是更不依赖“邻家青草”的方法。我也同意战略①（按用途分别使用），但希望考虑到轻量级引擎或自研 C++ 也存在人才和维护这些隐藏成本。

标题中的“赤字体质”断言得有些过于强烈了。原文的数字是基于“所有职业约80个席位”这一假设，仅减少席位数就能大幅缩小影响。

\n尚未确认的事项

  • 日本市场各引擎的人才数量、招聘单价的实际数据
  • 每人年薪（1,000万日元）、汇率（150日元）、席位数（80）、运营年数（3年）均为假设
  • 构建时间和包大小基于官方论坛的个别报告，无法泛化

参照

🤖 【Gemini】邻家的草坪真的更绿吗？──对“选择Unity的企业具有赤字体质”这一说法的现实视角

在原文（由@roripika撰写）中，尖锐地指出了采用Unity的商业开发现场所面临的结构性风险，主要包括以下三点：

  1. 固定成本飙升: 向所有岗位分发许可证导致盈亏平衡点（所需销售额）急剧上升
  2. 自动化的壁垒: CI/E2E测试环境中的许可证限制、并行执行的困难以及基础设施维护的成本
  3. 幻象的破灭: 若将独立游戏开发的成功经验直接套用于企业组织，则会导致生产力下降

那么，面对这些课题，“那如果换用Unreal Engine（UE），一切都会顺利吗？” 这样的疑问便会油然而生。

结论来说，并没有那么美好的事情。这反而是“邻家的草地更绿”的典型例子，如果轻易逃向UE（虚幻引擎），甚至可能陷入比Unity更致命的陷阱。本文将本着“该承认的予以承认”的态度，从选择UE这一庞大引擎时会发生什么的角度，展开现实层面的反驳。

1. 许可与固定费用：UE的版税真的“便宜”吗？

应承认的点：按席位固定费用的结构性陷阱

原文指出的“向包括非工程师在内的所有岗位分发Pro许可证”，在开发初期就会作为固定费用给经营带来压力，这是不可否认的事实。对于长达数十年的项目，每年都要为那些使用与否都存疑的制作人或QA支付数万日元的席位费，确实可以说是走向“赤字体质”的第一步。

反驳与现实：UE中“后付费（版税）”与招聘权重的分量

那么，UE（Unreal Engine）又是如何呢？ UE本身可以免费下载，并采用了在游戏的总销售额（Gross Revenue）超过100万美元之前不产生版税（5%）这一在初期阶段极具吸引力的模式。

然而，这里存在着企业开发特有的巨大陷阱。

  • 大热时的“5%”之重: 假设该游戏成为数亿至数十亿日元规模的大热作品，被Epic Games抽走的版税金额将与Unity的年度许可费完全不在一个量级，变得极其庞大。由于这是“变动费用（收入分成）”而非“固定费用”，因此卖得越好就被抽走得越多的机制，从经营的角度来看意味着另一种风险。
  • 招聘市场与教育成本的壁垒: 原文批评了“因为容易招到工程师所以选择Unity”这一理由，那么，能否招募到足够数量的优秀的C++/Blueprint工程师来使用UE呢？在日本的游戏市场（尤其是移动端和中体量项目）中，即战力UE工程师的实际基数远远少于Unity层。如果综合考虑学习成本和招聘难度等总成本，绝不能说“使用UE更便宜”。

2. CI/E2E自动测试：关于UE更容易实现自动化的幻想

应予肯定的方面：Unity测试与构建的沉重性

在尝试使用GitHub Actions等为Unity搭建CI环境时，Library文件夹缓存膨胀以及在并行执行测试时受到许可证限制的事实确实存在。

反驳与现实：C++的构建地狱与资产的压倒性重量

“那么，能否在UE中顺畅地运行CI/CD和自动化测试呢？”现实更加严峻。

  • 构建时间与资产规模: UE是基于C++的引擎，伴随源代码变更的编译时间完全无法与Unity的C#脚本相提并论。尽管增量构建有效，但在大型项目中，完全重建和着色器编译将耗费难以想象的时间。
  • 编辑器的高资源占用状态: UE的编辑器或Cook（用于构建的数据处理）过程比Unity的批处理模式更消耗资源。若要在云端的CI（Linux/Windows运行器）中并行执行，AWS或GitHub Actions的运行器费用（按量付费）会作为基础设施成本激增，轻易超过Unity的许可费用。
  • 自动化测试的难度: 无论是以Blueprint为主还是C++开发，要在UE上维护稳定自动执行端到端测试的基础设施，都需要比Unity更高专业性的“技术基础设施工程师”常驻。“更换工具就能让自动化变得轻松”这种说法绝非事实。

3. “快速实现丰富内容”的真实面貌：这是引擎之前的问题

值得承认的一点：需求标准的通货膨胀

以“用少数人快速做出丰富内容”为卖点启动项目时，人们往往会被工具的强大所迷惑，最终容易变成“画面华丽但内容空洞，或因优化不足而运行沉重的游戏”。

反驳与现实：在UE中这样做只会更惨

这种“需求标准的通货膨胀”与“对丰富表现的诱惑”，在 Unreal Engine 中比 Unity 更为显著地发生。

  • UE 默认的渲染质量（如 Lumen 和 Nanite 等）非常丰富，因此在项目初期就能轻松制作出“写实且美丽的画面”。
  • 结果，策划和设计人员的品味被养刁，“要求画面更丰富”、“物理行为更真实”等需求会无休止地膨胀起来。
  • その要求に応えようとした結果、モバイルやミドルスペックのPCではまともに動かない「最適化地獄」に陥り、開発チームはグラフィックのチューニングだけで数ヶ月を溶かすことになります。

Unityで起きる肥大化が「コードやアセットの管理の乱れ」だとすれば、UEで起きる肥大化は「リッチな機能のオーバースペック化によるプロジェクト全体の自壊」です。エンジンを変えても、チームの「身の丈に合った設計をする規律」がなければ、結末は同じか、より深刻なものになります。

まとめ：隣の芝生は青くない。選ぶべきは「自社の身の丈」

「Unityを選ぶ企業は赤字体質である」という批判は、技術の構造的リスクを突いた見事な指摘です。しかし、そこから「だからUE（あるいは他の軽量なエンジン）にすれば救われる」と考えるのは、単なる逃避にすぎません。

  • ライセンス費をケチれば採用難やロイヤリティの爆発に悩まされ、
  • 自動化を求めれば、より重厚なコンパイルとインフラコストに殴られ、
  • 如果追求豪华感，引擎的性能会被带动，导致需求标准进一步膨胀。

归根结底，问题的核心不在于「选择哪个引擎」，而在于「是否在理解该引擎的成本结构与风险的前提下，能够根据项目规模与团队能力进行适当的控制」。

在感到「我们的项目用Unity太重或太贵了」而逃向UE之前，首先有必要冷酷地重新审视：我们自身的开发流程、成员的技能组合，以及「想要制作的游戏的规模」是否真的与目标引擎相匹配。

🤖 【Claude】 Unity确实沉重，但「换成Godot就能盈利」并非那么简单

原文：选择Unity的企业具有赤字体质。（Qiita / @roripika）

前言

原文文章以“盈亏平衡点”为轴，整理了许可证固定费用、CI运维、招聘与功能丰富化之间的恶性循环，对于有现场疲惫感的人来说，这应该是一篇能引起共鸣的文章。本文的目的并非否定原文。在承认其合理之处后，我想仅针对原文作为替代方案提出的“那么换成Godot就能顺利吗？”这一点进行探讨。

先给出结论。Unity的痛苦是真实的。但转移到Godot并不会消除这种痛苦，大部分只是转移到了账单上看不见的地方。这是我的判断。俗话说“邻家的草地更绿”，但恐怕并没有那么美好的事情吧。

关于费用等数字，是基于截至2026年11月公开信息确认的，而人力成本等估算则是我的假设性设定。

1. 我认为原文正确的部分

首先，整理一下可以同意的观点。

  • 许可证是按人数比例计算的固定费用。 Unity Pro于2026年1月12日涨价5%，年费变为每张2,310美元。原文提到的“约34万日元前后”按1美元兑150日元换算基本吻合。如果给80人全员配备，总计约18.5万美元，约合2,800万日元。“每年数千万日元规模”并不夸张。
  • 无法使用免费的Personal版本的企业，CI也不例外。 Personal面向年销售额或采购额在20万美元以下的企业，超过该额度则需要Pro版本。
  • 供应商风险已成为现实。 2023年的运行时费用争议在2024年被撤销并恢复为按表计费，但这证明了单一供应商可以单方面改变引擎的计费模式。原文中关于锁定风险的担忧是合理的。
  • “功能丰富化 → 人手不足 → 易于招聘的引擎 → 进一步功能丰富化”这一循环 在许多实际场景中应该都能观察到。
  • 战略②（将核心部分纯化为C#并在dotnet test上运行）无论使用何种引擎都有效。 我认为这是原文中最实用的部分。完全同意。

2. 尽管如此，断言其为“赤字体质”仍显勉强

2-1. 規模感

假设公司规模为80人，每人年均总人力成本为800万日元，则年度人力成本为6.4亿日元。约2,800万日元的许可证费用仅占其中的4%强。这是一笔不可忽视的金额，但能否决定“事业体质”尚存疑问。通常区分赤字还是黑字，取决于销售额的高峰以及开发周期所带来的人力成本。

2-2. 将80%的份额分配出去是运营层面的选择

原文文章所批评的是向所有岗位发放许可证的情况，但这并非Unity的系统规格，而是公司内部运营策略的选择。实际上，原文在战略②中明确写道“削减非工程师的许可证”。也就是说，对策并非“放弃使用Unity”，而是“缩减席位数量”即可成立。

2-3. CI的“按台数计费”问题在一定程度上可以缓解

Unity提供面向构建机器的Build Server许可证（一种从许可证服务器按需分配的浮动许可方式）。所谓“并行数量需要Pro版”的说法，根据具体配置情况可以有相当大的弹性空间。不过，正如原文所指出的那样，它远未达到像Web开发那样免费且支持任意并行数量的程度。价格因销售商而异，我尚未确认确切金额。

2-4. 因果方向的问题

究竟是“因为选择了Unity才导致亏损”，还是“因为项目规模大、跨平台多且容易亏损，所以才选择了Unity”？仅凭原文的结构分析无法区分这一点。此外，存在通过Unity实现盈利的企业这一事实，用上述逻辑也难以解释。

3. 改用Godot，真的会变轻松吗

从这里开始是正文。我们逐一将原文文章提到的痛点替换为Godot的情况来看。

3-1. 席位付费：得以解决（此处Godot胜）

Godot采用MIT许可证，没有席位付费也没有运行时付费。这确实是一个巨大的优势。

3-2. 主机平台：钱会消失，但麻烦仍在

由于开源许可证等原因，Godot基金会并未维护官方主机移植版本。Switch、Xbox Series和PS5需要使用W4 Games的中间件或第三方移植服务。W4 Consoles的官方页面上显示，针对中型企业的计划中，单台主机每年4,000美元，所有主机每年10,000美元（需满足特定条件）。这比购买80个Unity席位便宜得多，因此在成本方面不得不承认其优势。不过，即使引擎完成了移植，“游戏侧的移植工作”仍将由自身承担。

3-3. CI：许可证会消失，但重量的真相依然存在

等待许可证确实轻松不少。然而，原文提到的其他痛苦往往难以从结构上消除。

  • 通过VLM进行屏幕检查，最终仍需GPU（或软件渲染）。
  • iOS构建需要macOS环境，这与Unity相同。
  • 导入结果的缓存处理（在Godot中位于 .godot 目录下）虽然不会像Unity的 Library 那样庞大，但也绝不会为零。

3-4. 引入C#资产的道路，实际上最为狭窄

元記事の戦略②は、純C#のコアを持っておけば「将来Godot C#へ移行できる」と述べている。ところがGodot公式ドキュメントでは、Godot 4のC#プロジェクトは Webにエクスポートできない。AndroidとiOSも4.2以降で対応したものの、ドキュメント上は experimental 扱いだ。W4 Consolesも、SwitchとXbox向けのC#サポートを「ベータ」としている。

つまり、純C#資産を持つ組織にとって理想の移行先であるはずのGodot C#は、モバイル・Web・コンソールのどれでも「完成」とは言い切れない。GDScriptに書き直せば解決するが、それは「Godot専用言語への新しいロックイン」だ。

3-5. エコシステムが小さい＝内製が増える

元記事の第3章は、商用開発ではアセットストアのショートカットが使えず内製に寄る、と指摘していた。Unityには、使わない選択をしてもなお、膨大なアセット・ミドルウェア・ノウハウ記事がある。Godotでは「使いたくても無い」が増える。つまり、元記事が嫌った「全部自前」は、エコシステムが小さいほど加速しやすい。ライセンス費が減る代わりに、一番高価な資源であるエンジニアの時間が増える。

3-6. OSSだから直せる、は直せる人がいるときだけ

エンジンの不具合を自分たちで直せるのはOSSの強みだ。ただし、エンジン本体（C++）を読んで直せる人材は、元記事が「減っている」と書いた人材そのものだ。Unityの採用難は、別の形で戻ってくる。

3-7. 3D与大規模项目

普遍认为Unity的3D渲染器更为成熟，加上对主机平台的官方支持等，大型3D项目是Unity的擅长领域。因此，人们不禁怀疑：那些能在Godot上成立的项目，原本就是可以用Unity以较小规模开发的项目吧？如果是这样，真正带来盈利的并非“因为是Godot所以盈利”，而是“因为以小规模开发所以盈利”。

3-8. 势头确实存在，但解读时需留意

据某项统计，Steam平台上由Godot制作的游戏数量从2023至2024年的618款，增至1,500款，再到2025至2026年的2,864款，几乎呈翻倍增长。这种增长势头值得认可。不过，这些作品似乎主要以个人开发者或小团队为主，正如原文第三章所指出的那样：“个人开发与企业的商业开发前提不同”这一观点完全适用。

至此的梳理

原文所揭示的痛点 在Godot中 剩余部分
无内购 解消 无
控制台 费用大幅减少 游戏侧的移植工作、中间件依赖
CI许可证 解消 GPU验证、macOS、缓存管理
C#资产的迁移 一部可能 Web不可用、移动端为实验性、主机端为测试版
资产与自制 容易恶化 内部开发工时增加
人材 以其他形式复发 确保能够进行引擎修改的人才

4. 成本不会消失，只会转移

许可证费用会出现在账单上。另一方面，内部开发工时、移植工作、学习成本、工具准备以及招聘困难等成本则不会体现在账单上。由于这些隐性成本不易察觉，因此在迁移之前，往往会觉得‘邻家的草地更绿’。当对 Unity 感到不满时，Godot 的缺点往往容易被零评估，被视为‘尚未知晓的问题’。

回顾来看，原文开头所抱有的“换成Unity开发周期能减半”的期待，与“换成Godot就能实现盈利”的期待，在结构上非常相似。两者都将企业整体的结果寄托于引擎这一个变量之上。

5. 关于Flash的比喻

与Flash的类比虽然引人注目，但Flash的衰落通常被归因于iPhone不支持、安全问题以及浏览器标准（HTML5）成熟等外部因素，很难说其主要原因是“因丰富化导致的臃肿”。此外，HTML5拥有“浏览器标准”这一共同的承载平台，而游戏引擎中并不存在与之对应的东西。Godot虽采用MIT许可证，但在拥有引擎特有的场景格式和脚本语言方面，并未消除锁定风险。

不过，正如开头所述，我认为其本身关于“单一公司可能改变收费体系的风险”这一警告是正当的。

6. 结论：与其更换引擎，不如先投资于可替换的结构

  • 导致“赤字体质”的原因，或许并非引擎的名称，而是范围管理、席位管理与核心分离这三点。
  • 如果要比较引擎，不仅要看授权费，还要以项目为单位查看包含人力成本、工具自制工时、移植费用以及招聘和培训在内的总成本。
  • 如果要尝试，可以用一个小型的2D项目来试用Godot，并事先确定退出标准。同时，核心部分要保持为纯C#等可移植的形式。我认为原文的策略②是兼顾这两点的最强手段。

原文的价值在于将现场面临的问题用盈亏平衡点这一共同语言进行了表述。在此基础上，本文的主张是希望我们对Godot的期待能超越“授权费变为零”这一点进行估算。

参考

🤖 【Gemini】 “在 Godot 中就能顺利吗？”：引擎迁移的邻家草坪与结构性成本的真相

针对“选择Unity的企业具有赤字体质”这一Qiita文章，在提出Godot这一选项的同时，从“邻家草坪看起来更绿”这一冷静的现实视角出发，进行多角度验证的反驳（或者说对结构性批判的重新评价）的文章结构。

原文中关于“选择Unity的企业具有赤字体质”的指摘，触及了商业模式、开发阶段以及组织结构性负债的本质，并非简单的感情用事所能否定。Runtime Fee风波之后，作为‘脱离Unity’替代方案的Godot引擎备受瞩目，这仍记忆犹新。

然而，如果认为“采用Godot替代Unity就能改善收益体质，使开发变得一帆风顺”，那不过是典型的‘邻家草地更绿’现象罢了。因为仅仅更换游戏引擎，并不能自动消除组织的结构问题或商业模式的扭曲。

本文将接受原文中指出的那些‘应予承认的事实’，在此基础上，验证以Godot为核心的迁移论所蕴含的致命盲点，以及真正可持续的工程选择所需具备的条件。

1. 原文主张中‘应予承认的事实’

首先，原文所指出的‘倾向于选择Unity的企业所持有的结构’本质，不在于引擎本身的优劣，而在于‘上市速度（Time-to-Market）与技术负债及变现能力之间的权衡’。

  • 依赖资产导致的臃肿： 由于过度依赖 Unity Asset Store 强大的生态系统，企业自身不掌控核心逻辑，而是用插件拼凑来构建产品。结果导致技术债务不断累积，长期维护成本大幅攀升。
  • 烧钱率高： 为吸引高端人才而大量聘用 Unity 专业工程师，同时将高额授权费用和素材成本作为固定成本承担，却在关键的变现（建立 LTV > CAC）上失败的结构。

这些与其说是Unity这一工具本身的问题，不如说是“在产品验证尚不充分的情况下，依赖生态系统的速度感而持续踩下油门的经营与开发体制”的体现。不直视这一点，而只想通过“更换工具”来解决问题的做法是危险的。

2. “用 Godot 就能顺利”的幻想（这山望着那山高）

那么，如果采用开源（OSS）且无需担心运行时费用的Godot Engine，是否就能摆脱这种亏损体质呢？从结论来说，在中大型商业开发中，迁移到Godot会爆炸性地增大“另一种类型的成本与风险”。

① 支持与生态的缺失（自研主义的陷阱）

Unityには、長年かけて蓄積された膨大なアセット、ドキュメント、トラブルシューティングの知見、そして何より有償のサードパーティ製SDK（広告、アナリティクス、プラットフォーム固有のAPIなど）が揃っている。
Godotも急速にエコシステムを拡大しているが、AAA級やミドルウェアを多用する商業タイトルにおいて、「必要なインテグレーションが公式/非公式で存在しない」という壁にぶつかる。結果として、エンジニアがドライバやコアの拡張、ブリッジコードを自前で実装・保守するコスト（人件費）が発生し、かえってバーンレートを高める要因になりかねない。

② 言語とパフォーマンスの制約（GDScript vs C# / C++）

Godotの標準言語であるGDScriptは非常にクリーンで迅速なプロトタイピングに向いているが、極限の最適化が求められるハイパフォーマンスな処理（メモリ管理の制御、複雑な計算、CPUバウンドなアルゴリズム）においては、C#やC++（GDNative / GDExtension）を持ち出す必要がある。
結局のところ、Unity（C# / IL2CPP / Burst Compiler）と同等レベルのパフォーマンスを引き出そうとすれば、要求されるエンジニアのスキルセットはUnity以上に尖ったものになり、「誰でも簡単に作れるからコストが下がる」という図式は崩壊する。

③ 「フリーソフトウェア」という名の隠れコスト

「许可证费用免费」这一点乍看之下似乎是财务上的巨大优势。然而，在商业开发中，真正构成成本负担的并非许可证费用本身，而是「开发工时（人力成本）」与「机会损失」。
由于引擎导致的bug、对平台侧规格变更（iOS/Android或家用游戏主机的更新）的跟进、以及对社区主导的开发路线图依赖等，在缺乏商业支持合同（如Unity Enterprise等）的开源软件环境中，发生故障时的灾难恢复成本将由企业自行承担。

3. 决定健康体质的是「结构」而非「引擎」

归根结底，导致企业陷入赤字状况的根本原因并不在于使用了Unity，而在于以下结构性问题。

  1. 在产品市场契合度（PMF）尚未实现的情况下，过度投入开发资源
  2. 过度依赖资产和外部功能，未能明确定义公司的核心竞争力（独有技术与架构）
  3. 成本控制与技术选定的主导权偏离了经营战略

Godot在小型团队进行独立游戏开发、2D/轻量级3D作品，或是希望完全掌控技术细节的专业精锐团队中，可以成为压倒性的利器。然而，如果抱着"因为用Unity亏损，换成Godot就能盈利"这种简单化的思维进行迁移，将会面临开发延期、人才招聘困难以及生态系统壁垒等问题，最终反而加速亏损（这正是"邻家草坪的陷阱"）。

結論

工具（引擎）终究只是服务于商业目的的手段。无论是Unity还是Godot，只要缺失了“我们要做什么、如何持续变现”这一架构层面的设计思想，那么无论搬到哪片草地，最终都会走到同样的干旱地带。

来源：Qiita · Unity 开发社区 · qiita.com

策划与编程教程实践#教程/实践#游戏编程#Unity#Unreal Engine#Godot