自建 runtime 还是用平台？
每个正经的团队都会在第三个月前后撞上同一个岔路口："我们干嘛交平台抽成,自己跑一套 runtime 不行吗?"问得有理,有时候答案也确实是"行"。但大多数人问这个问题时,漏算了真正拖垮预算的那些部分。咱们把真实的账算一遍。
Q：该自建 runtime 还是用平台？
只有当 runtime 本身就是你的产品、而不是你的分发渠道时,才值得自建。如果你是游戏工作室,runtime 就是你的 overhead——它只是让玩家能打开游戏的那层壳,你每往上面投一小时,就少一小时做游戏。共享平台把这笔固定成本变成你不用操心的可变成本。真正该自建的是那些把 runtime 卖给别人的公司,而不是只想把游戏发出去的人。
Q：自建到底藏着哪些路演稿里不写的成本？
三样东西没人预算过:兼容性税(每次系统更新、每款新设备都会搞坏点什么,得你扛)、支付接入税(每个市场的本地通道都是一个项目,不是一行预算)、冷启动问题(你没有受众,所以建基础设施之外还得自己买量)。平台把这三项都包了。自建等于在你第一个公司里藏了第二个公司。
Q：平台不会把我锁死吗？
锁定是真的,但很少是"他们拿我的用户当人质"那种戏码。真正的锁定是操作层面的:你的分析、你的计费流、你的发布习惯全都顺着它的 API 长。解药不是所有东西都自己建,而是让你的游戏逻辑可移植。一个讲标准、你可控的通用 runtime,意味着你能说搬就搬。建的是可移植性,不是整座技术栈。
Q：什么时候自建才真的划算？
当规模让抽成比自建还贵的时候。如果你每个月移动玩家几百万,平台抽成是你仅次于买量的第一大支出,账就算过来了。或者你要的控制平台给不了——特定的沙箱、特定的数据驻留、特定的支付条款。多数团队到达这个点比想象中晚得多,有些根本到不了。
Q：怎么既保住掌控又不把整座栈都自建？
把 runtime 当标准、别当供应商。对着一个开放的 runtime 规范写游戏,能自己留的用户数据和计费关系就自己留,挑一个"退出只是改个配置、不是重写"的平台。目标不是 independence 表演,而是"不是离不了"。一个能走的团队,才是有底气谈判的团队。
| 维度 | 自建 | 用共享平台 |
|---|---|---|
| 前期成本 | 高(数月工程) | 低(接入即发) |
| 分市场支付 | 每个通道自己接 | 已打包 |
| 受众 | 量全自己买 | 共享的 warm 基础 |
| 兼容性风险 | 自己扛 | 被吸收 |
| 退出成本 | 无(自己拥有) | 看可移植性 |
| 划算时机 | 规模盖过抽成 | 你想把游戏发出去 |
