关系数据库

Shards of Order 角色

三位英雄,一个概率空间。

三位可玩的Shards of Order角色是安东、雅娜和列夫。他们的名字出现在官方技能树界面中,第一方资料表明每位角色都拥有个人技能树、多种受支持的玩法风格和个人故事线。他们的构筑不能被视为独立的牌组:所有人都从同一个共享牌库中抽牌,因此通过一名英雄的成长路线添加的卡牌会改变后续的每一手牌。本数据库仅比较这些经过验证的关系,不分配未经支持的职业、传记、排名或战斗统计数据。

角色名单字段特意设计为关系型。名称标识经过验证的英雄;个人成长记录独特的技能树和个人故事线;玩法风格范围反映已发布对多种方法的支持;共享牌库后果记录个人选择贡献卡牌时会发生什么。这些字段使三行数据保持有用,而不必分配一个已发布材料未确立的固定职业、传记、数值角色或排名。请将表格视为一张关联决策的地图,而非三张孤立的角色表。

角色保持个人技能树独立区分已验证的剧情弧与编造的传记从队伍层面判断进度
Anton · 角色保持个人技能树独立区分已验证的剧情弧与编造的传记从队伍层面判断进度
Yana · 角色保持个人技能树独立区分已验证的剧情弧与编造的传记从队伍层面判断进度
Lev · 角色保持个人技能树独立区分已验证的剧情弧与编造的传记从队伍层面判断进度
官方Shards of Order角色与装备界面
装备界面保持完整,以便角色、装备栏和队伍上下文始终可见。

装备 · 组建队伍

追踪每件物品进入共享手牌

武器、护甲和记忆可以改变英雄的玩法风格,并可以将卡牌插入共享牌库。比较个人收益与新卡牌为所有三位英雄创造的序列。一件物品可能强化穿戴者当前的成长路线,但如果其卡牌与另一张前置卡牌竞争或在缺少有用搭档的情况下出现,它仍可能降低队伍计划的一致性。在判断物品在当前构筑中的价值之前,必须同时回答穿戴者问题和牌组问题。

沿着完整的观察路径追踪每个装备决策。识别佩戴者及正在测试的个人打法,记下该物品是否添加卡牌,然后观察该贡献与其他两位英雄的卡牌搭配时的表现。记录它帮助队伍解决了哪个可见的倒计时问题,以及下次行动时还剩什么可用。这可以避免将装备视为私人的属性变更,而忽略游戏系统至少将部分装备选择纳入了共享手牌概率问题。

当结果不明确时,进行一次受控的替换。保持三棵个人技能树和其他装备不变,只更换一件物品,然后比较后续混合手牌在相同时间点下的表现。一个有用的改动可能增强佩戴者,也可能改善共享序列,或两者兼有;一个吸引人的个人效果也可能让公共牌池变得不那么协调。命名这些结果比给装备分配一个通用等级更有信息量,因为装备的验证价值取决于它修改的具体队伍进度和牌组。

保持个人技能树独立

安东、雅娜和列夫各自拥有一棵个人技能树。这使得每个进度选择都有可追溯的来源,即使其卡牌效果可能被共享。在复盘弱势手牌时,找出未能产生联系的贡献,然后追溯提供该贡献的英雄和技能分支,再考虑更改其他两棵技能树。这能保持诊断的精确性:抽到卡牌的英雄不一定是其进度将卡牌放入牌池的英雄,而失败可能源于周围的队伍计划,而非仅仅来自那棵个人技能树。

官方资料支持每位英雄的多种玩法,因此角色列表不会将任何名字限定为单一固定角色。根据正在测试的构筑来定义当前角色。一个有用的功能描述应说明该英雄旨在贡献什么,该贡献解决了哪个可见的时机问题,以及两位队友的哪些卡牌可以与之配合。如果描述依赖于一个不支持的职业标签或一个假定的固定连招,应将其改写为可观察的手牌和倒计时关系。

将洗点作为比较工具,而非一次性重建所有东西的理由。修改一个分支,保持其他个人技能树和装备不变,观察预期混合序列是否更可靠地出现。如果有所改善,记录队伍层面的变化:也许该英雄现在提供了更灵活的起手,也许一张多余的设置卡离开了牌池,或者另外两位英雄能更频繁地利用由此产生的位置。这种方法在通过一副共享牌组判断实际协作时,保留了个人身份的独特性。

官方径向技能树,标示为雅娜、列夫和安东
官方技能树界面提供了三个经过验证的名字和各自独立的个人进度。

从队伍层面判断进度

一个强大的个人升级并不自动等于一个强大的队伍决策。如果它添加了卡牌,那么抽到每张现有贡献的概率都会改变。根据它与其任一队友产生的序列、它服务的倒计时窗口,以及在牌池扩大后队伍更难找到的贡献来判断这个选择。这并不要求每个英雄都做相同的工作。它要求每个人的路线解释清楚,当共享手牌混合了所有三个来源时,其添加的卡牌如何保持有用。

将战斗手牌作为反馈。如果某个英雄的卡牌反复出现,却没有所需的支援或时机,检查提供这些卡牌的技能和装备选择。区分三种可能性:贡献可能对当前队伍规则来说过于狭隘,另一张添加的卡牌可能竞争相同的时机窗口,或者出牌顺序可能在设置完成之前就推进了敌人队列。只有前两点直接指向构筑调整;第三点则需要用相同的牌池尝试不同的序列。

在固定的检查点审查进度,而不是对每一次抽牌都做出反应。说明队伍规则,列出每位英雄的预期贡献,并记录哪些混合组合在最近的敌人行动前实际达到了有用状态。然后更改一个来源并重复比较。目标不是消除专精,而是让专精对其他两条路线变得清晰可读。当一棵个人技能树的卡牌能够进入共享手牌,而不会频繁阻挡队伍仍需执行的时机任务时,它就在队伍层面上成功了。

  • 确定提供该贡献的个人技能树。
  • 定义该贡献解决的倒计时问题。
  • 检查来自另外两位英雄的有用搭档。
  • 一次只测试一个洗点或装备来源。

区分已验证的剧情弧与编造的传记

第一方资料明确指出,安东、雅娜和列夫各自拥有一条个人故事弧。这支持将他们视为不同的叙事参与者,但并不能支持那些在已发布记录中缺失的详细传记、隶属关系、出身或关系结局。因此,角色数据库将故事弧作为一个已验证的字段,并使其与别处描述的战斗关系区分开来。一个可见的服装、配色方案、肖像表情或在一张截图中的位置,不足以将印象转变为事实背景故事。

记录叙事信息时,应将其附属于提供该信息的具体对话、日志条目、故事事件或官方描述。区分游戏直接陈述的内容与选择仅仅暗示的内容,不要将一种可能路线转化为角色的普遍历史。个人剧情弧也可能与玩家决策相交,因此在一个选择后观察到的结果应保持与该路线相关,而不是呈现为每个战役的唯一结局。

只有当新的角色字段能够被一致地应用并追溯到正确的英雄时,才应添加。安全的更新可以描述游戏或官方出版物明确说明的命名关系、事件或进度结果;不安全的更新则是用猜测的角色、动机、年龄、职业或结局来填补空白。这个边界在发行初期探索阶段保持了角色列表的实用性:玩家现在可以比较验证过的进度和共享牌组的效果,而叙事细节只会在可复现的信息可用时逐步扩展。