OnLive 的云游戏超前 (OnLive):一个技术方向被后来证明是对的,为什么它作为先行者反而先倒闭了?
技术方向正确不等于时机正确,先行者往往要先替所有人付学费
OnLive 的云游戏超前 (OnLive):巅峰期以云端串流方式提供游戏的服务平台,用户无需高性能硬件即可游玩大型游戏,曾被寄予改变游戏分发方式的期望;终局是技术体验受网络延迟与带宽限制,用户规模与内容授权成本难以平衡,公司资产被收购后服务终止,云游戏的第一个大规模尝试落幕。
以云端串流方式提供游戏的服务平台,用户无需高性能硬件即可游玩大型游戏,曾被寄予改变游戏分发方式的期望
技术体验受网络延迟与带宽限制,用户规模与内容授权成本难以平衡,公司资产被收购后服务终止,云游戏的第一个大规模尝试落幕
5,335 票参与
1 方案 · 1 见解
投稿会先进入待审,通过后才进入公开目录和站点地图。
核心败因全民归因公投
投票选择您认为导致该企业/项目最终死亡的最核心死穴,认同即可实时投票计入权重
用户体验受外部网络条件限制
延迟与带宽不可控,核心体验无法保证
自建基础设施资本支出巨大
数据中心投入先于用户规模,单位成本居高不下
内容授权成本高
游戏版权方议价能力强,内容成本难以随规模摊薄
时机早于网络条件成熟
宽带普及与边缘节点尚未就绪,市场教育成本由自己承担
时间线:从高峰到终局
技术发布与关注
公司在展会上展示云端串流游戏,获得媒体与行业高度关注
上线与体验瓶颈
服务正式上线后,用户在实际网络条件下的延迟与画质体验不及预期
重组与裁员
公司在亏损压力下重组资产与团队,尝试调整商业模式但用户增长仍有限
资产出售与服务终止
公司资产被收购,原有服务停止,云游戏的大规模商业化要等到数年后才由其他公司继续尝试
四大维度全景复盘剖析
发展背景与全盛期基石
云游戏解决了本地硬件成本的痛点:把运算放在服务器、把画面串流给用户;公司自建数据中心并投入大量资本,希望以订阅与内容分发作服务模式,技术演示在当时相当惊艳巅峰期的成绩单是:以云端串流方式提供游戏的服务平台,用户无需高性能硬件即可游玩大型游戏,曾被寄予改变游戏分发方式的期望。此时的它拥有渠道、品牌与资本的合力,看起来没有任何理由会输。
致命转折点的战略误判
实际使用体验受用户网络延迟与带宽影响,尤其在对延迟敏感的游戏类型中难以接受;同时自建数据中心的资本支出与游戏内容授权成本高昂,用户规模不足以摊薄单用户成本,公司长期亏损并多次重组早期为了速度堆起来的技术债没有及时偿还,等到业务规模翻倍,系统已经无法支撑新场景,重构又意味着停掉增长,只能一路将就。
内部组织文化与盲目傲慢
工程团队疲于救火与打补丁,优秀工程师流失,剩下的人只能用更低效的方式维持系统运转,形成恶性循环。
轰然倒塌的崩盘推演
技术体验受网络延迟与带宽限制,用户规模与内容授权成本难以平衡,公司资产被收购后服务终止,云游戏的第一个大规模尝试落幕。OnLive 的云游戏超前 (OnLive)的结局不是某一次意外,而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
商业落地避坑实操法则
以血淋淋的商业代价淬炼出的创业与经营行动准则(DOs & DONTs)
依赖外部条件的技术,要先确认那些条件什么时候才会就绪
把「用户环境是否满足」当作产品能否成立的第一道门槛。
- •在规模化前验证真实网络条件下的体验
- •用合作方式减少自建基础设施的资本支出
- •不要用最优环境下的演示代表真实体验
- •不要假设内容成本会随规模下降
绝地求生模拟器:如果你是当时的CEO,在关键转折点该如何挽狂澜于既倒?
历史不可更改,但思维可以淬炼。针对核心转折点,提出手术刀式改革方案与资源调配破局法,交由全网创业者与投资人可行度公投。
先把体验门槛与单位成本验证清楚,再谈规模
关键干预时点:2012 年前后用户实际体验不及预期、亏损持续扩大时
- •停止在用户环境未达标时扩大推广
- •停止以自建方式承担全部基础设施成本
- •停止用演示效果代表真实体验
- •与运营商合作以降低网络与基础设施风险
- •聚焦延迟不敏感的游戏类型先建立用户
- •用合作分成替代高额内容预付
技术条件受限于外部环境,收缩到可保证体验的场景是唯一选择。
在可保证体验的场景中形成稳定用户,商业模式具备可持续基础。
行家深度复盘见解
来自创业者、投资人、前员工和行业专家的真实第一手复盘反思
云游戏的逻辑很清楚:把昂贵的运算放在云端,用户只负责显示与操作,硬件门槛随之消失。演示在受控网络下效果惊艳。但真实用户的网络条件并不统一——延迟、丢包与带宽差异直接决定体验,而在需要快速反应的游戏里,几十毫秒的差别就足以让人放弃。同时,自建数据中心意味着巨额资本支出一开始就要发生,而游戏内容的授权成本又牢牢握在版权方手里。用户规模不足以摊薄这两项成本时,技术再先进也只能停运。
先行者的成本,是把「什么时候才轮到这个技术」这件事也一并付掉。
商业复盘与避坑备忘录 · OnLive 的云游戏超前 (OnLive)
一个技术方向被后来证明是对的,为什么它作为先行者反而先倒闭了?
# 商业复盘备忘录:OnLive 的云游戏超前 (OnLive) > 一个技术方向被后来证明是对的,为什么它作为先行者反而先倒闭了? > 周期: 2009 - 2015 | 行业: 工具与互联网 > 巅峰: 以云端串流方式提供游戏的服务平台,用户无需高性能硬件即可游玩大型游戏,曾被寄予改变游戏分发方式的期望 > 终局: 技术体验受网络延迟与带宽限制,用户规模与内容授权成本难以平衡,公司资产被收购后服务终止,云游戏的第一个大规模尝试落幕 ## 核心概览 技术方向正确不等于时机正确,先行者往往要先替所有人付学费。巅峰期以云端串流方式提供游戏的服务平台,用户无需高性能硬件即可游玩大型游戏,曾被寄予改变游戏分发方式的期望;终局是技术体验受网络延迟与带宽限制,用户规模与内容授权成本难以平衡,公司资产被收购后服务终止,云游戏的第一个大规模尝试落幕。 ## 社区公投头号死因 1. [产品技术] 用户体验受外部网络条件限制 (1,755 票) 2. [资本财务] 自建基础设施资本支出巨大 (1,474 票) 3. [战略决策] 内容授权成本高 (1,193 票) ## 可执行教训 ### 依赖外部条件的技术,要先确认那些条件什么时候才会就绪 > 把「用户环境是否满足」当作产品能否成立的第一道门槛。 - ✅ 推荐做 (DOs): - 在规模化前验证真实网络条件下的体验 - 用合作方式减少自建基础设施的资本支出 - ❌ 绝不能做 (DON'Ts): - 不要用最优环境下的演示代表真实体验 - 不要假设内容成本会随规模下降 ## 救亡方案 ### 先把体验门槛与单位成本验证清楚,再谈规模 — 良略编辑部 干预时点: 2012 年前后用户实际体验不及预期、亏损持续扩大时 - 必须断腕: - 停止在用户环境未达标时扩大推广 - 停止以自建方式承担全部基础设施成本 - 停止用演示效果代表真实体验 - 破局动作: - 与运营商合作以降低网络与基础设施风险 - 聚焦延迟不敏感的游戏类型先建立用户 - 用合作分成替代高额内容预付 - 预期结果: 在可保证体验的场景中形成稳定用户,商业模式具备可持续基础。 ## 社区见解 ### 这个方向最终被证明是对的,但它的成立需要一整套外部条件同时到位。 — 良略编辑部 (工程师) 云游戏的逻辑很清楚:把昂贵的运算放在云端,用户只负责显示与操作,硬件门槛随之消失。演示在受控网络下效果惊艳。但真实用户的网络条件并不统一——延迟、丢包与带宽差异直接决定体验,而在需要快速反应的游戏里,几十毫秒的差别就足以让人放弃。同时,自建数据中心意味着巨额资本支出一开始就要发生,而游戏内容的授权成本又牢牢握在版权方手里。用户规模不足以摊薄这两项成本时,技术再先进也只能停运。 - 如果重来一次的纠偏招式 先行者的成本,是把「什么时候才轮到这个技术」这件事也一并付掉。 --- 来源: 良略 · https://www.lianglue.com/c/onlive