如何做一个圣遗物管理系统：产品需求文档

系列文章：

1. 如何做一个圣遗物管理系统：产品调研与分析
2. 如何做一个圣遗物管理系统：产品需求文档（本篇）
3. 如何做一个圣遗物管理系统：产品介绍

在一番技术调研之后（并没有捞到程序大佬），以及自己对于圣遗物管理的强烈需求的驱动下，这篇「产品需求文档」得以更新。当然，在上篇需求分析文章的最后，圣遗物管理系统的需求已经转化为一种「辅助」式工具。但为了保持系列文章标题的统一性，这里还是称为「圣遗物管理系统」吧。

产品需求文档，作为工作期间打交道最多的文档，这篇文章多多少少会透露出我的习惯。不过我这个人嘛，不是非常讲规矩，文档自然也会多样化，可能并不能作为一篇合格的「产品需求文档」的参考，如有异议，欢迎讨论，正文部分就不讨论产品需求文档该怎么写了。

不同的是，这一次的文档面向对象前前后后都是我自己，是一次完完全全和自己交流的过程。当然，文档的目的还是一致的，使得整个工具的需求更加明确，后续第一版工具的研发过程不会因为各种思路调整而改来改去（除非我遇到技术难题实现不了既定需求，那也只能被迫改需求了）。

修订记录

序号	版本号	修改说明	作者	日期	备注
1	0.1.0	创建文档	Skeathy	2022.7.13

需求简介

在上一篇关于需求分析的文章中，已大致得出产品需求的结论：帮助玩家快速判断圣遗物及套装对于特定角色的强度数值。具体一点，就是以贴图的形式，在游戏界面上标注圣遗物的评分。

用户行为

graph LR
    A[选择角色] --> B[选择圣遗物] --> C[触发行为] --> D[查阅评分结果]

从用户行为角度而言，整个产品的使用流程非常简单。

1. 选择角色：用户可以选择游戏中的某一个角色，后续的圣遗物将针对此角色展开。
2. 选择圣遗物：用户在游戏中选择某一个圣遗物，游戏内界面展示出该圣遗物的属性。（可以是背包，也可以是角色的圣遗物装配栏）。
3. 触发行为：用户需要告诉程序应用「我想要知道当前选择的圣遗物评分」，然后触发相关进程。最直接的自然是「选择圣遗物」的行为直接构成触发行为。但鼠标左键这一行为过于常用，作为触发事件是否会对其他正常操作产生影响有待进一步探讨。
4. 查询评分结果：查看圣遗物的评分结果。由于游戏内只能一次查看一个圣遗物的详细属性（点开一个忘了上一个），该产品的评分结果需要持续保留在屏幕上（圣遗物列表上）。

（抛开第三方工具的局限性，更加合适的方式肯定是打开列表就可快速查看到评分结果，而无需一个个去点。最理想的方式自然是游戏内置，给圣遗物的表加个字段用于记录分数。至于如何算分，官方可能不好解决，不如交给用户手动输入自己算的分，至少一次算好后可以永久保留。如果是纯第三方工具的话，就涉及一些数据本地保存与数据更新的问题，可以考虑后续版本添加。）

需求列表

1. 主窗口中选择角色的控件（下拉选择框，配备搜索过滤功能以应对角色过多选择困难的情况）。
2. 圣遗物识别（OCR 技术+文字处理，获取到词条属性及对应的数值）。
3. 圣遗物评分计算，需要确定算法规则并根据不同角色做适配。
4. 评分结果显示，以贴图（某种窗口）的形式直接呈现在游戏界面上，并需要关联到对应的圣遗物选择区域附近。

需求详述

原型

详见 Figma 文档： Artifact Auxiliary 。

由于实际上用户可操作的界面非常少，原型也非常简单，主要包括两个部分：

1. 主窗口的角色选择。
2. 贴图窗口的分数显示。

大头的需求还是要落在后台的识别和计算，以及一些不怎么常见的交互方式上。

主窗口

核心组件下拉选择框，用户可从候选列表中选择想要测试的角色。（具体的交互方式可以丢给交互设计师吗？）

• 候选的角色列表数据可参考 米游社-角色图鉴 ，排序按照元素类型分（便于后期维护更新），每个元素类型下的排序按照图鉴里的来就行。
  • 默认情况下为空选择，并显示「–请选择角色–」。于此相关的，有效词条的配置也存在默认项，以针对空选择或通用情况下的分数计算。
  • 同一角色可能存在不同的玩法，比如反应流或纯色流，对应的有效词条配置也会不一样。针对比较常见的多玩法角色，予以不同的玩法的支持，在角色后标注玩法类型。（不过我确实不怎么懂有哪些角色有多种玩法，随缘加吧，有反馈就补上，问题不大，下面随便记录一些。）
    • 可莉-蒸发流、可莉-纯火流
    • 温迪-攻爆流、温迪-精通流
• 搜索功能。最常用的前后连续匹配搜索即可——候选列表中有任意连续字符与输入匹配则筛选出匹配的角色列表，用户可在筛选后的列表中进行选择。

触发行为

前面已经简单讨论过关于圣遗物识别的触发行为，这里再继续展开讲讲。

PC 端的基础交互行为是键鼠，而在查看圣遗物这一操作行为中，玩家的主要操作为鼠标移动+左键点击。倘若使用最直接的左键点击，在识别阶段是没有什么问题；但在识别过后，用户的其他操作，比如装配、强化圣遗物等等，由于频繁的左键点击操作，可能会与识别的触发行为冲突，造成很多无效识别的情况，并给出干扰用户的无效贴图结果。理论上无效识别可以静默处理（不给贴图结果就当无事发生），但总感觉有些消耗资源。而且我并不确定自己能不能写出无效识别的逻辑，把界面业务变复杂，识别出来的结果就更加复杂，何为无效实际上比较难判定的。

所以最终定下不要使用左键点击事件作为触发行为。剩下可选的就是鼠标的其他键（中键、右键）和键盘事件了。和几位前端的朋友了解了一些技术原理，鼠标事件在窗口外的定位会比较复杂，所以是不是需要考虑一下使用快捷键+蒙版（建一个全屏的窗口）形式去追踪所选的圣遗物的坐标，有点类似于截图的功能和形式。

由于技术力限制，具体还需以实际技术测试结果为准，这里仅做几个可能实现的优先级排序：

1. 优先使用鼠标右键事件，右键点击则对当前点击位置的圣遗物进行识别。由于游戏中右键点击并不会切换圣遗物选择，所以玩家的实际操作是左键点击一个圣遗物，然后再右键点击一次。
2. 可以结合一些键盘快捷键、鼠标事件，用类似截图的实现方式去触发识别程序。

此外，确定了触发行为后，需要记录触发行为的一些数据，用于后续的结果展示贴图定位。这里最重要的就是触发事件时所选圣遗物的坐标。具体方法可以获取鼠标的坐标，这就需要用户右键落在所选圣遗物的方框中，否则贴图就会贴在其他圣遗物上了；或者图像识别，直接定位选择的圣遗物的方框。不过图像识别对我似乎有点难，还是用鼠标吧。

圣遗物识别

圣遗物的主属性相对清晰，复杂的是对于 4 条副属性进行评估，相关同类评分工具也主要对副属性进行评分计算，所以识别的主要目标是圣遗物的副属性。

从屏幕上的信息到副属性词条和数值，比较常用的是 OCR 技术，可以使用网络 API 或本地 OCR 项目（自己研发是不可能了）。所以关键信息是确定识别的图片，也即截屏操作选择的区域坐标。

完成 OCR 识别后，获得了一些字符串数据，需要通过一些文字处理方法（比如正则表达式）从中得到格式化整理的数据，包含文字词条部分和数值部分。比如：

• 攻击力：35
• 暴击率：12.3%
• 元素充能效率：15.5%
• ……

由于攻击力、生命值、防御力包含百分比和具体数值两种情况，也需要额外处理「%」并作出区分。

评分计算

具体的评分方法已在上一篇文章中提到，总体上使用提瓦特小助手的评分方法—— 圣遗物评分方法 ，这里就不自己再去整一套算法了。

简单做下总结，每个角色（及玩法）有不同的有效词条，而每一个有效词条都可按比例转化为可累加的评分。为此，需要配备一些字典也好、数据表也好的数据，包括角色的有效词条和词条转化为分数的系数。

角色由主窗口用户选择而确定，同时为兼容用户未做选择或其他情况，默认设置一个比较通用的有效词条（攻击力、暴击率、暴击伤害）。

计算结果需要根据选择的角色，识别的结果和配置的两个基础数据来确定，大致可以用以下公式表达：

$$S=\sum_i^Nvalue_i*coefficient_i$$

其中$S$是评分，$value$是识别的有效词条的数值，$coefficient$是该词条对应的评分系数，数值保留一位小数。

评分结果显示

特别感谢 Snipaste 截图软件的贴图功能给的启发。对于这一贴图（窗口）而言，其实没有什么交互式的功能，只要保留窗口置顶使得结果一直可见即可。当然，贴图的坐标需要准确，使得评分结果和圣遗物能够对应起来，这由前面的触发事件决定。至于贴图出来后，后续在游戏页面内滚动下拉圣遗物列表，造成位置对应不上，这一版本暂时不考虑，相信一屏的数据已经够用。

然后是窗口的关闭/刷新操作。由于贴图窗口为了保持简洁，省略了窗口的关闭按钮，需要有额外的操作方法将这些窗口关闭，比如右键菜单，快捷键等（右键菜单又有 GUI，饶了我吧）。在实际应用中，也存在识别错误，需要刷新数据；或者换了另一种圣遗物/页面，需要重置所有贴图的情况。

所以存在两种关闭/刷新贴图窗口的需求：

1. 关闭单独的贴图。选中贴图（获取焦点）后通过快捷键 Z 关闭贴图。
2. 关闭所有的贴图。全局快捷键 Ctrl+Z 关闭所有贴图。

另外，关闭主窗口视为退出程序，也需要关闭所有贴图窗口。

写在后面

第一次用 Markdown 的格式写 PRD，各种富文本的图啊之类的需要切换再引用还是有一点点麻烦的（画图什么的如果没有所见即所得还是难受，说的就是 mermaid，外部导入后再修改又是一件让人头疼的事），还是各类集成了作图工具的在线文档好用。好在整体上功能简单，原型图也没几张，整个文档也没几个图要画。

不过本以为需求非常简单，PRD 会比较少，可惜最后写成 PRD 还是满满的字，更有很多具体的数据配置都懒得放上去（打算直接堆代码里了）。初版实现的功能还是相当简陋的，也不知道有没有能力搞个好看的 UI，就这样吧。

一些后续版本可优化的方向：

1. 很多前端坐标受 PC 的分辨率影响，后续要适配更多的分辨率。
2. 考虑一下自动化操作，一键自动控制鼠标遍历圣遗物然后把结果都呈现出来。
3. 适配滚屏的操作，可以一次显示更多圣遗物。
4. 数据本地保存，后续可一键调动后台数据然后将结果展现出来，无需一次次去识别，需要解决圣遗物更新的问题。