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

本文最后更新于:2022年8月5日 上午

系列文章:

  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. 数据本地保存,后续可一键调动后台数据然后将结果展现出来,无需一次次去识别,需要解决圣遗物更新的问题。

如何做一个圣遗物管理系统:产品需求文档
https://skeathytomas.github.io/post/如何做一个圣遗物管理系统:产品需求文档/
作者
Skeathy
发布于
2022年7月13日
许可协议