不起眼的困境
在早期的版本中，少部分游戏曾有过较为夺目的Stats社区后台形态：以V社自家的求生之路、CS:Go等游戏为主，但又不仅限于此。然而，这种界面在当今的Steam游戏中已不多见
（据网友讨论，带有这类Stats后台界面的游戏通常发布于2012年之前，并似乎主要是由source引擎所制作）
通过后台文档，我们能大概感受到Stats的主要使用意图大体没变：仍是侧重为玩家记录和呈现，只是更多的从显转向了隐，从外转向了内——当下，只有开发者去主动的搭配Steam API制作了相应的信息显示层，玩家才能够有机会在游戏内通过一系列或许名为[玩家信息]的UI界面获知具体的数据。
这或许一定程度上也是当下Stats常常给人一种【无论是在各种游戏还是在日常的开发中，都似乎处于边缘地位且容易被无视】的原因所在？即 “ 看起来需要额外费力，但又似乎没太大必要” 的感觉一直萦绕其上。
Web API
不过，Steam对于Stats，除了通过游戏内Steam-API获取信息的方法之外，其实还提供了一种叫做Web-API的方式
它由浏览器地址栏直接输入，由它获取到的结果大概长这个样：
可能是以往对于Web知识的储备不足，以及对Stats本身曾抱持过视若鸡肋的态度XD 这种方式对于我个人来说，在真正使用之前，无论是作为一名玩家，还是作为一名开发者，以往的经历中都甚少见人讨论; 或者即便听到了，也可能会感觉似乎比较抽象，似乎离自己较远...
直到最近我开始考虑为自己的Demo在新品节中加入成就和统计信息的时候...
该方式看起来比较复杂，但本质上无非就是将SteamAPI改为了通过网页输入—— 虽然看起来要输入的东西很多，但无外乎就是appID 、函数的名称、以及一些被不太直观的符号所连接起来的参数而已
就像上图中用到的这行的前半部分
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的方式，通过返回当日GMT0点的时间戳，来做当日的标记
虽然无法实现我预期的[基于小时]的精度范围，但多少也足够了，这数据已可以使我知晓：“那一天，进入第一章节的玩家一共有13人”
而后面的几项查询返回，则可以让我注意到：
- 明明查询两天，story_c1_r3_bonus的history只返回了一项来自1718496000（即6月16日）的数据
- 这说明15日并无数据更新（因为当日无数据，则不返回对应的date项）
- 即可知，在15日那天，这进入第一章的13个人里，有7人推开了那扇门
- 却一个人也没有发现那个房间里的秘密
- 直至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视频（感谢他，该视频也是我学习Stats初期带给我启发的一个视频）
该主播在讲解该机制的末了，也从数据隐私的角度论述了一下这种数据获取方式的好处，大意是：“因为玩家在接受Steam的服务条款时，已经允许了Steam以合适的方式收集游戏数据，所以对于使用Stats的开发者，可以在数据安全的角度获得一层额外的背书”
以上，希望本文可以帮助各位在Demo的准备阶段带来一些灵感
也祝愿各位能够在诸如Steam新品节这类活动中，除了流量与曝光之外，还能获取更多有趣的数据，同时也获取更多的快乐
感谢你的阅读！
暂无关于此日志的评论。