页游项目设计指南分享

96
UXplayer
0.2 2016.08.10 18:02* 字数 5057

指南来自之前一款页游项目,代号WG006,现已正式运营近2年。
本文写于该项目的立项之初,所用图片来自于该项目的示意图或更早已上线项目的示意图、截图。
当时由于看了iOS和Material Design的Guideline,心血来潮,便尝试了终结整理了一番,
发布之前删减了一些涉及「内部秘密」的图片,并调整格式以适应markdown。
如果您恰巧看到本文,欢迎指出其中的不足之处。

1 概述

  • 示意图的阅读者为美术人员,因而需要着重表达的是信息显示
  • 显示什么信息?
  • 如何组织排列?
  • 每条信息以何种方式呈现?
  • 再配合一些适当的规则讲解,方便美术人员更准确理解示意图所要传达的信息

2 示意图输出

  • 一个系统所涉及的所有界面都需要提供示意图
  • 即使一个系统的几个界面很相似,也要尽量单独列出示意图,只做文字说明容易遗漏细节
  • 同一个界面的多种状态,导出在同一张示意图中以方便对比
  • 若界面尺寸过大、放在同一张示意图中不便于浏览时,可以分多张图导出
  • 弹窗Alert类小窗口,与打开该弹窗的界面存在同一张示意图中
  • 对于流程较复杂或界面较多的系统,需要给出界面流,表面各个界面之间的相互关系,以爬塔系统为例:
爬塔系统界面流

3 界面入口

  • 目前游戏中的界面入口主要有以下几种:
  • 通过主UI功能图标
  • 通过NPC/传送门等场景元素
  • 通过某个界面内的按钮、链接
  • 使用物品等
  • 不同的入口,有时也会对界面样式有一定的影响。反过来,一个界面的样式有时也会对其入口有一定的限制。例如:
  • 通过NPC打开的界面适合采用NPC对话框的形式
  • 全屏界面中的按钮不适合再打开另一个全屏界面(除非按钮表达的是场景切换)
  • 界面入口无法在示意图中体现,但它在设计界面时应该明确,并在文档中写明
  • 除了主入口之外,还需列出是否可以通过关联系统打开、是否需要在其他界面额外增加入口等

比如称号、时装系统,除了主UI的入口按钮之外,还有人物界面上的入口按钮

4 界面尺寸与布局

4.1 尺寸

4.1.1 全屏界面
  • 固定为1440*750
  • 还需考虑到小屏幕用户的尺寸(最小支持到1024*768)以及其他UI元素(如主UI)占用的空间
  • 因此画面的主要部分,应在大约1000*650的范围之内
  • 全屏界面还有一些基本的通用元素,这些通用元素会对界面的显示区域有一定的布局影响,在示意图中需要把这部分添加进去。这些通用元素有:
全屏界面的通用元素
  1. 左上角的货币显示区域
    当这个系统涉及到货币、资源消耗时,需要显示
  2. 中上方的界面标题
    若非特殊情况,都需要显示标题
  3. 右上角的关闭按钮
    贴合操作习惯,全屏界面的右上角都需要有关闭按钮
  4. 左下角的聊天框
    只要这个界面不是非常短暂的过度性、一次性界面,就应该显示
  5. 右下角的的功能按钮
    此处显示的按钮数量根据该界面主要会用到的系统而定。通常有【人物】、【背包】、【技能】,以及固定需要显示的【返回】
4.1.2 二级界面
  • 一般的二级界面尺寸,需要控制在900*550的范围之内
  • 如果这个节目需要经常与其它二级界面一同打开,需要考虑两个界面的总宽度

例如背包界面与人物界面、邮件列表与邮件内容

4.2 布局-信息列表

  • 收件箱里的邮件、背包界面的物品、人物界面的侠客切页,等等,所有的信息组合,都可以看做是一个信息列表。
  • 这种列表都需要考虑分组方式、排序规则、默认值、筛选过滤等
4.2.1 信息分组
  • 哪些信息可归为一类,归类的依据是什么,相关联的的部分在位置上尽量靠近。
  • 组与组之间的主次关系如何,更重要的信息组应该更醒目
4.2.2 排序规则
  • 优先按什么排序、再按什么排序,一般至少列2-3个排序条件,最后再用唯一的主键ID来排,不能让程序按照收到消息的先后顺序来随意排序。
4.2.3 默认值
  • 在显示各种信息时,需要考虑默认值。
  • 默认的选择

比如关卡界面:最初显示第一个切页,之后显示上次关闭时所在的切页,开启新区域时将默认切页设为新切页,再次打开界面后,再记录关闭界面所在的切页。

  • 每个元素的默认状态

特别是头像、模型等数据资源,在未加载到数据时,如何显示。例如在物品图标未加载时,在图标框内显示一个固定的菊花转loading动画

4.2.4 筛选过滤
  • 当信息列表中有较多项目时,需要考虑是否需要筛选或者过滤,筛选过滤规则是什么

比如背包里按物品类型、侠客谱按照侠客品质

4.3 状态差异

  • 一个界面通常有各种不同的状态,需要列出各种状态的示意图
  • 如果状态变化比较少、比较简单,可以通过简单的文字叙述。
  • 主要的状态差异有:不同的操作状态、不同阶段的状态、不同玩家时期的状态、不同玩家视角的状态
4.3.1 不同操作状态
  • 主要是在拖拽中状态下,需要仔细考虑关联元素的状态
4.3.2 不同玩家时期的状态
  • 主要是指随着玩家等级、VIP等级之类的成长状态的变化,界面有哪些不同的状态
  • 在考虑玩家时期的状态时,第一眼状态的界面表现更重要,而美术的效果图通常习惯按最终状态(或满状态)来设计,可能会导致第一眼状态很不美观,在审核美术效果图时,需要额外注意这点
4.3.3 不同玩家视角的状态
  • 玩家视角,与玩家时期不同,视角是可以转换的,而时期是不可逆的,例如
  • 公会会长与普通会员
  • 跨服竞技的参赛选手观众
  • 帮派战时的己方信息和敌方信息
4.3.4 不同阶段的状态
  • 由系统自身规则所呈现的不同阶段,也是最重要但却容易忽略的状态示意
  • 各种满级状态
  • 有各种限制条件时的状态
    • 未解锁的关卡、未学习的技能等
  • 一个流程各个阶段的状态,例如
    • 装备打造:未选装备、选中装备、打造中、打造完成后。
  • 一个系统内不同时间阶段的不同状态
    • 华山论剑:比赛开始前、准备时间、战斗中、一轮结束下一轮开始前、整届比赛打完等。
华山论剑系统的状态,结合了不同的视角.png

5 操作/事件

  • 考虑每一个界面元素、控件,是否有主动操作或触发事件。
  • 玩家主动通过鼠标与键盘发起是主动操作,
  • 程序上满足特定条件时自动触发的是触发事件。

5.1 主动操作

5.1.1 鼠标操作
  • 悬停
  • 悬停时,可点击元素都需要有hover态
  • 需要更详细说明的元素(头像等图标、不完整的文字等),显示出hint提示
  • 单击
  • 注意时鼠标松开时才触发,对新手客户端程序员,文档里可以额外提醒一下:“release时触发、而非down”
  • 双击
  • 有双击操作时,要特别注意对该元件单击事件的屏蔽,通常是给单击事件加延时(0.1s)触发。
  • 拖拽
  • 注意设定拖拽触发的最小距离(约8px),以免在单击时不小心触发
  • 注意考虑落点判断规则,是以为鼠标指针进入目标区域、还是拖拽元素整个或部分进入目标区域
  • 长按
  • 购买商品调整数量时,通过长按操作使数字快速变化
  • 除了上述这种在游戏、软件中已经习以为常的操作方式,尽量避免使用长按
  • 滚轮
  • 一般不用特别说明,可以滚动的地方程序还是知道的
5.1.2 键盘操作
  • 主要为ESC(关闭界面、取消操作)、Enter
  • ↓←↑→方向键移动
  • 其他一些快捷键

5.2 触发事件

  • 触发事件的结果反馈,在设计时往往容易忽略,需要特别注意
  • 被动/自动触发的一些事件
  • 在倒计时结束时
  • Calendar(控制各种系统开启、关闭、持续时间的一个总控系统)触发时
  • 其他一些自动行为完成时

6 Hint

  • 列出界面中所有需要Hint的地方,包括一个Hint的不同状态
  • 如果与现有的Hint格式差异比较大,需要让美术也提供新的效果图
  • 特别注意在新加物品类型时,要考虑对应的物品Hint是否要重新设计。
  • 例如图纸类物品Hint需列出图纸的材料,宝石类物品Hint列出宝石属性, 尽量避免全靠策划手工填写在说明字段里,低效且易出错
宝石类物品Hint

7 关联界面改动

  • 需要考虑一个系统是否会影响到其他系统的界面,常见的有:
  • 战斗相关界面
    • 设计战斗的系统,都需要考虑战斗界面是否需要改动,例如

世界BOSS系统需要增加额外的BOSS血条模式
多批次战斗需要增加批次显示

  • 尤其是一些在战斗规则本身可能没有特殊变化的系统,但涉及战斗的系统,也要考虑一下整个战斗的过程,例如

切磋系统的战斗结算框需要考虑平局的情况
华山论剑系统需要考虑观战界面以及观战时结算框
擂台系统的连胜buff,需要在战斗界面里显示
跨服系统需要在玩家名后加上服务器标识
不让跳过战斗的系统,跳过按钮要灰显或是隐藏

  • 角色界面
    • 新增的主将/侠客养成系统,需要考虑是不是要在角色界面增加入口
    • 如果增加了入口按钮,还要考虑自己角色界面和查看他人界面的规则差异
  • 其他养成界面
    • 在新增渠道系统时,需考虑下是否需要在该渠道关联的养成系统中增加关联的渠道入口
    • 备战/实力比较
      • 新增养成系统时,都要对应的增加
  • CDbar
    • 一般为每日有多次、且有CD限制的渠道类系统,都需要考虑一下
  • 飞入提示
    • 每个系统多考虑一下,有没有什么重要的提示。

8 控件使用

8.1 复选框&单选框&下拉菜单

复选框&单选框&下拉菜单
  • 可以同时选择多个选项时,毫无疑问是使用多选框
  • 当选项只有两项,且是两个相反的值时,也使用一个复选框

例如 使用/不使用、开启/关闭,这种两个相反的选项时,使用一个复选框

  • 使用银两/使用元宝,这种并非相反的值时,则应使用2个单选框选项
  • 同时只能选一个选项时,使用单选框
  • 下拉菜单通常作为单选框的一种变种
    • 如果选项数目不固定、选项数目比较多,或者界面空间有限时,用下拉菜单代替单选框

8.2 按钮&超链接

按钮&超链接
  • 超链接和按钮能的功能几乎是相等的——点击执行操作。区别只是在于表现形式上。
  • 示意图中应考虑何时使用按钮、何时使用超链接。而不能都用按钮、完全让美术去决定。
  • 通常情况下,按钮代表是更核心的主要功能;而超链接则相对次要一些。

8.3 可编辑的文本框&普通文本

可编辑的文本&框普通文本
  • 大多数情况下,用到的都是普通文本
  • 只有在那些需要输入、可编辑地方,才会使用到可编辑的文本框
  • 在示意图中,不能为了表现文字有背景、或是其他目的,随意地使用可编辑的文本框控件来代替普通的文本。

9 界面文案与字体

9.1 文案

  • 精简:尽可能简短,去掉多余的、修饰性的文字
  • 准确:描述清楚,避免错别字
  • 情感:用玩家的语言、不要用程序员的语言
  • 统一:除了名词统一,还要各种符号、大小写、半角全角等
  • 设计:利用好文字,它也是界面设计的一部分
  • 如果界面很空,可以考虑用一些说明性文字作为填充
  • 某些情况下字数统一可以使得界面更整齐(中文汉字更能发挥这点)
仅修改文案字数的改变

9.2 字体

9.2.1 Size&Family
  • 程序支持的无锯齿字体为:宋体12、宋体14、宋体16、黑体18
  • 不便于用艺术字的地方,都应采用上述几种字体
9.2.2 Color
  • 示意图中的文字一般不用彩色。但在表达以下含义时,需使用对应的颜色
  • 说明文字:绿色
  • 错误提示文字:红色
  • 超链接文字:蓝色
  • 随品质变化的文字:紫色

10 其他通用设计标准

10.1 搜索框

  • 搜索框中需要有默认文字,默认文字使用不同的颜色(灰色)
  • 默认文字根据不同的搜索框有所不同
  • 当搜索框获取鼠标焦点后,清除默认文字,等待用户输入文字。
  • 若用户没有输入任何文字时失去焦点,则文本框中恢复默认文字
  • 若用户输入文字后再失去焦点,则文本框中依然显示用户输入的文字

10.2 可排序表格

  • 对于可以排序的表格列,
  • 列标题需可点击,且有3态效果。
  • 根据当前排序状态显示正序或逆序的图标
  • 若有多列可排序,则排序时需考虑所有列的排序规则,最后点击的列在排序中拥有更高的优先级。例如
市场界面商品列表.png
  1. 默认: order by 总价 ASC,...sortid
  2. 此时先点品质:order by 品质 DESC, 总价 ASC,...sortid
  3. 再点 单价:order by 单价 ASC, 品质 DESC, 总价 ASC,...sortid
  4. 再点 总价:order by 总价 DESC, 单价 ASC, 品质 DESC,...sortid

10.3 日期&时间

  • 默认的日期显示格式,统一为YYYY-MM-DD
  • 用四位数表示年、两位数表示月和两位数表示日的。日期部分以连字符 (-) 分隔。
  • 默认的时间显示格式,统一为HH:MI:SS
  • 用两位数表示小时、两位数表示分钟和两位数表示秒。时间部分以冒号 (:) 分隔。

√应该用 2013-08-01 12:45:01
×而不是 2013-8-1 12:45:1

10.4 倒计时

10.4.1 完整显示
  • 完整显示“时”、“分”、“秒”的倒计时格,统一为H:MI:SS
  • 可根据实际的设定情况,确定倒计时中是否需要“时”、“分”
10.4.2 分阶段显示
  • 若倒计时受到界面限制,可根据剩余时间显示不同的精度
时间段 显示格式1 显示格式2
小于1分钟 剩余N秒 剩余0分M秒
小于1小时 剩余N分钟 剩余N分M秒
小于1天 剩余N小时 剩余N小时M分
大于1天 剩余N天 剩余N天M小时

10.5 消耗显示

消耗显示
  • 尽可能将操作消耗直接列在按钮旁,已列出消耗数目的操作,一律不要消费确认提示。
  • 消耗货币时,显示格式为:货币名称×货币数量
  • 满足是用白色,不满足用红色
  • 点击货币链接,打开货币来源界面
  • 消耗物品时,显示格式为:物品名称×消耗物品数量(剩余物品数量)
  • 物品名称为品质色
  • 括号内的剩余数量,满足用白色,不满足用红色
  • 点击物品名称链接,打开物品来源界面

11 相关美术需求

11.1 动画需求

  • 主要指操作反馈动画、界面之间的切换过渡动画。
  • 如果在设计示意图的同时,就已经想清楚了相关动画,需要提前跟UI先说明、并且在UI制作过程中注意检验。以免由于UI布局的变动导致原先的动画模式不适用,
  • 如果一个界面的动画非常依赖实际的UI表现,可在UI设计之前先大致列出哪些地方需要有动画来强调或是过渡,让UI设计时可以一同考虑。

11.2 图标

  • 界面中涉及的图标,如果在交付程序开发时,UI来不及完成全部图标,需要督促UI先提供一个临时的版本以供程序制作
  • 临时版本的主要目的是确定图标的尺寸、以及制作方式
  • 比如是否需要程序叠加颜色、裁切等

11.3 其他美术需求

  • 原画、场景、3D模型等
  • 由于这类美术资源制作周期较长,务必尽早提出

12 最后

指南更多只是一种参考思路,只要有你的理由就可以打破常规

更多我在「游戏/交互设计」副本中的捡到的战利品

Design Thinking
Web note ad 1