不起眼的困境
在早期的版本中，少部分游戏曾有过较为夺目的 Stats 社区后台形态：以 V 社自家的《求生之路》《CS:Go》 等游戏为主，但又不仅限于此。然而，这种界面在当今的 Steam 游戏中已不多见。
据网络资料，带有这类 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&enddate=1718553600
比如，我在刚才浏览器里输入的那一大串，后面再加上额外的参数(startdate=1718467200&enddate=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 观点。返回搜狐，查看更多
责任编辑：