玩家以特工身份行动。官方媒体确立了玩家视角的行动,而命名记录则需要页面级社区验证后,档案才会附加传记、阵营、机制或故事声明。
玩家角色
从玩家视角的特工记录开始。
官方体验及其媒体提供了稳定的定位:玩家以特工身份进入一个最多五人的合作生存体验。这足以定义主要记录,无需虚构主角、标准外观或固定队伍组成。特工页面应将玩家连接到专长角色、特质栏位、武器、补给、搜刮与防御循环以及撤离目标。
官方图像用作行动背景,而非肖像数据库。下图描绘了体验的玩家视角世界,但档案不会将人物裁剪成命名肖像,也不会分配媒体记录未提供的身份。专门的命名角色页面只有在来源将图像绑定到该记录时才能接收图像。





签名记录
特工案件档案与系统链接。
- 玩家角色
- 特工
- 最大服务器人数
- 5 名玩家
- 活跃特质上限
- 最多 3 个
- 专长角色分组
- 基础 · 前线 · 后方 · 支援
案件档案刻意保持简洁。它记录了稳定的、会改变wiki其余部分导航方式的事实:玩家是特工,服务器最多支持五名玩家,当前社区数据列出最多三个活跃特质,当前专长索引按基础、前线、后方、支援组织条目。每个字段指向一个系统路线,而非假装特工记录包含所有机制。
下方的对比表将角色与记录分开。“特工”标识玩家角色。盟军、掠夺者、头目以及故事或结局记录是在社区路线表面观察到的浏览家族。某一行存在意味着档案有地方验证它;它并不断言当前的阵营、生成行为或叙事状态。
4 条记录
| 记录家族 | 此处确认的内容 | 下一步验证 |
|---|---|---|
| 特工 | 玩家视角角色与系统链接 | 专长、特质、装备与攻略路线 |
| 盟军 | 观察到盟军索引路线 | 在其来源页面上验证每个命名记录和关系 |
| 掠夺者与头目 | 官方描述命名了军事化掠夺者;观察到头目路线 | 分别验证遭遇机制和当前状态 |
| 故事与结局记录 | 社区表面存在命名和结局路线 | 将叙事声明绑定到专用来源 |
观察到的名称
浏览名称,无需导入未经支持的档案。
当前社区路线清单列出了包括 Adrian、特工“Jericho”、神射手“Ilija”、叛逃者“Daemon”、Sledge Queen 和 Yosef 在内的命名记录。这些名称是有用的搜索目标,但清单本身并不能确定某条记录是可玩的、友方的、敌对的、历史的、事件专属的还是叙事的。因此,此页面将它们作为观察到的记录呈现,并将详细声明推迟到未来的页面级审查。
这个边界防止了两种常见的wiki错误。第一,重定向或重复标题可能被误认为是第二个角色。第二,战斗指南、头目波次页面或结局路线可能被合并到传记中。档案会保留精确的观察标签和仍需进行的来源检查类型,使得后续扩展有迹可循而非推测。
6 条记录
| 观察到的记录 | 观察到的路线表面 | 详情前所需条件 |
|---|---|---|
| 阿德里安 | 命名社区页面 | 身份、角色与当前相关性 |
| 特工“Jericho” / Jericho | 两个相关的路线标签 | 重定向或不同记录的关系 |
| 神射手“Ilija” / Ilija | 两个相关的路线标签 | 别名关系与来源范围 |
| 叛逃者“Daemon” / Daemon | 两个相关的路线标签 | 别名关系与遭遇背景 |
| 雪橇女王 | 命名页面加战斗指南表面 | 当前角色、遭遇与机制来源 |
| 约瑟夫 | 命名社区页面 | 当前角色与叙事边界 |
操作身份
使用角色记录来明确团队职责。
在游戏中,最有用的角色问题通常不是“谁的传记最长?”而是“在当前周期中,这名特工负责什么职责?”专长角色、所选特质、武器类别、弹药需求和携带补给创造了一个临时的操作身份。小队可以在恢复的装备或受伤改变计划时更改该身份。
因此,角色页面应该向外链接。特工连接到专长和特质以了解配装形态,连接武器和物品以了解资源需求,连接敌人以了解威胁词汇,连接攻略以了解时机。命名盟友或敌对角色连接到其特定来源的遭遇或故事记录。这个图使角色档案保持实用,同时尊重玩家构建与叙事实体之间的区别。
结果是一个可以成长的名册,而不需要通用肖像墙。当可用来源能够支持身份、关系、机制部分、当前状态和媒体处理时,记录才能获得专用页面。在此之前,观察名称表仍然是诚实的索引。
常见问题
表中的所有名称都是可玩角色吗?
不。该表记录了当前社区路线清单中观察到的名称,并明确避免仅从标题分配可玩性、阵营、遭遇类型或故事状态。此页面上经过验证的玩家视角角色是特工。每个命名记录在获得详细档案之前都需要自己的来源审查。
为什么特工案件档案链接到系统页面?
特工的实际角色由专长分组、最多三个活跃特质、装备、补给以及小队当前任务决定。链接这些系统使记录在游戏中保持有用,并防止角色页面重复属于专用数据库的不稳定机制。