Tribal Age 交互设计复盘

项目概述

《Tribal Age》是一款面向海外玩家，融合了包括MOBA摇杆战斗，合成、Rogue Like、模拟经营等诸多创新的玩法，基于 COK-like 框架下的中重度战争策略手游。

版本迭代

交互团队正式介入项目时正处于早期的1.0版本，基础功能大致完成，但存在大量的设计和体验问题，无论是需求方还是来自玩家的真实反馈都不尽如人意。经过大约半年的优化之后，我们解决了绝大部分游戏体验上的痛点，玩家测试反馈数据上也有明显的提升。

后来，我们项目在前期玩法上做出了重大调整，来到了2.0版本。其中包括很多全新的机制和一些重做的系统，最多的时候我们UX团队同时有几十项大大小小的任务，又经过半年多的细节打磨，游戏整体的交互体验终于达到了市面主流的水准，UI风格也焕然一新。

工作流

我们团队的交互设计工作流程简单来说，一般先是策划或者PM负责提交策划需求文档和设计总单。作为交互设计师接单后开始需求分析和规划、以及后续的详细设计；完成交互设计方案后由我们发起评审会（与会人数不定），再根据需求具体情况制作交互原型或者修改方案，设计完成后输出交互说明文档交给UI设计师；UI设计师完成资源输出后，和策划一起参与走查。（如果设计中存在额外的动效需求，则给出初步方案与参考，列出详细的动效资源需求表后由相关美术人员给出资源，最后动效开发人员完成动效。）

最终产出物

基于策划原始需求的预研文档

@Yuque

用于需求评审会的交互方案

@Figma

用于模拟实机体验的可交互原型

@ProtoPie

交付给UI的交互设计说明文档

XXXX系统_Time_Version.pdf

其中，绝对不可或缺的产出物只有交互设计说明文档，该文档主要交付对象为UI及下游开发人员（GUI），可对照交互设计说明文档进行详细设计，UI设计师原则上不应再需要查阅原始策划文档。

作为交互设计师在具体的需求设计场景中要学会灵活变通，一味地追求绝对完整的产出在敏捷开发的环境下容易造成时间的延误，可根据不同的需求规模和时间要求调整文档产出。总之，统一文档输出和撰写规范是解决产出一致性和提升设计效率的有效方案。

一、前期设计

策划希望做一个类似剑与远征的“异界迷宫”，融合Rogue Like和摇杆战斗的副本玩法，承接游戏前期解锁地块功能以及中期的资源日常投放途径。经过前期的调研和讨论，再结合实际开发难度和可玩性等方面，市面上比较接近的成熟参考是DNF中的“房间”型副本战斗。

1.1 竞品调研

经过简单调研，市面上Rogue Like类型的游戏大多为主玩法，在底层逻辑和设计动机上更接近单机游戏，可以在机制上借鉴而不能简单地在玩法流程上照搬。本项目中的副本是作为辅助玩法而存在，所承担的更多的是鼓励付费，增加粘性等职责，它们没必要，也不应该用高难度去筛选玩家，降低学习成本让更多的人来玩，才能更好地达成该玩法的目的。

通过试玩筛选，下方截图中的四款房间即时制副本战斗的是较为符合需求的参考对象，都是在俯视角MOBA式操作中加入Rougue Like机制的RPG手游。

基于上述参考和具体需求，可以拆解出两个有关于副本内游戏体验的核心点：

随机祝福三选一

Rogue Like玩法的核心之一，是随机性与玩家选择策略的体现，可适度包装设计，且需要一定的仪式感。参考方向：各类肉鸽、自走棋等游戏。

副本地图信息

地图是玩家在副本内的重要功能，辅助玩家的移动决策以及的路线规划，可作为HUD上额外的导航。参考方向：各类房间、地牢探索类RPG。

1.2 交互流程

因为这是一个全新的玩法机制，为了尽可能地做到逻辑上的滴水不漏，首先要建立一个玩家在这个机制中需要执行的任务清单，并对这些信息进行结构化处理。它可以帮助我们梳理和简化玩家的操作流程，而不是直接用UI简单粗暴地堆砌在玩家面前，这一点在SLG类游戏中尤为重要。

二、方案设计

2.1 随机祝福三选一

获得随机祝福是一个带表现型的交互流程，可以进一步拆解成以下三个阶段

Part.1 祝福掉落

击杀房间内最后一个敌方单位后掉落祝福，祝福的种类包含技能和士兵等多种加成，故包装方向采用光效而非实体更为妥当。同时光效需要一定的暗示效果，采用辉光或Z轴上下循环浮动更佳。

Part.2 选择祝福

在这里我重点对祝福卡牌显示的内容做了优化：新获得的祝福显示完整的详细描述；而后续升级仅展示变化项。这样玩家可以更清楚地了解每个选项的核心重点，能够更快速地做出最优选择。

Part.3 获得祝福

祝福选择完成之后的反馈强化效果，主要分为两处：一是在三选一中强调玩家最终的选项，这里采用卡牌延迟出场，模拟视觉残留的特效；二是祝福对应施加目标的提示，采用光柱垂直照射的特效。

2.2 副本地图信息

玩家在存在地牢/副本类玩法的游戏中通常会需要地图来导航，一般都会配备一个小地图用于标注玩家的实时位置信息，并且这个小地图大多常驻于HUD上。

通过简单的分析拆解，副本地图的几个关键点

• 地图的总览信息
• 房间的类型信息
• 房间的状态信息
• 额外交互功能

上述的前三点可以统一为地图信息的展示性内容，过程就不过多展示了，下面为两版交互设计方案（A方案虽然我和策划一致认为功能性和美观度更优，但奈何开发成本和工期的原因只能退而求其次）

A方案

该方案在有限的房间格子内加入了房间路径的显示，能给玩家的行动路径更多地暗示；技术实现方面可采用瓦片拼贴的形式生成地图，但客户端和地编有不少额外的开发成本。

B方案

该方案在实现上更为简单，用不同的UI元素来标识房间状态。房间路径也单独标识了出来，空间利用上不如A方案紧凑；而且因为更加扁平，在视觉表现力上稍逊于A方案。

策划提出了一个希望能够跨越多个房间传送的需求，存在玩家可能因为种种原因错过了未拾取的宝箱、仍有高价值物品库存的商人、已经通关BOSS但想通刷副本等情况。这里想要回头前往这些房间并不困难，但是只能依靠控制角色移动前往这些房间无疑是浪费时间的愚蠢行为（有些房间距离可能非常遥远）。

由于时间紧迫的关系，我提供了最便捷的交互方案 —— 在展开的地图中增加可选中已探索的目标房间，一键传送的功能。

前期设计

先与策划了解相关背景明确设计需求，主要是针对已有系统存在的交互痛点进行优化。同时也着重了解该系统的具体使用场景，以及未来可能的迭代方向。

英雄系统在SLG类手游中是个常见的大型系统，对于该类系统的交互优化需要遵循玩家已有习惯，在有限的空间内尽可能简化操作、降低操作门槛，打磨更友好的操作和更高效的体验。

竞品调研

在正式开展设计之前我会进行简单的竞品分析，主要对核心功能的交互体验，以及整体的主观感受进行资料整理及聚合分析，辅助设计决策

可以看到，市面上的英雄系统可简单归纳为两种方案

A：英雄主页作为功能的聚合入口；前往子功能页的按钮以及核心信息分布于右侧区域(多数)

B：英雄主页仅作英雄的概览和切换功能；子功能隐藏至下级页面

方案设计

经过对市面上主流横屏SLG英雄系统的分析，再结合我们自身的设计需求，我也找到了原系统中不少的交互痛点。

改进策略

1. 视觉“减负”
把英雄系统首页的功能移入下一层级，使玩家的注意力不再因为过多的信息和按钮而变得分散。

2. 交互“减负”
将英雄培养与图鉴功能分离，同时增加UI间的转场过渡动效，增强主页与子页面之间的关联。

3. 信息“减负”
将信息重新整合，优化排布，在每个子功能中删去一些冗余的次要信息，强化核心信息的展现。

高保真可交互原型

为了获取更真实的玩家反馈，而不仅仅是停留在页面上的交互框架，我们希望能够在原型中加入游戏机制、UI、美术、视觉特效、动效等一系列完整的体验过程，我使用ProtoPie帮助我们在快节奏的游戏开发和真实的操作环境中进行demo验证。它能够以极低的成本去模拟大多数游戏交互，在最终方案落地前制作出高保真的可交互原型，再交由需求方来验证方案的真机效果，很多动态和细节问题可以在这一环节很好地暴露出来。

下面是英雄系统的ProtoPie原型供参考，您可以用鼠标尝试操作。

到这一步整个英雄系统的交互体验效果基本确定，一般经过多个需求方的体验，把动效细节参数的微调一下，就可以直接把录制好的片段提前交付给开发以供参考。

交互设计说明文档

我刚加入交互团队时，并没有具体的交互说明文档规范，长图，视频，文档，表格等多种格式文件交织在一起，难以保证设计效率、产出质量和整体体验的一致性，工作对接的同事也偶有抱怨阅读体验不佳。恰好我在担任UI时期积累了比较丰富的文档撰写经验，经过简单地梳理和借鉴，很快就沉淀了出一套适合于我们项目的交互设计说明文档模板，供各个交互设计师使用时参考。

其他案例

因篇幅所限，只能展示部分交互方案的详细设计过程，但你可以通过 点击下方 的不同案例查看设计缩略图。

战报系统

详细罗列参战双方不同场次战斗结果的汇总与统计，包含了大量的信息展示

战斗HUD

基础核心HUD内容，包括头像组件、战斗信息浮动显示、对象微操作等功能

摇杆对冲综合玩法

由摇杆战斗衍生出的包含对冲、防守、吃鸡等多模式关卡玩法

战报系统

详细罗列参战双方不同场次战斗结果的汇总与统计，包含了大量的信息展示

战斗HUD

基础核心HUD内容，包括头像组件、战斗信息浮动显示、对象微操作等功能

摇杆对冲综合玩法

由摇杆战斗衍生出的包含对冲、防守、吃鸡等多模式关卡玩法