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