一、概述 游戏中角色移动分为了主动和被动，主动主要由玩家通过摇杆或者键盘进行操作，被动移动主要应用于自动寻路，通过寻路点行动。 二、主动移动 移动组件 移动组件主要用到Unity的移动组件Character Controller，主要属性如下 Height角色的高度，通常和现实中的人物一样设置为2米左右。 Radius角色的半径，用于控制人物的胖瘦。 Center设置角色中心点的位置。 Slope Limit限制角色能爬的最大坡度。通常设置为90度以下，这样角色就不会走到墙上。 Step Offset移动步长。通常2米左右的人移动步长设置在0.1到0.4米. Skin Width皮肤厚度。如果这个值太小角色容易被卡住，太大角色容易抖动。通常将这个数据设为0.01到角色半径的10%之间。 Min Move Distance最小移动距离。官方推荐把这个值设为0。 isGrounded可以获取角色当前是否在地面。 velocity可以获取角色当前的速度向量。 移动方法主要用到Move，Move方法需要自己实现重力的效果，看具体项目需求 //用摇杆控制方向，当按下空格键时跳起。 using UnityEngine; using System.Collections; public class ExampleClass : MonoBehaviour { public float speed = 6.0F; public float jumpSpeed = 8.0F; public float gravity = 20.0F; private Vector3 moveDirection = Vector3.zero; void Update() { CharacterController controller = GetComponent<CharacterController>(); if (controller.isGrounded) { moveDirection = GetTargetPos(nowPos) - nowPos; // 跳跃 if (Input.GetButton("Jump")) moveDirection.y = jumpSpeed; } //Move方法需要自己写重力效果 moveDirection.y -= gravity * Time.deltaTime; //移动控制器 controller.Move(moveDirection * Time.deltaTime); } } 每帧目标点的计算 速度模拟模拟现实中人物移动的特征，起步时加速，计算代码如下 Vector3 GetTargetPos(Vector3 pos) { //计算实时速度，addSpeed为加速度 curMoveSpeed = Mathf.MoveTowards(curMoveSpeed, MaxSpeed, addSpeed * deltaTime); //计算终点，curMoveDir由输入决定 pos += curMoveSpeed * curMoveDir * deltaTime } 动画状态机 移动时需要动作配合，动作主要由Animator组件实现，通过设置不同的参数，实现状态之间的转换，还可以细化，加上准备跳跃，跳跃落地等等。 通过SetTrigger进行不同运动状态的切换，通过SetBool进行移动和静止状态间的切换。 管理组件 主动移动的管理组件主要功能如下 接收输入方向 状态机维护当前角色状态（普通，跳跃），设置对应动画状态 计算下一帧移动方向 三、自动寻路 自动寻路主要是计算出起始点到目标点的一连串的中间点，每次走一小段直线，从而完成寻路的过程，逻辑比较简单， 如果使用Unity自带的Nav Mesh Agent 可以使用参考https://bbs.huaweicloud.com/blogs/303788。 计算寻路点 计算寻路点主要用到Unity的NavMesh类中的CalculatePath方法，得到寻路点以后只要逐个进行寻路即可。 ...

概述 一般副本中都会包括各种各样的行为和判断逻辑，下面举一个简单的副本例子，进入副本后，如果组队人数到达三个，则刷出怪物，播放特效，播放对话，与怪物战斗后，弹出结算UI，再播个动画。 如果由策划出完案子后程序负责直接实现的话，每个副本都是定制化的，写起来非常难受，而且维护极不方便，一旦需求改动就要重新写代码 所以需要设计一套副本系统可以灵活配置副本功能，想法是把副本里的每个行为，判断都作为一个节点，类型行为树的概念，从开始节点一直执行到结束节点，这个副本进程就结束了，进入下个副本进程。 编辑器使用连线的方式操作，每个节点的前后置关系，导出lua配置供程序使用，服务端控制执行流程，客户端只需要执行节点逻辑。 例子 节点可以分为执行节点和判断节点，执行节点执行一个行为，流程推进，判断节点在符合条件的时候，推进流程，否则暂停。 端口定义了每个节点间的关系，也就是图中的连线，控制流程走向，比如刷怪战斗节点，输入端口连接“判断组队人数”，有两个输出端口，分别是胜利和失败，连接对应的节点。 把副本流程解构成一个个节点以后，只需要维护节点的行为和端口逻辑即可，组合由策划完成，只有在添加新节点时程序才需要上场。 编辑器 编辑器可以用网上的开源例子xnode组织节点，也可自己实现。 导出的数据包括了节点的类型，参数，前后置节点等一切代码需要的信息。 副本流程 服务端推送当前节点信息 服务端执行/客户端执行 服务端/客户端完成节点，推进流程 直到到达结束节点

一、概述 一般MMO的游戏由场景和场景中的对象构成，在设计地图时，就会遇到几个问题。怎么有效直观地配置信息，对象都有什么功能，有什么功能是共有的。针对上面的问题，首先需要解决的是抽象出场景对象结构，在此基础上做编辑器，用图形化的界面展示，修改储存数据，供代码使用。 二、场景对象结构 场景本事有数据，如场景资源，组队人数限制等等，这种信息改动不大，也比较直观，一般只要存在excel里面就好，需要的话可以做图形编辑器对excel进行读写和修改。 场景中的对象可以按需分成几类，常见的有npc，采集物，区域，点等等。 NPC NPC主要承载了显示模型的功能，读取NPC表。 采集物 采集物和NPC差不多，只是对话交互改成了点击采集。 区域 区域分成了圆形区域和多边形区域，划分区域可以实现进入和离开区域的逻辑，比如划分了游泳区，飞行区等，进入以后主角切换运动状态。 点 点的功能比较广泛，主要用于定位，也可以添加触发组件以后实现圆形区域的功能。 组件 组件是对象上的属性和功能，公用的组件有缩放，大小，显示隐藏条件等，特殊的组件有巡逻，交互按钮等，按需添加，从而赋予对象特性。 三、场景编辑器 理清了场景对象的结构以后，就可以做编辑器把数据组织起来了，场景编辑器的实现细节不多说，尽量用起来符合直观操作即可，功能如下。 增删改场景信息 直观展示场景中的对象（位置、模型、范围等） 增删改场景中的对象 修改对象的组件属性 导出程序可用数据 四、数据载体 数据可以直接导出lua，也可以导出成json，xml等，只要方便维护，程序方便调用即可。 目前使用的是先储存到excel，再从excel导出到lua中，供程序调用。 使用excel作为中间载体的原因可能是比较直观，但感觉使用json或者Unity序列化的方法也是可行的。

概述 游戏对象管理一般是通过总分结构，管理器为RoleMgr，对象为Role，Role的功能由各种功能组件实现，从而实现继承和解耦。 RoleMgr 管理类管理游戏中所有的Role，负责Role的创建、查找、销毁，一般配合UID生成器，给每一个Role分配一个唯一ID作为唯一的标识。 Role Role是游戏中的对象，可以是角色，特效，建筑等等游戏中的一切实体，由BaseRole派生。 BaseRole 基类，定义Role的最基本信息，如GameObject，Transform信息，显示隐藏状态等等。 派生 对BaseRole进行派生就是具体的游戏对象，如添加了控制器以后就是角色，再添加主动移动的控制器以后就是主角，通过绑定不同的组件实现Role的不同方向功能。 Role的功能 Role的功能都由挂载的组件实现，常用的组件有 模型组件 被动移动组件 主动移动组件 显示隐藏组件（多条件） 范围触发组件（当玩家走进时会触发回调） 头顶文本组件 还有各种项目中需要实现的功能 Role的结构

前言 UI是游戏中很重要的一部分，工作大多是繁复的，所以有一套功能强大，操作简单直观的UI解决方案是非常有必要的。 上半年一直在用FGUI，和之前用的UGUI相比下来，各有优缺点，对比分析记录一下。 一、介绍 UGUI UGUI是Unity原生提供的UI方案，提供了基本的UI组件，如图片，文本，按钮，复选框，进度条等等，正是因为UGUI是面向普遍开发，所以没有封装很多高级的组件，比如虚拟列表。 FGUI FairyGUI（下来简称FGUI）号称易上手，直观，零代码，有一个独立的编辑器，封装了很多高级的UI组件，用起来不需要自己造轮子。 二、编辑器使用体验 UGUI 优点：稳定。 缺点：因为集成在Unity中，资源管理不太方便，需要项目定好规范，编写工具提交效率。 FGUI 优点：有单独的编辑器，所有资源统一管理，美术策划也能很快上手使用。 缺点：不稳定，经常会莫名卡住，导出的时候经常报错。 三、基础组件 基础组件上面因为FGUI实现很多的高级功能，所以使用起来体验要么一样，要么好点。 文本 FGUI文本支持ubb语法，富文本支持图文混排，超链接等等，自动大小的文本。 列表 FGUI实现了虚拟列表，树列表。 字体 字体上FGUI提供了工具制作美术字，只要把资源拖进去专用的编辑器就能很快做出一个美术字体。 动效系统 两者都有动效系统，UGUI上叫Animation，功能上差不多，都很强大。 四、对齐系统 对齐系统这一块，FGUI是很大的亮点。 UGUI UGUI的锚点系统以中心点为基准，对父节点对齐，提供了上下左右，拉伸对齐方式。 **优点：**简单直观UI默认的中心点在中心，符合人的正常思维。 缺点：不够灵活；同级UI之前的关联对齐要依赖其他布局组件；缺乏针对同级元素的对齐工具，不过可以自己拓展实现，可以参考我的另一篇文章。 FGUI 优点：FGUI的对齐系统叫做关联系统，第一个优点是不局限与与父节点对齐，可以对任意两个元素进行对齐。第二个优点是在拓展了对齐的维度，可以以上下左右边缘为基准，可以以上下左右为基准拉伸，复杂一点，但是学会以后可以很方便实现一些效果，比如一张图片随着文字的变长而往右移动。 缺点：垂直布局和水平布局功能太单一；锚点在左上角各种反人类。 五、FGUI特色功能 资源引用查找工具 可以轻易找到组件（图片）和其他组件的引用关系。 支持多国语言 原生支持多国语言，可以导出xml维护即可。 控制器系统 控制器系统一般用于控制显示一些UI元素的状态，可以配合动效和Tab使用，UGUI一般要通过代码控制或者自己实现一个类似的系统。 多平台 FGUI可以一套UI，应用到不同的游戏引擎去，比如Unity和Unreal，对于后期可能更换引擎的项目，节省掉很多成本。 插入3D物体 支持在UI层中插入任何3D物体，例如模型、粒子、骨骼动画等，UGUI中要通过修改特效和UI的渲染顺序实现，比较麻烦。 六、拓展性 两者都有拓展性，FGUI的拓展性在于代码是开源的，可以在底层定制适合项目的功能，但是编辑器是不开源的，所以编辑器里面的东西改不了，虽然编辑器提供了脚本拓展支持，但能实现的东西不多。 UGUI的拓展性在于可以轻松地对编辑器进行拓展，也可以加上各种效果，一般也不会动到底层的如网格重构和渲染的代码，真想修改的话可能要和Unity进行合作然后项目搞一个魔改版的Unity。 七、总结 总的来说两种UI解决方案都可以商用，不会有特别大的问题。 要是策划美术拼UI的话，可以选择FGUI，相反要是程序负责的话，两者都可以，但个人感觉Unity上的操作更加熟悉一点，程序员也可以在平时的UI流程中，吸收一些FGUI的思想，做些工具提高UI的开发效率。