目录

Google关闭游戏平台Stadia,对开发者心理产生的影响

9月29日,Google突然宣布云游戏平台Stadia将于2023年1月18日关闭,同时Stadia将开启退款通道,凡是购买了Stadia硬件、游戏与DLC的玩家将可以进行退款,谷歌预计在明年1月中旬前将完成大部分退款。

Google云游戏平台Stadia

Google云游戏平台Stadia

Stadia 是 Google 运营的游戏流服务,于2019年11月19日上线。Google 声称服务支持最高4K分辨率、每秒60祯数、高动态范围视频,由世界各地的服务器经高速互联网流至用户设备。Stadia 服务与 YouTube 结合,并支持“状态分享”功能,允许玩家自 YouTuber的存储点自己开始游戏。

Stadia 支持桌面版Google Chrome、移动设备、Chromecast终端设备访问。

Stadia 平台不像其他内容平台提供订阅制,需要玩家购买所玩游戏。

2021年2月1日,Google关闭了Stadia游戏和娱乐公司,转向着重于第三方开发者的发布平台

2022年9月29日,由于反应不如预期,Google副总于官方博客宣布将于2023年1月18日关闭服务,关闭后内部仍会致力将相关技术集成进现有产品中。

Stadia关闭产生的影响

Google突然宣布关闭云游戏平台Stadia,不但员工没有了工作,游戏玩家购买的游戏软件和硬件也没有了用处。虽然谷歌承诺退款,但是游戏玩家花费时间好不容易获得的游戏道具和存档也将不复存在。

Stadia作为一个平台,受影响最大的应该是给它提供游戏的游戏开发团队,他们在平台上花费的时间、人力和金钱都白费了。

有一家美国游戏工作室的负责人就在 Reddit 论坛上面,公开抱怨谷歌。

游戏工作室负责人公开抱怨谷歌

游戏工作室负责人公开抱怨谷歌

这个团队准备把他们的游戏移植到Stadia平台。第一次提交,平台工作人员反馈给他们20多个问题需要解决,两个礼拜后,平台工作人员又反馈10多个新问题。

为了解决这些问题,整个团队大概花费了大约4-5个月时间,花大量时间学习Stadia背后的技术。

终于在9月29日修复了所有的问题,游戏可以很好在Stadia平台上运行。但是,过了一夜,9月30日,Google突然宣布Statia平台要关闭了。

五个月的时间,这个团队本来可以做其他事情,开发其他游戏,或者是向其他平台适配迁移。只是因为他们选择了Stadia,需要学习Stadia系统,为之付出金钱和汗水,最后结果迎来的却是平台关闭。

在之后的留言中,有人给他们建议,可以把自己的游戏名称和内容,以及整个迁移Stadia平台的经过做成视频,借着Stadia平台关闭的新闻效应,好好宣传一下自己。但根据我以往开发的经验,如果团队自身资金有限、人员配置不充足,他们的游戏只能选择适配Stadia平台。如果想要脱离Stadia平台运行,剥离这些专有代码又是不小的工作量。

平台类服务的天然排他性

我没有Google云游戏平台Stadia的开发经验,但是如果那个美国游戏工作室需要花费4,5个月的时间来解决各种问题,就说明Stadia有其自身独特的技术需求。一款游戏如果想要在Stadia平台上正常运行,就需要针对其技术特性完成适配,这些适配代码是面向Stadia平台独有的。

国内10家主流小程序平台

国内10家主流小程序平台

国内各个互联网大厂推出的小程序开发框架也有类似的特征,虽然这些框架有不少是相互借鉴学习的产物,但是每家又或多或少添加了自己的特色,开发者必须要详细阅读开发文档,并在开发中遇到问题时,找每家技术支持人员沟通文档上没有出现的技术细节。

这些小程序平台,或者通过移动终端的市场占有量,或者通过应用的安装量,基本拥有全网大部分流量。个人开发者和中小型开发企业,如果期望用少量的宣传投入,获得最大化的流量关注,就不得不将自己的应用依附在这些小程序平台上。

但是,简单的小程序应用也许可以实现一套代码跨平台通用,一旦应用与平台提供的基础服务有操作交互,那么针对每一家做适配就是不得不完成的事情。如果开发企业的人力、资金和时间都很有限,取舍就是必须要做出的决定。随着业务的开展,收益会严重依赖某一、两个平台,开发团队与这些平台重度捆绑在一起了。

互联网企业创建的云

互联网企业创建的云

除了小程序平台这种庞杂到类似操作系统的开发框架,基础云服务提供商所提供的云服务也越来越具有类似的特性。

2009年在我第一次开始使用亚马逊云服务开发应用时,觉得实在是太方便了。

灵活快速地创建所需的服务器资源,不再需要繁琐的上线部署前资源预估。

根据波峰波谷需求,动态扩展与缩减服务器数量,使得成本控制变得相对容易。

公有云服务的便利性,让我成了使用云计算技术的拥趸者。但是随着之后的工作变化,从企业自用应用开发者转变为第三方企业应用提供商时,不同企业用户会选择不同的公有云服务商,让我对重度使用云服务产生了怀疑。

我们把产品绑定在某个云服务商平台上,努力进行各种技术优化、运维探索的做法,在不同企业用户选择不同云服务商的需求面前,变成了一种制约。

最后只有把公有云服务等价为数据中心服务器,所有服务器之上的基础服务都需要自己搭建和维护,以便我们开发的企业应用能够快速部署在不同的云平台上。

开发者无奈的选择

移动设备厂商对终端应用市场、小程序平台厂商对用户流量的控制,使得开发者团队不得不面对多种不同的开发语言、开发框架。

资金有限的情况下,要全平台支持,就需要配备支持各种技术类型的开发人员。为了节省人力成本,不得不降低技术招聘要求,结果导致应用开发进度拖延、应用完成质量低劣,陷入恶性循环。

如果放弃全平台支持,只绑定部分,一旦这些平台发展出现状况,又可能要面对金钱与人力投入白白浪费的情况。

为了避免这样两难情况的出现,技术开发社区也不断努力研发全平台适配的开发框架,但是这与那些平台厂商的意愿往往又是相背的。


Google云游戏平台Stadia的突然关闭,应该让其他只选择绑定一,两个平台的开发团队心里忐忑。技术团队为了生存只能尽量把仅有的几个鸡蛋,放到不同的篮子里去。