支持街机游戏玩家协作的 MEAN Stack 开发技术 Web 工具

1. 引言

自早期大学计算机实验室的第一批实验游戏以及后来的街机游戏以来，竞争一直是视频游戏中的一个持续存在的影响因素。

如今，价值千亿美元收入的电子竞技产业拥有联赛和锦标赛，奖金达数百万美元。竞争不仅限于游戏内的玩家。在线平台也在竞争，以提供更好、更全面的平台、服务和数据分析统计，帮助玩家发现他们可以在游戏中改进的领域，或者跟踪他们在日常训练中的进步，以成为更好的玩家。这些最早提供给玩家的服务也是任何形式的竞技活动（虚拟或现实）中最基本的服务之一。

关于游戏基本和基础系统规则的数据的基本编目和可用性（或体育项目）。每次攻击造成的伤害量、每次攻击的有效范围、使用某些攻击所需的场内资源，以及许多其他基本信息。

电子竞技行业中一个有趣的案例是格斗游戏社群（FGC）。可以说，它是第一个发展出规模庞大且国际化的竞技社群的类型，但就整个行业而言，它绝对不是收入最高的，尽管这个场景规模庞大且稳定，足以举办多个格斗游戏的年度联赛和月度锦标赛。

这种明显的投资不足的一个症状是格斗游戏缺乏这些集中化且功能丰富的平台。本文展示了开发这样一个系统的一个过程。

2. 背景

格斗游戏（Johnson, 2017）围绕着瞬间反应和做出微秒级决策及动作展开，因此，玩家越了解自己的角色动作和移动，以及对手的动作和移动，就越能做好准备，越有可能取得胜利。

格斗游戏几乎普遍以每秒 60 帧（60 FPS）的恒定速度运行，使得每一帧持续约 16.67 毫秒。在格斗游戏中，你可以采取的每一个动作都包含在这些帧中，在这些帧之间没有中间点（Ketonen, 2016）。

所以，如果你想知道《街头霸王》中的隆（Ryu）发动重踢需要多长时间，与其说“大约半秒钟”，或者更技术精确地说“约 533.44 毫秒”，不如直接说“32 帧”要实用得多，也更有用。

在格斗游戏中，几乎每一个可以执行的动作都经过 3 个阶段，它们的时间是以被锁定在该阶段的帧数来衡量的（图 2）

• 起手或发动阶段，此时你的攻击尚未能够击中对手。
• 威胁或活跃阶段，此时你的攻击可以击中对手。
• 收招或恢复阶段，此时你正在返回中立或待机位置，但（取决于招式）无法输入下一个动作，因此可能会暴露在反击之下。

当受到该攻击时，根据对手是否格挡或被击中，会有防御僵直或受创僵直（图 3）阶段。
阶段（图 3），具体取决于对手是否格挡或被招式或攻击击中。

虽然它们的名称不同，但它们在机制上并没有区别。唯一的区别是它们被卡在这些状态的帧数。

3. 提议

过去，认识到帧数据必要性和有用性的格斗游戏玩家别无他法，只能手写在纸上进行编目和存储。例如，如图 4 所示。

不必多说，但存储这种定义游戏策略的数据存在的问题显而易见。它不便携，容易出错，而且如果你想与朋友或一起玩游戏的本地玩家群体分享，你必须手写一份副本，或者扫描并打印副本。如果游戏进行了平衡补丁更新，从而改变了这些数据。近三分之一——如果不是大部分——的努力可能会付诸东流，有效地浪费在“无用”的过时数据上。

以一个真实且及时相关的例子来说明这类更新，就是当前最受欢迎的格斗游戏之一《铁拳 7》的第四赛季更新。

(Sdtekken, 2020) 提供了 49 页的平衡性改动，涉及游戏中每个角色，以及新增的招式，修复了那些具有非预期属性/问题的招式，使其比预期更有效或更无效。但随着年复一年，格斗游戏社群开始在线聚集，因此他们开始使用在线工具来更好地协调和维护这些帧数据表，作为社区的共同努力，使用 Google Sheets 或 Microsoft Excel 的在线版本等平台（图 5）。

一些格斗游戏开发者也开始为他们最新的格斗游戏提供这些数据，例如卡普空（Capcom）于 2016 年发行的《街头霸王 5》，在其网站上提供了其所有角色的帧数据。虽然不是最用户友好的网站，但所有数据都在 Capcom (2020) 中。在某些特殊情况下，像 Nether Realms Studios 这样的开发者已经为他们的游戏提供了大约 8 年和 4 款不同的游戏版本。

当玩家需要在训练中复习某个招式的帧数据时，他们只需按下开始，无需退出游戏即可找到所有角色及其对手的最相关数据（图 6）。

即便如此，大多数时候，玩格斗游戏的社区仍需努力为自己创建这些帧数据表，尤其是对于早已发布的、肯定不会再获得开发者支持但仍有活跃玩家群体每天都在玩的旧游戏。这些旧游戏和新游戏的玩家仍然必须承担大部分的负担，在他们之间开发和共享这些资源。

尽管这些社区可以利用 Google Sheets/Excel Online 或类似维基百科的网站来存储和管理所有这些数据（Shoryuken, 2020）。

很明显，一个专业的平台可以帮助这些不同的社区拥有一个更集中的平台来满足他们所有的需求。并且，通过将基本的帧数据编目作为基础，允许未来改进提供更多功能。

如果你使用电子表格来解决问题，你总是可以开发一个专门的工具，以更好、更有效、更具可扩展性的方式来解决它。为未来的改进敞开大门，为特定问题量身定制，以帮助用户实现更高的效率和可用性。

4. 开发与结果

4.1 用户体验原型设计

起初，研究关注如何设计表格的第一个贡献界面。在下面（图 7）快速（且粗糙）的手绘草图之后

在初步想法之后，项目得到了改进，很快就过渡到了一个专业且丰富的 UI 原型工具。新结果如图 8 所示；根据纸质模板的初步设计，它具有必要的按钮、输入组件、标签、组合列表等。

不久之后，项目开始考虑管理特定表格的数据模式的页面会是什么样子，其结果是这个截图（图 9）。

这个早期的页面承担了不止一项工作，因为它也充当了管理游戏的页面，而不是一个单独的页面承担这个角色。这是我在开发过程中才注意到并纠正的一个问题，这让我将“管理游戏视图”与“管理数据模式视图”分开了。

4.2 功能和范围规范

起初，研究关注如何设计表格的第一个贡献界面。

本项目的主要目标是开发一个能够满足所有格斗游戏社区关于管理和存储其各自游戏帧数据的需求的平台。

1. 该平台将由一位管理员管理，该管理员可以访问：基本上对所有有 FGC 成员感兴趣被添加到这个集中式数据库中的游戏进行所有 CRUD 操作。
2. 在插入游戏后，授权的登录用户可以：对他们感兴趣的游戏表的模式进行完整的 CRUD 操作。
3. 在决定了游戏的特定数据模式后，一般的登录用户可以：根据自己的意愿为这些表贡献数据。
4. 最后，随着表的填充，任何人都可以：查看平台上所有游戏的帧数据。

这些操作和系统权限可以通过下面所示的初步 UML 用例图来识别（图 10）。

图 11 展示了用户基本操作的主菜单。这是 UX 交互风格的一个例子，具有现代化的视觉组件，并遵循良好的可用性标准来操作系统。

前端页面显示数据库中的所有游戏。在这种情况下，图 12 展示了它在前台的样子。

因此，在屏幕（图 12）上，可以理解管理员用户（admin）如何操作系统游戏。事实上，它表明了在系统管理员的最低权限方面所做的努力，以便主要的协作在于普通用户（登录用户）的范围内。

4.3 代码策略

图（图 13）显示了 API 后端路由的总体安排。我决定将后端 API 分为 3 个不同的路由，以便每个路由都有一个非常具体负责的区域。

游戏 API 将处理所有与数据库中集合的 CRUD 相关的 REST 操作，仅此而已。这些集合中的文档将由其他路由处理。

这张图（图 13）展示了 Index.js 和后端路由，例如，描述了 Data-router.js。然而，它通过 express JS 模块展示了实现。

然后，模式路由将处理所有与每个集合中的数据模式文档相关的 REST 操作。这个特定文档将决定集合的所有文档和数据将如何排列。这是本项目的一个关键/关键特性，因此我选择将其与数据 API 正式分开，因为它的作用很重要。

最后，Data API 将处理与集合中所有文档的 CRUD 相关的 REST 操作，但有一个例外。因为数据模式文档太重要且关键，无法在此通用 API 中处理。

代码展示继续跟进其他组件。例如不同页面之间的导航以及调用其他重要路由的函数（图 14）。

图 14（右上）实现了 schema-router.js。不需要 post 方法，因为数据模式应该在创建游戏时自动创建。

顺便说一下，这张图（图 14）仍然可以看到 Angular 中的路由，在前端层的 app.module.ts 中实现。同样，nav.components.ts 是关于页面路由到系统的。

图（图 15）显示了一个 Get 请求通过调用堆栈的交互过程。在这张图（右下）中，可以看到通过 manage-table.ts 的交互，在组件启动时，它调用返回可用操作列表的函数。

系统的主要集成点是 gameservice.ts，它加载将向后端发送 GET 请求到 Rules API 的函数。

在系统集成层协商之后，后端 game-ctrl.js 中的 getGames 函数负责与 Mongo 数据库通信。这个组件接收查询所需的所有结果，形式为 collections 数据类型。

最后，这个原型版本的完整代码可以通过 Github 上的公共仓库获取，链接如下：https://github.com/LaercioMBR/TCC-FrameData。

4.4 技术支持和规范

对于开发，本提案通过 Angular 组件和资源探索了 SPA（单页应用）结构，在一个页面模式下运行整个提案系统。为此工作开发了以下支持工具

• Visual Studio Code：用于生成应用程序代码库的文本编辑器
• Node.js + Express：用于 REST API 的后端
• MongoDB：用于作为项目数据库，提供易于开发的非关系型数据库
• MongoDB Compass：用于轻松管理和监控 MongoDB 数据库的原生 PC 应用程序
• Angular：由 Google 开发的多平台基于组件的前端框架
• PrimeNG：功能丰富且易于定制的 Angular 组件库
• Git：分布式软件版本控制系统
• GitHub：用于存储和版本控制项目
• Postman：用于在将后端 API 正式连接到 Angular 前端之前轻松测试后端 API
• HTML, CSS 和 TypeScript：用于组件开发和样式设计

开发的原型运行在由 Mongo DB 支持的非关系型数据环境中。这种非关系型数据库结构为工作提案和领域属性的维护提供了理想的执行环境，同时也从性能角度来看。

该项目处于一个竞争频率较低的背景下，但它必须处理大量的数据粒度，通常是相同类型或家族的。

图 16 展示了系统执行的演示。在这种情况下，显示了 MongoDB Compass 中的所有游戏作为 collections。

其他工具作为技术支持对获得项目成果也很重要。在最常见的开发 IDE、编译器和包管理器等工具中，Postman 对于开发至关重要，因为它允许在构建 API 期间进行测试和改进集成。图 17 显示了一个在完整原型 API 中已有的请求类型示例。

虽然前端仍在建设中，目前唯一完成的视图是管理员（admin）可以管理游戏。我预计该项目的其余开发工作将在一个月内完成。目前，后端所有多个 API 路由的所有 REST 操作都在工作。它们确实需要更多的时间来解决运行时可能出现的错误，但在给出预期的最终输入时，它们确实能如预期般运行。

5. 结论

这个项目旨在应对开发 SPA 平台的挑战，同时也是我第一次尝试 MEAN 栈。它有一个非常雄心勃勃的目标，即为整个格斗游戏社区服务，承担一项非琐碎的分布式数据编目任务。而且我认为这个项目，即使处于未完成状态，也已经实现了它。

它证明了这样一个平台的概念是可行的，并且可以提供一个有用、强大且专门针对管理和编目通用帧数据数据库任务量身定制的工具。允许几乎所有格斗游戏社区开始开发和改进他们各自的竞技场景，使用这个集中的数据库。

当这个项目达到最小可行产品（MVP）状态时，我计划进行一次公告，将整个项目开源给各种格斗游戏社区，以收集对平台实际用户们的兴趣，并希望能吸引其他更有经验的开发者，使之成为一个更好、完全实现的想法。

当达到这个目标时，我将开始开发更高级和专业的工具，为格斗游戏玩家量身定制，并将这个平台作为基础。因为该平台提供了格斗游戏玩家最基本和必需的信息，在此之上添加的任何内容都是非常受欢迎的奖励功能，而这些功能在该电子竞技产业的这一侧严重缺失。

参考文献

1. Capcom (2020)。“Capcom 官方主页”，[在线] 可在 https://game.capcom.com/cfn/sfv/character/sakura/frame/table#vt1
2. Johnson, M. R. & Woodcock, J. (2017)，“格斗游戏与围棋：探索职业游戏的美学”载于 Thesis Eleven，首次在线发布。ResearchGate 可在：查看讨论、统计数据和作者资料，网址为 https://www.researchgate.net/publication/312651324
3. Miikka Ketonen (2016)；“设计一款 2D 格斗游戏”；Kajaanin Ammattikorkeakoulu 应用科学大学。2016 年秋季。
4. Sdtekken (2020)，“Sdtekken 档案状态 2020 官方主页”，[在线] 可在 https://sdtekken.files.wordpress.com/2020/11/ tk7_changelist_v400_en.pdf，访问于 2020 年 10 月。
5. Shoryuken (2020)。“Shoryuken 官方主页”，[在线] 可在 http://wiki.shoryuken.com/Ultra_Street_Fighter_IV/Ryu#Frame_Data，访问于 2020 年 11 月。

历史

• 2020 年 11 月 27 日 - 文档创建
• 2020 年 12 月 4 日 - 同行内容修订
• 2020 年 12 月 9 日 - 修订和格式验证
• 2020 年 12 月 10 日 - 文档提交和修复图像链接问题