排行榜参考体系结构
以下参考体系结构介绍排行榜用例以及具有不同替代方案的实现，让您能够构建自己的云解决方案，从而可以完全控制和自定义以完美适合您的游戏设计。
提示
如果您要查找开箱即用的排行榜解决方案，PlayFab是一个完整的后端平台，用于生成、启动和发展具有排行榜支持 的云连接游戏。
排行榜设计
在定义排行榜时，有许多变量可供考虑。 下面是一些示例，供您参考：
- 地理位置：玩家所在的地理位置。 从国家到地区再到大洲乃至更广阔的范围，根据您的需要确定粒度。 示例：法国、中国、美国、北美、亚洲、EMEA。
- 平台：运行游戏的设备或服务。 您也可以考虑启用合并多个平台的排行榜。 示例：Xbox、PlayStation、电脑、iOS、Android、移动设备、主机。
- 模式：改变游戏玩法和影响其他游戏机制行为的独有配置。 示例：单人、双人、小组、PvE、PvP、锦标赛。
- 难度：用户选择的挑战。 示例：容易、中等、困难。
- 选项：玩家选择的各个选项。 示例：角色（人、车辆）、物品（武器、工具）、设置（手动或自动变速）。
- 关卡：游戏中的关卡或阶段。 示例：关卡 2-1、赛道 3。
- 统计信息：玩家生成的各个值（基于使用情况或操作）。 示例：得分、获胜、失败、收集的硬币数。
玩家身份验证和标识
此参考体系结构不涵盖玩家身份验证或玩家标识。 这两项留给读者作为练习。
PlayFab 提供多种形式的身份验证，以便在多台设备上跟踪玩家：
- 用于访客登录的设备 ID
- 用户名/密码
- Google 帐户
- GameCenter 帐户
- Facebook 帐户
- Steam 帐户
- Kongregate 帐户
- Twitch 帐户
- 其他 oAuth 提供程序
- Android 设备 ID
- 自定义玩家 ID
大小和复杂性
排行榜可以是基于分数的极为简单的玩家排名系统，也可能因跟踪多个统计信息、选项、关卡、平台等的组合而变得既庞大又复杂。 例如，假设有一个组合了变量平台、地理位置、模式、关卡和统计信息的排行榜。 这将允许在游戏场景中使用“法国（地理位置）的 Xbox One（平台）玩家在第 3 关（关卡）进行玩家对战（模式）模式的得分（统计信息）”这样的值计算玩家的排名。 跟踪此数据后，您可以删除地理位置筛选条件，从而计算身处任何位置的所有玩家的排名。
再举一例，假设有一个组合了变量系统、关卡和统计信息的排行榜。 这将允许游戏在赛车游戏场景（例如“电脑（系统）玩家完成赛道 Nürburgring（关卡）的时间”）中计算玩家的排名。
当然，特定的游戏可能还会有更多计算玩家排名的方式。 提供的示例实现只是使用上述几个变量的起点。 在本用例中，将基于两个变量对玩家得分进行排名：平台和关卡。 每个平台上的玩家都将在每个关卡中夺取最高分数。 请以此为基础随意构建和修改，以适应您的游戏需求。
数据刷新
数据过时的排行榜比根本没有排行榜好不到哪儿去。 但是，出于成本原因，避免频繁刷新数据可能是有意义的。 尝试间隔一段时间刷新并重新计算排名，范围从每分钟到每小时。 在某些情况下，甚至每天刷新一次也是可以的。 但是，如果您确实需要（接近）实时刷新排行榜数据，此参考体系结构也能满足您的要求。
我附近的玩家
最佳实践是显示用户在排行榜上的位置，以便玩家可以看到谁排在他们上面和下面，让他们知道他们可以做得更好。 不要仅向玩家显示游戏中排名最高的玩家，这会令他们感到沮丧；让玩家明白可以轻松地实现排名攀升，这有助于提高他们的参与度。
反作弊
总有些玩家会尝试向您的排行榜中注入虚假分数，这会给社区造成负面影响。 您可以采取一些措施来提高作弊难度：
- 加密客户端与云之间的通信，以防止数据包探查。
- 添加遥测并在服务器端使用，以查看分数是否合理（理想情况下是自动生成），从而即时检测出作弊分数。 两项简单的检查是：
- 玩家真的能够在宣称的时间内完成关卡吗？
- 玩家多久提交一次分数？
- 不要丢弃不正确的分数。 将分数和提交此分数的玩家标记为可疑（要务必小心，因为您可能会意外影响到合法用户）。之后，当已知的合法用户访问排行榜时，仅检索未标记为“可能作弊”的分数。 当作弊者提交排行榜查看请求时，仅检索不正确的分数。 这样做的目的是避免给作弊者“伪造分数注入无效”的直接反馈，因此他们会以为自己成功了。
参考实现详细信息
选择用于存储排行榜信息的数据库时，首先要做出的决定之一是使用关系型还是非关系型 (NoSQL) 数据结构。 请牢记以下差异：
| 关系 | 非关系 | |
|---|---|---|
| 准备工作 | 必须事先确定数据的结构/架构，日后更改可能会造成破坏 | 所需的最小结构 |
| 刚度 | 所有数据必须使用相同的结构 | 每个数据条目可以有自己的结构，以后也可以轻松添加新字段 |
| 主存储模型 | 基于表 | 文档存储、图形数据库、键值存储或宽列存储 |
| 可伸缩性 | 可垂直缩放 - 增加服务器 CPU、RAM 或存储 | 可水平缩放 - 分片或添加更多服务器 |
有关不同存储模型的所有详细信息，请参阅选择适当的数据存储文档。
最后一点，要考虑个人对这两个选项的了解程度。 选择已知道路可避免一系列全新的未知问题，节省熟悉新的最佳实践和概念的时间。
下面是一个简单排行榜用例的两种不同实现，可以帮助您入门：
- 非关系 (NoSQL)：小规模部署使用 Azure Redis 缓存，大规模部署使用 Azure Cosmos DB。
- 关系：小规模部署使用 Azure SQL 数据库或 MySQL，大规模部署使用 Azure SQL 数据库。