不起眼的困境
在早期的版本中，少部分遊戲曾有過較為奪目的 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 觀點。