Steamworks:统计数据Stats可以更好地为Demo服务

作者:Zephyr Guardian
2024-07-02
5 2 0

不起眼的困境

在早期的版本中,少部分游戏曾有过较为夺目的 Stats 社区后台形态:以 V 社自家的《求生之路》《CS:Go》 等游戏为主,但又不仅限于此。然而,这种界面在当今的 Steam 游戏中已不多见。
截图取自我随机选取的某位Payday玩家

据网络资料,带有这类 Stats 后台界面的游戏通常发布于 2012 年之前,并似乎主要是由 Source 引擎制作

通过后台文档,我们能大概感受到 Stats 的主要功能意图大体没变:仍是侧重为玩家记录和呈现,只是更多从“显”转向了“隐”,从外转向了内——当下,只有开发者去主动搭配 Steam API 制作相应的信息显示层,玩家才能够有机会在游戏内通过一系列可能命名为“玩家信息”的 UI 界面获知具体数据。

这或许也是当下 Stats 常常给人一种“无论是在各种游戏还是在日常开发中,都处于边缘地位且容易被无视”的原因所在?即 “看起来需要额外费力,但又似乎没太大必要” 的感觉一直萦绕其上。

Web API

不过,对于 Stats,除了通过游戏内 Steam-API 获取信息的方法之外,Steam 还提供了一种叫做 Web-API 的方式。

它由浏览器地址栏直接输入,获取到的结果大概是这样:

可能是以往对于 Web 知识的储备不足,以及对 Stats 本身曾抱持过视若鸡肋的态度,对我个人来说,在真正使用之前,无论是作为一名玩家,还是作为一名开发者,以往的经历中都甚少见人讨论这种方式;或者即便听到了,也可能会觉得比较抽象,似乎离自己较远。

直到最近,我开始考虑为自己游戏的 Demo 在新品节中加入成就和统计信息......

此方式看起来比较复杂,但本质上无非是将 SteamAPI 改为了通过网页输入—— 虽然看起来要输入的东西很多,但无外乎 App ID 、函数名称、以及一些被不太直观的符号所连接起来的参数而已。

就像上图中用到的这行的前半部分:

https://api.steampowered.com/ISteamUserStats/GetGlobalStatsForGame/v1/?appid=xxxxxxx&count=4&name%5B0%5D=c1_start.....(后略)....

是对 GetGlobalStatsForGame()函数的调用、随后传入的查询 Stats 条目的数量,以及分别输入的 Stats 的后台 ID。

其中没有呈现的是该函数的最后两个可选参数——这两个可选参数甚至可以由你告知所需要数据的时间范围,它则会返回对应日期范围内的每日数据。

https://api.steampowered.com/ISteamUserStats/GetGlobalStatsForGame/v1/?appid=xxxxx&count=4&name%5B0%5D=c1_start......(中间部分略)......startdate=1718467200&date=1718553600

比如,我在刚才浏览器里输入的那一大串,后面再加上额外的参数(startdate=1718467200&date=1718553600),即可让它帮我查询北京时间 6 月 16 日 0:00 至一天后的数据(对应 GMT 时间 15 日 16:00 至 16 日 16:00)。

加入的参数使用 unix epoch timestamp 格式——它表示的是自 1970 年 1 月 1 日(UTC/GMT 的午夜)开始所经过的秒数,你可以通过 https://www.extool.cn/timestamp/ 将它与北京时间进行换算(使用转换工具时,请注意默认参数是否为“秒”而不是“毫秒”,设置为毫秒将返回错误的数据)。

可以看到,此时它额外返回了按日分隔的 history 项。

  • 其中的第一项[date 1718409600], 经过计算网站的转换,可知其显示的是 GMT 时间 15 日 0 点;
  • 其中的第二项[date 1718490600], 经过计算网站的转换,可知其显示的是 GMT 时间 16 日 0 点。

可以发现,它用 date=xxxx 的方式,通过返回当日 GMT 0 点的时间戳,来做当日的标记。

虽然无法实现我预期的“基于小时”的精度范围,但基本也足够了,这项数据已可以使我知晓:“那一天,进入第一章节的玩家一共有 13 人”。

而后面的几项查询返回,则可以让我注意到:

1. story_c1_r3_bonus 的 history 只返回了一项来自 1718496000(即 6 月 16 日)的数据,这说明 15 日并无数据更新;

2. 即可知,在 15 日那天,进入第一章的 13 个人里,有 7 人推开了那扇门,却没有 1 个人发现那个房间里的秘密;

3. 直至 16 日,27 位玩家里的 20 人推开了那扇门,最终才有 2 人发现了那个秘密...

作为开发者,由于你在后台还可以看到实际的 Demo 下载人数(且这个数据不像 Wishlist 那样一天一更, 而是实时更新),那么,结合以上信息,你完全可以推算出诸如“每日下载人数里究竟有多少人实际游玩”,而“他们又大概有着怎样的章节完成度和彩蛋发现度”等很具体的信息了。

后台配置要点

所以,需要为此做哪些准备呢?

其实只需要用好 Stats 里的“Global 统计复选框”。

比如将一项的最大值设置为 1,这样,结合 GetGlobalStatsForGame 函数,每一个数字就可以代表一个人了。

也可以统计某件事物使玩家在其中累计消耗的时间。

如果你想比较两个放置得很近的可交互物体——究竟谁对玩家更有吸引力一些,那么并置这两项的累计交互时长数据就会是一个很有价值的信息。

Stats VS 统计型成就的迷思

以上,考虑到 Demo 通常较小的体量,以及它与本体后台分离所带来的,“可以基于自身情况单独配置独特后台 Stats”的灵活度——可以想象,在参与类似新品节这样的活动时(或是制作特殊包体),这能够给开发者带来多少便利。而如果将以上思路落实于本体呢?想来可以做到的就更多了。

尤其是这些年来,一些游戏似乎呈现出一种“试图以成就系统尽量替代统计功能”的风潮。而若集中地、有针对性地将信息收集放置于 Stats 中,或许也能避免这种风潮所带来的某些潜在影响?

让很多全成就玩家闹心的互斥型成就,以佐特为例

一些游戏中存在的统计型成就,往往会演变为玩家较难达成,或经历较繁琐流程才能达成的挑战。

有时候体现为“当涉及分支路线时,需要新的周目才可以解锁”(以《空洞骑士》的佐特系成就为代表);有时则体现为需要做一大堆无关紧要的清单事项才能获得相关成就。

而这类成就的设置一旦把控不善,往往会给一些玩家带来不必要的困扰和痛苦(尤其以并不那么激进追求全成就,但又渴望尽量收集成就的那类玩家为典型代表)。

因此,如果在以上情境中,你只是想为作为开发者的自己收集一些额外信息,那么显然,Stats 其实可以成为更合适的选择。而干净的统计功能与成就功能的区分,想必也能反向促使开发者设计出更合宜的成就系统。

辅助工具

最后,可能你刚才就想问了 ,“ Web-API 这么难读又难写,该怎么上手呢?”稍作调查之后,我发现一些网站早已在尝试帮助开发者解决类似的困扰了。

https://steamapi.xpaw.me/#ISteamUserStats/GetGlobalAchievementPercentagesForApp

如上所见,该网站已将常见的 API 汇总,并以可视化填表的方式列出(我演示所用的链接便是借由工具快速获得)。

为了提升可读性,在生成的链接末尾还可加入诸如 =xml  之类的后缀,这将改变返回信息的显示格式。

更多这类知识,简单阅读官方文档即可习得。


最后,附上一个来自开发者 AuroDev 的 Youtube 视频,《运用 Steam Stats 实现数据驱动的游戏开发?》(Using Steam Stats for Data Driven Game Development?),感谢他,这也是我学习 Stats 初期,带给我启发的一个视频。

讲解完该机制后,AuroDev 也从数据隐私的角度讨论了这种数据获取方式的好处,大意是:“因为玩家在接受 Steam 的服务条款时,已经允许了 Steam 以合适的方式收集游戏数据,所以对于使用 Stats 的开发者,可以获得一层额外的数据安全背书”。


希望本文可以在 Demo 准备阶段给各位同行带来一些灵感。也祝愿在诸如 Steam 新品节这类活动中,除了流量与曝光之外,大家还能获取更多有趣的数据,同时也获取更多的快乐。

本文为用户投稿,不代表 indienova 观点。

近期点赞的会员

 分享这篇文章

Zephyr Guardian 

分享为享,非铸为像 

您可能还会对这些文章感兴趣

参与此文章的讨论

暂无关于此文章的评论。

您需要登录或者注册后才能发表评论

登录/注册