OnLive 的云游戏超前 (OnLive)：一个技术方向被后来证明是对的，为什么它作为先行者反而先倒闭了？
技术方向正确不等于时机正确，先行者往往要先替所有人付学费
OnLive 的云游戏超前 (OnLive)：巅峰期以云端串流方式提供游戏的服务平台，用户无需高性能硬件即可游玩大型游戏，曾被寄予改变游戏分发方式的期望；终局是技术体验受网络延迟与带宽限制，用户规模与内容授权成本难以平衡，公司资产被收购后服务终止，云游戏的第一个大规模尝试落幕。
以云端串流方式提供游戏的服务平台，用户无需高性能硬件即可游玩大型游戏，曾被寄予改变游戏分发方式的期望
技术体验受网络延迟与带宽限制，用户规模与内容授权成本难以平衡，公司资产被收购后服务终止，云游戏的第一个大规模尝试落幕
5,335 votes cast
1 plans · 1 insights
投稿会先进入待审，通过后才进入公开目录和站点地图。
Root Causes Consensus Poll
Vote for the primary fatal error that caused this enterprise to collapse.
用户体验受外部网络条件限制
延迟与带宽不可控，核心体验无法保证
自建基础设施资本支出巨大
数据中心投入先于用户规模，单位成本居高不下
内容授权成本高
游戏版权方议价能力强，内容成本难以随规模摊薄
时机早于网络条件成熟
宽带普及与边缘节点尚未就绪，市场教育成本由自己承担
Timeline: peak to collapse
技术发布与关注
公司在展会上展示云端串流游戏，获得媒体与行业高度关注
上线与体验瓶颈
服务正式上线后，用户在实际网络条件下的延迟与画质体验不及预期
重组与裁员
公司在亏损压力下重组资产与团队，尝试调整商业模式但用户增长仍有限
资产出售与服务终止
公司资产被收购，原有服务停止，云游戏的大规模商业化要等到数年后才由其他公司继续尝试
Four-Dimensional Retrospective Breakdown
Background & Golden Era
云游戏解决了本地硬件成本的痛点：把运算放在服务器、把画面串流给用户；公司自建数据中心并投入大量资本，希望以订阅与内容分发作服务模式，技术演示在当时相当惊艳巅峰期的成绩单是：以云端串流方式提供游戏的服务平台，用户无需高性能硬件即可游玩大型游戏，曾被寄予改变游戏分发方式的期望。此时的它拥有渠道、品牌与资本的合力，看起来没有任何理由会输。
Fatal Turning Point Miscalculation
实际使用体验受用户网络延迟与带宽影响，尤其在对延迟敏感的游戏类型中难以接受；同时自建数据中心的资本支出与游戏内容授权成本高昂，用户规模不足以摊薄单用户成本，公司长期亏损并多次重组早期为了速度堆起来的技术债没有及时偿还，等到业务规模翻倍，系统已经无法支撑新场景，重构又意味着停掉增长，只能一路将就。
Internal Culture & Bureaucratic Hubris
工程团队疲于救火与打补丁，优秀工程师流失，剩下的人只能用更低效的方式维持系统运转，形成恶性循环。
The Collapse & Aftermath
技术体验受网络延迟与带宽限制，用户规模与内容授权成本难以平衡，公司资产被收购后服务终止，云游戏的第一个大规模尝试落幕。OnLive 的云游戏超前 (OnLive)的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
Battle-Tested Actionable Survival Rules
Distilled practical DOs and DONTs forged from costly corporate catastrophes.
依赖外部条件的技术，要先确认那些条件什么时候才会就绪
把「用户环境是否满足」当作产品能否成立的第一道门槛。
- •在规模化前验证真实网络条件下的体验
- •用合作方式减少自建基础设施的资本支出
- •不要用最优环境下的演示代表真实体验
- •不要假设内容成本会随规模下降
Revival Simulation: If you were the CEO at the inflection point, how would you save it?
History cannot be rewritten, but executive decision-making can be honed. Propose decisive divestitures and strategic bets, and let entrepreneurs & VCs vote on feasibility.
先把体验门槛与单位成本验证清楚，再谈规模
Critical intervention point：2012 年前后用户实际体验不及预期、亏损持续扩大时
- •停止在用户环境未达标时扩大推广
- •停止以自建方式承担全部基础设施成本
- •停止用演示效果代表真实体验
- •与运营商合作以降低网络与基础设施风险
- •聚焦延迟不敏感的游戏类型先建立用户
- •用合作分成替代高额内容预付
技术条件受限于外部环境，收缩到可保证体验的场景是唯一选择。
在可保证体验的场景中形成稳定用户，商业模式具备可持续基础。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
云游戏的逻辑很清楚：把昂贵的运算放在云端，用户只负责显示与操作，硬件门槛随之消失。演示在受控网络下效果惊艳。但真实用户的网络条件并不统一——延迟、丢包与带宽差异直接决定体验，而在需要快速反应的游戏里，几十毫秒的差别就足以让人放弃。同时，自建数据中心意味着巨额资本支出一开始就要发生，而游戏内容的授权成本又牢牢握在版权方手里。用户规模不足以摊薄这两项成本时，技术再先进也只能停运。
先行者的成本，是把「什么时候才轮到这个技术」这件事也一并付掉。
Business Post-Mortem Memo · OnLive 的云游戏超前 (OnLive)
一个技术方向被后来证明是对的，为什么它作为先行者反而先倒闭了？
# Business Post-Mortem Memo：OnLive 的云游戏超前 (OnLive) > 一个技术方向被后来证明是对的，为什么它作为先行者反而先倒闭了？ > Period: 2009 - 2015 | Industry: Tools & Internet > Peak: 以云端串流方式提供游戏的服务平台，用户无需高性能硬件即可游玩大型游戏，曾被寄予改变游戏分发方式的期望 > Final: 技术体验受网络延迟与带宽限制，用户规模与内容授权成本难以平衡，公司资产被收购后服务终止，云游戏的第一个大规模尝试落幕 ## Overview 技术方向正确不等于时机正确，先行者往往要先替所有人付学费。巅峰期以云端串流方式提供游戏的服务平台，用户无需高性能硬件即可游玩大型游戏，曾被寄予改变游戏分发方式的期望；终局是技术体验受网络延迟与带宽限制，用户规模与内容授权成本难以平衡，公司资产被收购后服务终止，云游戏的第一个大规模尝试落幕。 ## Top-voted root causes 1. [Product & Tech] 用户体验受外部网络条件限制 (1,755 votes) 2. [Capital & Finance] 自建基础设施资本支出巨大 (1,474 votes) 3. [Strategy] 内容授权成本高 (1,193 votes) ## Actionable lessons ### 依赖外部条件的技术，要先确认那些条件什么时候才会就绪 > 把「用户环境是否满足」当作产品能否成立的第一道门槛。 - ✅ DOs: - 在规模化前验证真实网络条件下的体验 - 用合作方式减少自建基础设施的资本支出 - ❌ DON'Ts: - 不要用最优环境下的演示代表真实体验 - 不要假设内容成本会随规模下降 ## Revival plans ### 先把体验门槛与单位成本验证清楚，再谈规模 — 良略编辑部 Intervention: 2012 年前后用户实际体验不及预期、亏损持续扩大时 - Must cut: - 停止在用户环境未达标时扩大推广 - 停止以自建方式承担全部基础设施成本 - 停止用演示效果代表真实体验 - Breakthrough moves: - 与运营商合作以降低网络与基础设施风险 - 聚焦延迟不敏感的游戏类型先建立用户 - 用合作分成替代高额内容预付 - Expected outcome: 在可保证体验的场景中形成稳定用户，商业模式具备可持续基础。 ## Community insights ### 这个方向最终被证明是对的，但它的成立需要一整套外部条件同时到位。 — 良略编辑部 (工程师) 云游戏的逻辑很清楚：把昂贵的运算放在云端，用户只负责显示与操作，硬件门槛随之消失。演示在受控网络下效果惊艳。但真实用户的网络条件并不统一——延迟、丢包与带宽差异直接决定体验，而在需要快速反应的游戏里，几十毫秒的差别就足以让人放弃。同时，自建数据中心意味着巨额资本支出一开始就要发生，而游戏内容的授权成本又牢牢握在版权方手里。用户规模不足以摊薄这两项成本时，技术再先进也只能停运。 - Alternative Move if Replayed 先行者的成本，是把「什么时候才轮到这个技术」这件事也一并付掉。 --- Source: 良略 · https://www.lianglue.com/c/onlive