页游项目设计指南分享

作者: 卡拉赞图书馆 | 来源:发表于2016-08-10 18:02 被阅读318次

    指南来自之前一款页游项目,代号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 最后

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

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

    相关文章

      网友评论

        本文标题:页游项目设计指南分享

        本文链接:https://www.haomeiwen.com/subject/qrrrsttx.html