欢迎参与讨论，转载请注明出处。

前言

　　DFQ终究是顺利的开发完成，并在发布之后的短短四日内达到接近十万的下载量。赢得广大玩家的好评，甚者认为比之官方的手游品质更佳。然而这一切恍若黄粱一梦，于昨日晚上收到了来自腾讯的律师函，要求删除相关下载渠道与宣传内容。
　　取得这等成绩自是喜人，能被腾讯警惕也证明品质确实出色。只可惜游戏尚有一些待完善之处，无法再为玩家提供更新了。在此期间也有不少请求换皮合作的邀请，但本人志不在此。也不想讨论相关太多，就来为这个项目做个总结吧。

程序

　　关于制作DFQ的想法，在《阿拉德英雄传》3.0搁置以后便有了模糊的想法。认为要做一款简洁爽快的中小型DNF同人手游，作为我、以及开元的DNF同人最终章。但随着增长了见识以后，便发现自己的程序架构掌控力不足，于是花了不少时间恶补。且前期对于要做一款怎样的游戏并无清晰的概念，遂直到2018年6月才正式开始制作。
　　由于DFQ算是弥补3.0搁置的一个执念，于是依旧选择了LÖVE引擎。事实上这是个重大的决策失误。LÖVE关于移动端方面的功能只是刚刚推出，且是冷门引擎，没人帮忙踩坑。于是在制作时便遇到了很多问题，包括相关库的缺少或不合适以至于要造轮子、引擎本身的BUG之类等等。在发布之后更是遇到了诸多问题（NO GAME、全面屏、DPI等），在此奉劝各位，不要用冷门引擎。
　　说回程序本身，这次基本上是达到我的要求了，至少工程不再是一塌糊涂、难以协作的状态了。对于各种方面的写法问题也有过深刻的研究（如活动对象采用ECS架构），对于代码格式与写法也有了规范。不足之处在于状态的业务按理来说应该配置化，而非OOP，因其存在大量相似而不同的业务，而这些部分是难以用OOP解决的。以及在OOP的规范上，我引入了private（以_前缀表示），然而会发现很多时候这只会增加不必要的思考负担以及封装成本，这方面该如何处理其实至今我仍未有答案（在业界也是众说纷纭）。
　　为了弥补Lua没有强类型与智能提示的缺点，我引入了EmmyLua。所以看过之前的开源工程的会发现代码会有形如---@class XXX的注释，不过这种外挂的形式终究不如原生来的爽快，且缺乏运行前检查的功能。对于代码健壮性的建设尚嫌不足，由此可见TypeScript才是究极的工程化脚本啊。
　　在后续测试的图中遇到过一次严重的内存泄漏事故，基本上刷到第三个地下城时便会内存膨胀到难以接受的地步。通过使用LuaMemorySnapshotDump发现，由于我为了减少内存申请，会将一些固定的table类参数写成模块变量，而使用后却没有及时清空，导致游戏对象一直依附其中，无法回收。以及为了优化而做的对象池也是如此，真是汗颜。

美术

　　美术方面可以说的不多，首先是由于因需求做了个粒子编辑器，导致对粒子效果的掌控力上升。游戏的粒子特效使用率较之《阿拉德英雄传》有了大幅的提升。
　　在人物素材方面，实现了非常强大的纸娃娃，并且为了效率优化，纸娃娃是拼合成一张大图的，缺点在于合成相当耗时，需要在恰当的时机进行（如读图）。并且部分设备支持的图片大小最高为4096，而实际上则出现了超过该大小的图片（此问题至今尚未修复）。
　　在优化方面，由于引入了图集与压缩的措施，游戏的加载速度与显存占用是得到了极大的提升。在尚未采取压缩之前，小米9会出现显存带宽爆炸的情况。可以说安卓设备五花八门，令人十分头大。
　　UI方面，立绘依旧是小山龙同志的作品，质量较之当年可谓进步明显，原本打算采取live2d的方案，却因工期延宕而搁置了，实是一憾。至于界面本身，可以看出对于手游而言，连及格都称得上是勉强，实是因为一版过兼无经验所致。
　　手游UI与端游UI的不同处在于，由于屏幕太小，实际上UI要做的很大才显得正常。并且由于有着触控的需求，按钮也必须大且位置合适。如果为了美术效果而做得小，那也得必须要求附近无其他冲突项，且实际可触控范围要比素材看起来大才行。

游戏性

　　DFQ的原初想法实是一款刷刷刷的类暗黑游戏，但本人感觉这年头的游戏都过度强调养成了。遂在砍掉养成的前提下重新审视，定下了三国战纪+Roguelike的主基调。三国战纪的元素在于：角色扮演、街机闯关、拾取道具，Roguelike则是随机性了，可谓独立游戏时下的流行元素，当然大家不约而同选择Roguelike的原因很简单：游戏内容不足，所以要用随机性来增添耐玩性。这么一组合起来，DFQ的样子便很明显了：开局一把刀，一切全靠打，随机地图事件，横版街机闯关。
　　但是仅仅如此还是不够的，要是玩家一直用着一成不变的搭配进行游戏，那可就太浪费了。传统游戏对于此的解决方案有：上下级替换、针对性关卡替换，然DFQ没有条件搞上下级替换，针对性替换也未免苛刻。于是抄袭《塞尔达传说：荒野之息》的武器耐久度设定，让武器、道具、技能都具有轮替性。这份轮替性对于玩家而言实是辛辣了，以至于赢得不少吐槽。在后续版本中便为此做出了调整优化，但实是最佳之法。关键在于：玩家需要自己感到可控的设计，而非稀里糊涂的机制。DFQ在不少方面都有类似问题（如最初设想的动态难度），实该检讨。
　　在关卡设计上，DFQ是以传统游戏的标准进行设计的，做出了不少较之DNF的突破（如跨房间追击战、迷宫等）。在开发前期犯下一个严重的错误：以端游的标准去做手游，以至于难度过大。手游的操作成本比端游要大，以及更适合轻度的体验。传统的DNF操作方式并不够爽快，遂在此基础上加入了小技能可互相强制、普攻可减少技能冷却的设计，让整个游戏的体验如打了肾上腺素一般。
　　除此之外，在做《阿拉德英雄传》多年以来，落下不少错误的思想，如怪物的攻击频率相当鬼畜、没有合适的前后摇等。虽然较之当年，我的ACT设计理解有所提升，引入了反击元素，但仍是不足。在小草泥马的一番军训后，引入了紧张时间与舒适时间的概念，领悟了张弛有度的道理。怪物的设计上会做出提供玩家利用的破绽，让战斗的体验达到了业界平均水平（指国际）。

宣传

　　在此感谢轻声低语、瓦伦、夕阳飘羽三位同仁的协助，在DNF百度贴吧、COLG等处得到了极大的曝光，也感谢纷纷去安利、自发宣传的玩家们，以此得到了广泛关注。取得了下载量近十万、B站宣传片十三万播放、贴吧关注量近七千、群人数两千七、COLG帖子47页的成绩。
　　另外意想不到的是，以前《阿拉德英雄传》的玩家群体的活跃度也很高，并且开元工作室的名声也比想象中要大（不少人都知道，包括DNF吧的吧务），可见以前做下的成果也是有回报的。
　　其实在我看来，比较核心向的游戏，只要你知道受众的聚集地，并且有相关号召力的人士愿意帮忙。在赢得了核心玩家的认可下，宣传效果是非常棒的，哪怕远在韩国的好船同志也收到消息并通关了。这点和业界从广泛人群中捞玩家的买量游戏还是有所不同的。

后记

　　其实DFQ的成功，除了本身品质的优秀之外，更在于官方手游迟迟未发，当然最近又有动作了，这也算是撞枪口上了吧。且DFQ属于手游里少有的偏传统的单机类型，在玩腻了抽卡养成流水关卡的玩家看来，自然是十分闪耀的。而我之所以拒绝那些合作换皮的邀请，也在于我并没有想过符合游戏的商业化改造方案，如果按照市面上的那一套进行，结合下一次的天时地利人和，感觉迎来的只会是暴死吧。
　　经过这次的验证，可以见到我的ACT理解程度已经进入了新的台阶，然而这还不是我所能做到的极限，若有机会一定会再次整活。当然同人游戏是不会再做了，这次已经是撞倒了天花板，在各方面有其局限性。

　　欢迎参与讨论，转载请注明出处。

前言

　　DFQ是PVE（Player VS Environment）游戏，那么自然要有AI了。DFQ的AI实现并不算复杂，并没有用到时下流行的行为树（Behavior Tree）。原因在于不需要做到太精细的操作，且AI部分的业务不需要执行策划参与（不需要编辑器化）。本文将一一叙述其中要点，相信对于同类型的游戏也有一定的参考价值。

宗旨

　　AI设计的宗旨只有一个：根据游戏的各种情况，决定进行怎样的操作。这样的思路其实挺仿生的，我们玩游戏的时候本质上也是如此。要注意的是，玩家进行操作的方式是通过外设（键盘鼠标手柄触控等）输入操作信息（按键坐标等）。从这点来说，AI也可以这么做，以进行虚拟的输入操作。这么做的好处是很明显的，如此AI与玩家在功能上达到了一致，AI也不需要与某个具体的功能耦合，只需要关注相应的操作指令，无需关注具体的功能实现。
　　而这一切只需要做一套操作模块即可，并且做联机时来自其他玩家的输入亦可如此处理，通过这种方式达到了玩家、AI、联机三者的有机统一。可谓「软件开发中遇到的所有问题，都可以通过增加一层抽象而得以解决」的一次实践。
　　当然这也会引入新的问题：某些功能只想AI拥有，那该怎么办？DFQ中的非转向移动便属于这类，解决方法很简单：设计一个玩家无法触发的操作指令即可。

对象

　　AI的实体存在就是个类对象（下文称AI对象）而已，它会被外部调用的基础函数只有两个：Update和Tick。Update用于处理持续性的业务，而Tick则是一次性的业务，当然两者可能会有所结合（Tick接收参数，以驱动Update的运作）。
　　AI对象主要会存在的场合有：常驻（移动和攻击）、技能（判断是否应发动）、状态（某些状态下需要后续的操作），通过配置化的方式，即可灵活的组合需要的AI了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

return {
    script = "base",
    state = "attack",
    ai = {
        script = "battleJudge",
        collider = "duelist/goblin/skin/3-attack"
    },
    attackValues = {
        {
            damageRate = 1,
            isPhysical = true
        }
    }
}

　　如上配置所示，这是个技能的配置。在AI部分选择了battleJudge类，并提供了用于判断范围的collider参数。如此便定下了该技能的AI方针：使用collider判断是否存在敌人，存在则按下技能对应的按键，以发动技能。

实现

　　说完基本构成后，再来说说一些具体AI业务的实现吧。

• 移动：移动AI的核心构成有三
  • 获取目标：遍历符合条件的对象，涉及到阵营等因素。
  • 寻路：以目标为终点展开的寻路，由于DFQ使用的是网格地图，所以使用A星之类的寻路算法即可。
  • 输入操作：获取到移动路径后，通过发出输入指令以驱动角色以之移动。要注意的是，这种方式不可能做到完全贴合路径，所以出现了超过了路径点的情况也不会作处理。
• 攻击：攻击AI要做的事情很单纯，遍历技能以Tick它们的AI对象进行发动而已。要注意的是，技能的使用顺序要建立优先级进行排序。
• 判定：这个判定，便是上文的battleJudge了，通过collider以判断目标是否存在。这里的collider便是先前打击感所言的立体矩形，如下图所示：
  

　　以上便是DFQ里值得一提的AI业务。顺带一提的是，AI是典型的不需要立即生效的业务，所以可以考虑每帧只执行一个单位的AI业务，以此减缓性能压力，并且避免敌人一窝蜂展开攻击的现象。

后记

　　在本文开篇时，输入AI二字的我其实有点恍惚。短短数年，AI几乎成了深度学习/机器学习的代名词了。在游戏领域一个理所当然的缩写反倒让我踌躇了一瞬，真是唏嘘啊。也许以后的游戏AI真的都成了基于强化学习的实现也说不定呢（笑。

　　欢迎参与讨论，转载请注明出处。

前言

　　对于动作游戏（本文所谓的动作游戏具体指由FTG衍生而来的「超人系ACT」，如鬼泣、猎天使魔女等）而言，打击感自然是重中之重，本篇就来讲讲DFQ的打击感实现思路吧。
　　首先要明确打击感的定义，本人将之定义为：攻击命中时产生的反馈。就这点而言，打击感并非是动作游戏的专属，凡是涉及到攻击交互的游戏都有。而动作游戏与之不同在于会对在攻击中附加控制效果（击退、击飞等），使得动作游戏成为了围绕打击感展开操作的游戏。
　　而DFQ的打击感基本源于DNF，在此基础上加入个人的理解，接下来便一一讲解其中构成。

判定

　　在产生攻击命中之前，自然得讨论如何触发了。众所周知，动作游戏讲究「所见即所得」——必须是看上去击中了，才算是命中。所以自然要使用一些方式去近似地模拟素材的边界范围，以此进行碰撞判定。而DFQ的做法则相当粗暴——直接构建一些近似的矩形，当然这矩形却不一般：

　　如图所示，人物拥有两种颜色的矩形，其中白色矩形表示人物的X-Z轴矩形，红色矩形表示为X-Y轴矩形。与一般的无纵深横版游戏（冒险岛、胧村正等）不同，DFQ这类可进行上下移动且滞空的横版游戏（DNF、三国战纪等）会去构造一种「逻辑上的三维空间」：

　　当然实际上可以直接使用3D矩形（立方体）进行构造，只是2D图形下不便表示，于是分解为两个矩形进行。自然地，判定时也是红对红、白对白。至于判定算法，由于DFQ没有太精细的需求，矩形不会参与旋转变换，故直接使用AABB即可。

击退

　　话不多说，直接上图：

　　击退是打击感中最基本的元素了，当然将之命名为击退只是个人行为，在业界它有着各种各样的称呼，如stun、硬直、僵直、気絶等，在此一提。
　　由图可见击退有两种不同的姿势（为了表现的丰富度），敌人会保持被击姿势一段时间，且变速位移一段距离。以函数的形式表示便是stun(time, speed, acceleration)，time表示保持姿势的时间，speed为位移的初始速度，acceleration为速度的衰减值（也可以是加速值），通过acceleration来每帧减少speed，以此实现简单的变速运动效果。当然speed与acceleration并非是必须的（不带位移的击退），但time则必须有（无time不stun）。

击飞

　　同样，直接上图：

　　与击退同样，击飞也属于动作游戏里最核心的控制效果之一，它的别名也很多，如flight、击倒、倒地、浮空等。
　　击飞这种控制效果在最初只是作为一种动画表现手法而已，一般用于敌人死亡、某些想表达击飞的招式等。敌人处于击飞动画时一般无法或难以继续进行互动。将之发展的据说是CAPCOM开发《鬼武者》时触发的一个BUG——敌人处于击飞时被后续攻击而产生了滞空效应。从此一发不可收拾，铸就日后《鬼泣》皇牌空战之名。
　　而DFQ身为2019年的游戏，自然不可能落后：

　　以上两张图基本可以窥得击飞之全貌了：

• 击飞在状态上可分为上升、下落、倒地，上升与下落都会进行类似击退的变速运动，且根据进度改变姿势。
• 姿势内容为击退的两个为基础外加它们的90度旋转版本及倒地。
• 在击飞时被攻击会切换姿势且保持滞空一小会，形成了浮空连击的效果。
• 除此以外便是X轴的位移效果了，这点与击退一致。
• 倒地会根据浮空高度结算出「再击飞」，画面表现上为落地弹起，若高度不足则直接倒地。

　　与击退类似，击飞的基本函数形式则是flight(speed_z, speed_x, acceleration_z_up, acceleration_z_down, acceleration_x)，参数含义与击退类似，不再阐述。一般而言acceleration_z_up与acceleration_z_down会选择默认值，speed_x与acceleration_x则为可选项，但speed_z必须有（无speed_z不flight）。

特效

　　继续上图：

　　特效其实没什么好说的，如果说动作姿势是描线，那么特效便是上色了。需要注意的是特效出现的位置一般得是矩形碰撞的交点处，这样才有「打中这个位置」的感觉。
　　特效的种类一般就是斩、打、突、气四类（利器、钝器、锐器、魔法），外加出血之类等等，多多益善。
　　顺带一提的是，由于特效算是一种创建销毁十分频繁的对象，值得为之做对象池以减少创建销毁的开销。

声音

　　这下上不了图了，毕竟声音的可视化形式一般人类都看不懂（笑。
　　由于打击感是攻击命中时产生的反馈，而反馈的形式自然不局限于视觉上的，听觉也相当的重要。当然这里讨论的声音可不仅仅是攻击瞬间产生的部分，还包括了整个招式过程。
　　一般而言，一个招式基本会包含以下元素：

• voice：如人物发招时的叫声，播放时机不限。
• swing：如人物挥剑的声音、特效产生的声音，一般于运动帧时播放。
• hitting：如刀砍到身上的声音，于命中时播放。
• damage：敌人被攻击的惨叫声，于命中时播放。

　　声音这部分在业界不少垃圾游戏可谓是偷工减料的重灾区，实际上万万不可忽视，毕竟有时候效果好不好就靠听个响（代表：拳皇）。

Hitstop、闪烁、抖动

　　这仨放一块讨论是因为他们相辅相成：

　　Hitstop这玩意我对其没有准确的中文词汇，业界一般称为硬直、僵直、卡肉等（可见多容易与击退混淆）。其定义如其名般：因hit而导致stop。表现形式为人物停止运动一段时间，这里的运动包括位移、动画之类。Hitstop是敌我双方皆有的，我称本体的Hitstop为Selfstop，敌方为Hitstop。由此可见，卡肉这个说法其实很恰当，感受起来就像是一下刀卡到肉里了。一般Hitstop的高低可以用于表示攻击的轻重，以及像内功拳法、一闪刀法等延迟杀伤效果也可以通过高Hitstop达成。
　　至于闪烁就更直白了，就是敌人表面有一层纯色遮罩渐变消失。值得注意的是，闪烁的运作也会受Hitstop影响，故在Hitstop期间闪烁是保持初始状态的，看起来敌人就是蒙上了一层白色。这么做可以使得命中的效果更为明显，在业界中《王者荣耀》也采用了这样的表现手法。
　　抖动在图中也许看不太出来，主要就是设定个时间值以及抖动范围（xa, xb, ya, yb），人物在时间内就会随机位移，形成抖动的效果。与闪烁同样，在Hitstop时间是不会流动的，所以抖动与闪烁类似，基本上便是用于加强Hitstop的表现力。在业界中CAPCOM的《吞食天地》也采用了这样的表现手法。

后记

　　以上只是打击感的一些机械的构成，实际上要做好打击感得充分利用许多元素，如场景震动、运镜、符合节奏的连击等。实际上它是一门导演的学问，要想培养就只能多抄多想多做。限于素材与平台，未能表现更丰富的元素，只能有待日后进军3D再说了。

　　欢迎参与讨论，转载请注明出处。

前言

　　随机掉落可谓时下RPG的流行设定，DFQ自然也不例外。而掉落业务自然也有其值得细说之处，不然也就不会有本文了（笑）。接下来将一步步引申出随机掉落的实现演进。

粗劣的实现

　　在以往的开发生涯中，对于掉落业务，我采取了很粗劣的实现：

1
2
3
4
5
6
7
8
9
10
11
12
13

local random = math.random() -- 0-1
local pool -- drop pool
if (random < 0.1) then
    pool = pools.normal
elseif (random < 0.3) then
    pool = pools.rare
else
    pool = pools.other
end
local index = math.random(1, #pool) -- Choice one.
local item = pool[index] -- Get an item.

　　这种实现的槽点可谓数不胜数：掉落池的选取可谓暴力代码，而池中的道具也只能通过塞入相同的多份来扩充概率，对于概率的控制度很生硬。哪怕是将掉落池采取与道具相同的做法（将pools做成list）以去除暴力代码，对于概率控制度的问题依旧没有解决。且进行了两次取随机数，从概率而言并不纯粹。实际效果而言也导致了经常重复掉落，并不可取。

Alias Method

　　那么如果选择将多个掉落池合而为一，使之只有一个list呢？
　　如此确实能让概率纯粹了，但是对于道具概率的控制度依然很差。这个问题可以通过构建道具概率表（{a = 0.1, b = 0.5, ...}）以生成掉落池（{a, b, b, b,...}）解决。但这样生成的掉落池未免也太大了（最后可能会达上千个元素），这太不环保了，那怎么办呢？
　　长达廿二年的人生经验告诉我：我们做的绝大多数事情都是前人做过的，遇到不会的问题看看前人是怎么做的就对了。果不其然，这就遇上了个合适的算法：Alias Method。
　　本文并不打算详解其中的奥妙，这是愚蠢的复读机行为。直接上代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

-- items: A list of probability of item.
function Alias(items)
    local len = #items
    local alias = {}
    local probs = {}
    local small = {}
    local large = {}
    for n=1, len do
        items[n] = items[n] * len
        local tab = items[n] < 1 and small or large
        table.insert(tab, n)
    end
    while (#small > 0 and #large > 0) do
        local less = table.pop(small) -- Remove the first element of list and return it.
        local more = table.pop(large)
        probs[less] = items[less]
        alias[less] = more
        items[more] = items[more] - (1 - items[less])
        local tab = items[more] < 1 and small or large
        table.insert(tab, more)
    end
    while (#small > 0) do
        probs[table.pop(small)] = 1
    end
    while (#large > 0) do
        probs[table.pop(large)] = 1
    end
    return alias, probs
end

　　算法的代码量并不多，也就三十多行，输入参数items为道具的的概率list（{0.1, 0.1, 0.5, ...}），即代表需要配套的paths来表示对应的道具标识（{"stone", "potion", "gold", ...}）。至于返回值alias, probs，先来看看获取随机掉落的代码：

1
2
3

local index = math.random(1, #paths) --- 1-n
index = math.random() < probs[index] and index or alias[index]
local path = paths[index] --- Item's path.

　　以上代码很好理解，首先随机获取一个道具的索引，根据索引获取到probs[index]的值，与随机数（0-1）比较，由此可见probs存放的是一种运算后的概率值。若是随机数大于概率值，索引则改为alias[index]，由此可见alias存放的是一种与原索引相对应的新索引，而新的索引自然会有对应的道具。
　　如此我们便可理解这套算法的做法了：为每个道具设置一个概率值以及相对应的另一个道具，随机到一个道具后，仍需二次随机进行二选一。这么做很好理解，就是将一些高概率的道具填充到一些低概率的道具里：

　　如图所示的第二项紫色的占比（概率）为1，表示不需要进行二次随机了，如此即可保证整个掉落池的概率是可以平分干净的（多出的部分就作为1概率项）。不得不说这种做法十分绝妙，完美解决了先前做法中掉落池元素过大的问题，美中不足在于需要进行二次随机，相对破坏了概率的纯粹性，但由于只是二选一，实际上效果是可接受的。

掉落池的维护

　　虽说Alias Method方案的掉落池配置变得相当容易，只需如此这般填写概率值即可，再分别生成items与paths：

1
2
3
4
5
6

return {
    ["equipment/weapon/sword"] = 0.3,
    ["equipment/weapon/knife"] = 0.3,
    ["equipment/weapon/katana"] = 0.3,
    ["skill/flash"] = 0.1
}

　　然而实际上掉落项的种类与数量都相当的多，并且会时常更改。所以这般直接的配置是无法满足需求的，于是演进为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

return {
    skill = {
        prob = 0,
        item = {
            flash = 1
        }
    },
    ["equipment/weapon"] = {
        prob = 0.9,
        item = {
            sword = 0,
            knife = 0,
            katana = 0
        }
    }
}

　　新配置明显就方便了不少，若是概率填写为0则表示剩余总概率的平均值（sword=0 => 0.9/3 => 0.3），且填写的概率是相对于本层的（skill的总概率为0.1，故flash=1 => 0.1）。算是基于原配置进行了一波封装，可维护性大幅提升，如此便可面对变化频繁的需求了。

后记

　　本文所展示的掉落业务只是基础，在业界会有复杂度远超于此的需求（与时间、职业等因素挂钩，掉落池数量等），但DFQ的需求也仅此而已，期待日后能接触到更主流的设计。

　　欢迎参与讨论，转载请注明出处。

前言

　　继上回在macOS搭建LÖVE for Android平台后，这次买了新的iPhone，对iOS平台的发布自然也要开始了。如上回一般，也发现了不少实操中会遇到的问题，特此记录，以便后人。

实机调试

　　LÖVE for iOS的编译可谓相当容易，前提是你必须拥有一台macOS以及iOS设备，并且安装了Xcode。如官方教程所言般进行便是，大致上就是下载LÖVE源码工程，并且用Xcode打开love/platform/xcode/love.xcodeproj，然后选择love-ios项目、连上iOS设备、设置签名、然后Build就完事了。

　　如上图所示那便是签名的设置了，需要登录Apple账号作为Personal Team，并确保这是iOS设备所使用的账号。

　　签名设置完成无错误提示后，那便如上图所示般选择、执行即可。请确保iOS设备与macOS设备是处于连接状态的，过会便可见到iOS设备已将LÖVE安装完毕。此时尚无法直接运行，需要执行设置→通用→设备管理→Apple账号→信任love。
　　刚装好的LÖVE仍是空空如也，你可以选择打包好一个项目作为test.love，使用Apple的隔空投送（AirDrop）功能进行快速传输，如下图所示：

　　投送完毕后，iOS会精确的识别到这是LÖVE所需要的文件，于是你可以在LÖVE里见到它了，如下图所示：

画面适配

　　我所测试的项目的功能很简单：显示一张图片、该图片会拉伸至窗口大小。直接运行的效果如下图所示：

　　很明显可以得出两个问题：画面并不是水平的，以及顶部的状态栏没去掉。解决它俩的方法很简单，想要画面是水平的，就得在编译设置里进行更改，如下图所示：

　　如此即可，至于顶部的状态栏的去除，选择编译设置里的Hide status bar是无效的，因为LÖVE在游戏运行时又做了一次设置。而这个设置则是与引擎的love.window.setFullscreen(fullscreen)这个API有关，只需要在游戏运行时设置为全屏即可关闭状态栏。如此便没毛病了，如下图所示：

开发调试

　　在开发过程中需要不断地进行实机调试时，每次都对项目进行打包那效率未免也太低了。然而鉴于iOS的沙盒机制，又做不到如同Android般使用Git来进行同步工程。好在*.love文件本质上就是*.zip文件，如此开发一个对压缩包进行增量更新的脚本即可。如以下代码所示，用到了zip命令，脚本版本为Python3：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

import os
import datetime
import zipfile
from os.path import realpath, dirname
def listdir(path):
    paths = []
    lst = path.split('/')
    tree = file_tree
    for i in range(len(lst) - 1):
        tree = tree[lst[i]]
    for k in tree:
        v = tree[k]
        p = k if v is True else k + '/'
        paths.append(p)
    return paths
def zip(code):
    os.system("zip %s %s" % (file_name, code))
def sync(path):
    is_file_a = os.path.isfile(path)
    is_dir_a = os.path.isdir(path)
    info = path in name_set and zip_file.getinfo(path)
    is_file_b = info and not info.is_dir()
    is_dir_b = info and not is_file_b
    
    if is_file_a:
        if is_dir_b:
            zip('-d %s' % path)
        
        if is_file_b:
            time_a = os.stat(path).st_mtime
            time_b = datetime.datetime(*info.date_time).timestamp()
            if abs(time_a - time_b) > 1:
                zip(path)
        else:
            zip(path)
    elif is_dir_a:
        if is_file_b:
            zip('-d %s' % path)
        
        if is_dir_b:
            list_a = os.listdir(path)
            
            for i in range(len(list_a)):
                if os.path.isdir(path + list_a[i]):
                    list_a[i] = list_a[i] + '/'
            list_b = listdir(path)
            list_merger = list(set(list_a + list_b))
            for p in list_merger:
                sync(path + p)
        else:
            zip(path)
            zip('-r %s*' % path)
    else:
        if is_dir_b:
            zip('-d %s*' % path)
        elif is_file_b:
            zip('-d %s' % path)
cwd = dirname(realpath(__file__))
os.chdir(cwd)
file_name = 'game.love'
zip_file = zipfile.ZipFile(file_name, 'a')
zip_file.close()
name_set = set(zip_file.namelist())
file_tree = {}
for p in name_set:
    ls = p.split('/')
    tree = file_tree
    length = len(ls)
    for i in range(length):
        s = ls[i]
        if len(s) > 0:
            if s not in tree:
                tree[s] = True if i == length - 1 else {}
            tree = tree[s]
sync('asset/')
sync('source/')
# ...

IPA发布

　　以上只能本机运行而已，若是想分享给他人，便要解决新的问题了。iOS的安装包为.ipa文件，你需要提供正式的开发者账号作为签名，方可生成之。开发者账号分为以下三种：

• 个人账号
  • 只能提供单人使用
  • 其他人若想运行ipa文件，需要注册其UDID
  • 99美元/年
• 公司账号
  • 允许多个开发者使用
  • 需要填写公司的邓百氏编码(D-U-N-S Number)
  • 其他人若想运行ipa文件，需要注册其UDID
  • 99美元/年
• 企业账号
  • 允许多个开发者使用
  • 需要填写公司的邓百氏编码(D-U-N-S Number)
  • 该账号下的APP不能发布到App Store
  • 299美元/年

也就是说，除了企业账号以外，想轻松分享给他人是比较麻烦的。这方面可以考虑诸如蒲公英一般的第三方签名平台，会更方便。
　　IPA的生成方式为Xcode下Product→Archive，然后根据指示进行即可。顺带一提，在编译设置中将game.love文件加入到APP资源里，变会默认直接运行该项目，以达到发布的效果。如下图所示：

LuaJIT

　　还有一个需要注意的问题是：Lua代码若是需要转为LuaJIT字节码，所选择的版本得是LuaJIT 2.1.0-beta2 64bit（在LÖVE 0.10.2下）。重点在于这个64位，由于Apple现行规定APP必须得是64位，于是连LuaJIT的字节码也必须同步。而想要生成64位的字节码，则必须编译出64位的LuaJIT，而这需要在编译时填写参数：make CFLAGS=-DLUAJIT_ENABLE_GC64。

后记

　　总的来说iOS平台较之Android在编译方面更为简单，毕竟是很稳定的平台与设施嘛。但在开发方面则有更多的繁文缛节，也算是福兮祸兮吧。

　　欢迎参与讨论，转载请注明出处。

前言

　　虽然先前未曾严明，但《DFQ》的全称为《DungeonFighterQuest》，由字面上便可得出，这是一款《DNF》的同人游戏，那么《DFQ》的地图自然向《DNF》看齐了。而《DNF》的地图众所周知，具有一定的复杂度，在以往的作品开发过程中便是采取了手动制作的方式，可谓十分的费时费力。于是在《DFQ》便采用了生成随机地图的方式，与市面上许多独立游戏的做法不谋而合，毕竟手动做地图实在是太辛苦了（汗）。本文便记录其中心得。

地图结构

　　如上图所示，这便是一张随机生成的地图，它拥有以下组成：

• 远景层：地图最底的背景，图中表现为山水。
• 近景层：地图较近的背景，图中表现为树林。
• 边上层：地图的上边界，拥有若干地图物件。
• 地表层：地图的地板，图中表现为草地。
• 边下层：地图的下边界，拥有若干地图物件。
• 活动层：地图的主体，拥有若干活动的地图物件。

　　在配置中以这种形式组成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

return {
    info = {
        width = {1440, 1280, 1024}, -- 宽度随机选择
        height = {600, 736}, -- 高度随机选择
        theme = "lorien", -- 地图主体
        type = "dungeon", -- 地图类型
        bgm = "lorien", -- 背景音乐
        bgs = "forest1", -- 背景音效
        name = {
            cn = "洛兰",
            kr = "로리엔",
            jp = "ロリエン",
            en = "Lorien"
        } -- 用于显示的地图名称，拥有中日韩英四语
    },
    floorHorizon = 327, -- 地表层起始Y坐标
    scope = {
        x = 16,
        y = 368
    }, -- 可行走区域起始坐标
    far = "$A/far", -- 远景层
    near = "$A/near", -- 近景层
    floor = {
        left = "$A/tile/0",
        middle = "$A/tile/2",
        right = "$A/tile/1",
        bottom = "$A/tile/3"
    }, -- 地表层
    sprite = { -- 图片
        up = {
            "$A/flower/0"
            ...
        }, -- 边上层
        floor = {
            "$A/grass/0",
            ...
        } -- 地表层物件
    },
    actor = { -- 活动对象
        down = {
            "$A/tree/0",
            ...
        }, -- 边下层
        article = {
            "$A/tree/1",
            ...
        } -- 活动层
    }
}

　　接下来将对逐层进行分析。

远/近景层

　　远景层与近景层的机制完全一致，所以可以拿来一起说明。当然之所以会分为两个层次而非合并，是因为远景与近景关于摄像机移动时的相对移动速度不一样，以此形成纵深感。但在地图生成这一块，它们的机制是一致的：

1
2

far = "$A/far", -- 远景层
near = "$A/near", -- 近景层

　　它们都是加载一张图片，然后根据地图的宽度进行平铺操作即可。在最后阶段会渲染成一张成品长图，这是一种优化方法。

边上层

　　边上层为地图的上边界，拥有若干地图物件。这里的地图物件与其他层的并不一样，在配置里它的划分是sprite，仅仅是单纯的图片罢了：

1
2
3
4
5
6

sprite = { -- 图片
    up = {
        "$A/flower/0"
        ...
    }, -- 边上层
}

　　因为这些物件不需要与角色产生什么互动，最后也会如远/近景层一般，渲染成大块的成图。
　　关于物件的放置，会采取生成宽高为100的格子铺满整行，并随机在这些格子上放置物件，如下图所示：

边下层

　　边下层与边上层类似，但是生成的地图物件为活动对象(actor)：

1
2
3
4
5
6

actor = { -- 活动对象
    down = {
        "$A/tree/0",
        ...
    }, -- 边下层
}

　　边下层的地图物件需要作为活动对象主要是因为某些物件会遮挡人物，所以需要采取靠近后透明化的措施。于是不方便作为单纯的图片。
　　物件放置方面与边上层一致，这里不再复述，如下图所示：

地表层

　　地表层即地图的地板，远/近景层类似，也是采取平铺的方针。但是在元素上更为多样：

1
2
3
4
5
6

floor = {
    left = "$A/tile/0",
    middle = "$A/tile/2",
    right = "$A/tile/1",
    bottom = "$A/tile/3"
}, -- 地表层

　　地表层的图片分为左中右下四种，左右两种为于地图边缘进行随机选择（左/右或中），中为默认选择，下为平铺Y方向。
　　除此之外，地表层还会拥有一些类似边上层的地图物件：

1
2
3
4
5
6

sprite = { -- 图片
    floor = {
        "$A/grass/0",
        ...
    } -- 地表层物件
},

　　这些物件也是不会与人物有所交互，最终与整个地表层渲染成大图。与边上/边下层类似，地表层物件的放置会XY平铺宽高为64的格子，以此放置：

活动层

　　活动层即地图的主体，活动对象的放置层，诸如障碍、宝箱、怪物等皆置于此。放置的规则与地表层物件一致，与地表层物件的不同之处在于，活动层存在一些拥有障碍的物件：

　　如上图所示，《DFQ》采用的障碍方式为传统的格子流，这种形式便于配合类似A星的寻路算法。但如此存在障碍格子与物件素材的匹配问题，这方面都需要手动设置好。以及需要警惕因障碍范围过大且恰好四周都是障碍物件围住了人物的情况，好在实际上并不存在这样的物件（障碍并不会很大），并不需要为此做特殊措施。

随机问题

　　在处理诸如物件放置的问题时，切忌采用遍历+随机数判断的形式。因为这是不符合概率论的（存在放置数量上限），如此便会导致地图左边的元素多于右边（右边存在轮不到的可能）。所以得采取将格子存储在一个list中，以list[math.random(1, #list)]的方式提取要放置的格子，如此即可保证几率均等了。

后记

　　对于一些需要个性添加的元素（地图特效、通行门、BOSS），一般会采取编写专门的处理函数进行添加。对于一些需要固定化的地图，也可以采取生成后输出成文件以加载使用。目前这套很明显的缺点在于无法生成崎岖不一的地形，不过目前暂无需求，且日后再看吧。

　　不知不觉中2018年即将过去了，与去年相同，特作总结，以为归纳。
　　今年的Blog总共写了14篇，较之去年的13篇算是相差不大。但内容方面则更为单纯了，简要说来便是：DFQ、网络同步、ECS、实践记录。期望明年能有新的花样。
　　今年的主要成果为对网络同步的涉猎，在帧锁定同步方面有《Brick & Ball》，在FPS/TPS同步方面有TPSDemo。收获了不少同仁的赞可，但都算不上是正式项目的实践，只能有待机会了。
　　项目方面，《DFQ》的开发也算是正式进行了，这将是明年的总旋律。与今年类似，如无特殊情况则保持月更相关Blog。待最终完工开源后（也许）将会是一个很好的学习素材。
　　平常时刻也有与ChawDoe进行一些作业方面的研究，涉及到诸如强化学习、哈希表、寻路算法、词法分析、UNIX/POSIX API、OpenGL等方面，也是获益良多，作为巩固基础了。
　　总的来说，愈发感觉到计算机图形学是自己的待恶补项，以及3D游戏开发中的不少方面也值得实践，这将是明年的发展方向，期望在这些方面能有所建树，作出一些心得分享。
　　以上便是本人的2018年度总结，今年下半年以来的社会经济状况不是很好，祈祷明年能够回暖吧。
　　无双草泥马
　　2018.12.31

　　欢迎参与讨论，转载请注明出处。

前言

　　在阅读本文之前，你需要了解一下何为ECS框架，今年年初本人也对此进行了相关研究。到了实际开发时发现确实有此需求，遂应用之。本文便记录其中心得。

ECS的意义

　　在讨论实现细节之前，首先要弄明白一个关键问题：为何要用ECS？ 对于我而言，使用ECS的意义在于使用传统OOP方式构造一个高度复杂的对象集时异常困难。在我看来，高度复杂的对象集即「多衍生物、衍生物之间多多少少拥有些共性」的存在。游戏中于地图上活跃的对象便是如此，拥有多种形式（物体、特效、子弹、NPC、怪物……），而这些衍生物之间多多少少会拥有一些共性（怪物和NPC都要寻路），如何组织安排好这些功能是很麻烦的一件事。在以往的开发生涯中，这部分我重构过很多遍，尝试过各种形式（将通用的功能做成子对象之类的），最终发现：ECS便是解决此问题的绝佳利器。

实现要素

　　上图便是本项目ECS框架的结构了，大致介绍一二：

• Entity（实体）: Entity是对象的主体，Component的容器，在数据结构的形式上就是个哈希表。
• Component（组件）: Component是数据的容器，与Data对接，提取相关数据。Component的形式多样，如Transform、Aspect、Input等。Component只有构造函数。
• Data（数据）: 来自配置文件，其中定义了各Component的配置所需。可由Manager将Data作为参数创建Entity。
• Group（群组）: Group以Component作为条件筛选出合适的Entity集合，如此便可使符合条件的Entity运作相应的业务。
• System（系统）: 业务运作的主体，以Group进行筛选出合适的Entity以执行相应的业务。分为Enter, Init, Exit, Update, LateUpdate, Draw六个业务函数。System的形式多样，如Drawing、Life、Battle等。
• Lib（库）: 存放通用业务函数之处，原则上以具体所需Component为参数，而非Entity，如Hitstop(attacker, identity, time)。如此是为明确函数调用条件，以及可以使Component分别来自不同Entity，实现一些特殊需求。Lib的形式多样，如AI、Battle、Effect等。
• Manager（中枢）: 负责Group与Entity的管理，如AddComponent, DelComponent, NewGroup, NewEntity等。
• Executor（执行）: 整套系统的执行者，负责导入System，定义System的执行顺序以及提供System的执行场所。

使用演示

　　以上便是ECS框架的组成元素了，接下来展示一下使用场景：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

-- attributes.lua
local _ATTRIBUTE = require("actor.lib.attribute") -- Lib
local _Timer = require("util.gear.timer")
local _Base = require("actor.system.base")
local _Attributes = require("core.class")(_Base) -- System
function _Attributes:Ctor(upperEvent)
    -- Filter
    _Base.Ctor(self, upperEvent, {
        battle = true,
        attributes = true
    })
    self._timer = _Timer.New(1000)
end
function _Attributes:Update(dt)
    self._timer:Update(dt)
    if (not self._timer.isRunning) then
        -- List is from group.
        for n=1, self._list:GetLength() do
            local e = self._list:Get(n) -- Entity
            -- Component of Battle
            if ((e.battle and not e.battle.isDead) or not e.battle) then
                local attributes = e.attributes -- Component of Attributes
                _ATTRIBUTE.AddHp(attributes, attributes.hpRecovery)
                _ATTRIBUTE.AddMp(attributes, attributes.mpRecovery)
            end
        end
        self._timer:Enter()
    end
end
return _Attributes

　　可以看到，这是属性相关的System，它提供了每秒回复HP与MP的业务。拥有Battle与Attributes组件的Entity方可执行，并且了ATTRIBUTE这个Lib的函数。采用这种形式只需要将业务分割为一个个System，以不同的Component组成游戏对象即可达到极高的灵活度。对于高度复杂的对象集而言可谓绝佳的解决方案。

子对象问题

　　在开发的过程中，总会遇到诸如状态、技能、BUFF之类需要以子对象形式存在的情况。为此应当如何实现是ECS框架绕不开的一个问题。我曾尝试为他们也纳入至ECS框架中，但是这样会使得System的数量膨胀，而且并没有带来什么明显的好处（它们的独立性很高）。也曾试过为它们弄二级ECS框架，但感觉很刻意死板。最终领悟到了一点：ECS框架对我而言的意义，只是降低构建对象的复杂度，若是对象本身的复杂度并不高，采用OOP的方式完全可以接受。

后记

　　ECS框架我只用在了地图对象，其余部分（如UI）等都是采用传统的面向对象形式，因为他们的构成复杂度并不高，切忌犯了“为用而用”的错误。当然对于Unity那边而言，ECS的意义在于达到高性能（内存连续、非GC、高Cache命中率、多线程），这时候为了高性能是不得不用了。当然Unity的ECS框架我所涉猎并不多，有待后日挖掘。

　　欢迎参与讨论，转载请注明出处。

前言

　　因友人的项目要做TPS联机对战游戏，本人遂对此进行了一番研究，经过四回的辗转反侧，Demo总算是做出来了。本次Demo是C/S一体化的设计，即服务端也是Unity做的（可选择1P兼任服务器或者将Unity以命令行模式运行于服务器）。网络模块采用了UDP+KCP，即先前BNB的强化版，而之所以没用UNet是因为之前搞出了乌龙所以换了现在这套，但序列化部分还是用的UNet。以上只是背景交代，本文仅聚焦于网络同步方面的细节。

实现思想

　　如果你对这方面有所涉猎，想必大致了解何为状态同步。市面上的大多文章将其与帧锁定同步对立而论，但本人认为两者并非是对立的存在，关于这点这篇文章讲的非常清楚，希望读者不要拘泥于形式。在阐述详细的实现思想之前，我们先来看看FPS/TPS游戏的需求：

• 非常迅速的操作反馈（若采用服务器应答后方有反馈的设计，很难达到要求，尤其是操作镜头） → 本地先行
• 个人体验第一（对于是否命中敌人与被命中不是很敏感） → 玩家之间看到画面情况不一致
• ACT元素低（不存在ACT游戏的打击控制链，不需要帧判定） → 不需要精确到帧的同步
• 服务器权威（命中判定由服务器决定） → 服务端模拟游戏世界、同步验证
• 房间战斗（玩家人数不多） → 与MMORPG同步不同
• 相对同步（玩家之间的时间差不可拉得太大） → 追赶进度

　　Well done，由以上几点需求已经得出了TPS游戏同步的实现思想，下文将根据实现思想阐述具体实现细节。

快照

　　在探究同步流程之前，首先要了解同步的核心：快照。换言之，也就是我们所同步的内容。快照（Snapshot）通俗来讲就是玩家的操作指令与相关数据的集合，由于需要做同步验证，所以将数据分为必要数据(Must)与验证数据(Check)，先来看看移动的快照数据结构吧:

1
2
3
4
5
6
7
8
9

// Actor/Common.cs
public class Move {
    public string fd; // Address:Port(Must)
    public int frame; // Game Frame(Must)
    public bool fromServer; // It is from server, or client?(Must)
    public Vector3 velocity; // Moving Velocity(Must)
    public Vector3 position; // Position before moving(Check)
}

　　如上文所示，position为移动前的坐标，像这类数据客户端是不需要上传的，仅用于与服务端传来的快照作对比，以进行同步验证。

同步流程

　　由于服务端模拟游戏世界，所以采用了C/S一体化的设计。在代码层面上则是分为ServerMgr与ClientMgr两个MonoBehaviour，ServerMgr负责收集客户端的快照并整合下发，而ClientMgr负责发送快照与模拟来自服务端的快照以驱动同步单位的运行。如下图所示:

　　图中所说的同步快照，是一种特殊的快照列表，它由服务端每帧打包，包括了多个客户端的一帧快照，客户端模拟它们即可驱动其他客户端代表的对象。采用这种同步流程只能保证在客户端是同一帧生成的快照，在服务端也会打包到同一个同步快照里。除此之外都不会保证（不会考虑到快照之间的帧间隔执行情况），即不需要精确到帧的同步。

追赶进度

　　在正常的同步过程中情况总是理想的，但是一旦出现网络延迟或卡住的话，在恢复之时便会面临大量的快照，那么按照现有的做法便会导致与其他玩家的时间轴拉得太远（看到的画面是很久以前的了），这便需要设计追赶进度的机制。需要注意的是，追赶进度是服务端与客户端都需要的（服务器也有网络延迟和卡住的可能），客户端的追赶处理相当简单，同步快照超过一个数量则循环模拟:

1
2
3
4
5
6
7
8
9
10

// ClientMgr.cs
if (this.syncList.Count > 0) {
    this.Simulate();
    
    // SYNCMAX = 15
    while(this.syncList.Count > SYNCMAX) {
        this.Simulate();
    }
}

　　服务端方面则较为复杂，简而言之就是要知道每个客户端快照列表有多少帧（如4个快照，帧号分别为1, 2, 2, 3，则为3帧），当某个每个客户端快照的帧数过高，则循环打包到同步快照列表:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// ServerMgr.cs
var list = new List<Snapshot>(); // sync-snapshot
// Foreach all clients.
foreach (var i in this.unitMap) {
    int frame = -1;
    var sl = i.Value.list;
    // INTERVAL = 10, i.Value.count that is count of frame.
    while (sl.Count > 0 && (i.Value.count > INTERVAL || (frame == -1 || sl[0].frame == frame))) {
        var s = sl[0];
        list.Add(s);
        sl.RemoveAt(0);
        if (frame != s.frame) {
            frame = s.frame;
            i.Value.count--;
        }
    }
}

本地先行

　　本地先行可谓这类同步最玄学之处，不过只要了解其原理倒也无甚。需要本地先行的理由在上文已经阐述，由于是以服务端权威且不那么介意判定的问题，所以是可以允许玩家之间看到画面情况不一致这种情况的。况且在大多数场合下，玩家先行并不会造成什么问题（最终的结果趋于一致），但假设在这么一个场合下：玩家A一直行走，在玩家B的视角里对玩家A进行了眩晕。如此便会造成不同步了，所以需要进行同步验证以将问题修正。
　　要实现同步验证的思路倒也朴素:就是用一个验证列表将快照保存，当收到同步快照列表时就进行逐个对照（对比它们的验证数据，见前文），一旦发现不一致之处，就以当前位置开始，循环模拟同步快照，然后再继续循环模拟验证列表里进度比目前快的快照，追上最新进度:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// ClientMgr.cs
// Compare sync list and check list.
for (int i = 0; i < list.Count; i++) {
    if (!list[i].Equals(this.checkList[i])) {
        index = i;
        print(i);
        break;
    }
}
if (index == list.Count) { // Agreement
    this.checkList.RemoveRange(0, list.Count);
}
else { // Need to fix.
    var frame = list[list.Count - 1].frame;
    // Remove useless snapshots.
    for (int i = this.checkList.Count - 1; i >= 0; i--) {
        if (this.checkList[i].frame <= frame) {
            this.checkList.RemoveAt(i);
        }
    }
    // Loop simulate.
    ClientMgr.Resolve(this.fd, list, index);
    ClientMgr.Resolve(this.fd, this.checkList, 0);
}

服务端权威

　　从上文可以看出，本地先行会修正的范围只有本地玩家而已，回到之前的例子:在玩家B的视角里对玩家A进行了眩晕，假设这个行为在服务端上并没有达成（玩家A闪现走了），那么该如何修正呢？很显然可以选择搞个更大的修正系统，但我认为这样并不符合业界的常规做法，所以我给出的答案是: 眩晕行为需要在服务端触发了，然后由服务端将其作为快照，以正常同步的形式在诸客户端上展示。事实上在网络正常的情况下，这样的间隔最多也只是0.1x秒左右而已，完全可以接受。当然这么做对于玩家B而言肯定会发生修正（眩晕按理来说是之前的事了），所以我对此作了个措施: 为快照设计了fromServer属性，一旦是fromServer = true且属于本地玩家的快照，本地玩家会直接模拟而不会将其进行修正对比。这也可以看出这套同步的一个规则:会影响他人的操作，都需要由服务端发起。

后记

　　很显然，目前这个demo仍很不成熟，不少地方在业界应该会有更好的处理，如CS的射击纠正（服务端根据客户端的射击时间回滚之前的场景进行判定）。如此只能算是一个雏形，还是缺少实战项目的淬炼，先根据接下来的项目看看效果吧。

　　欢迎参与讨论，转载请注明出处。

前言

　　在游戏开发的领域里，界面（User Interface）是不可或缺的，在一些强大的游戏引擎会为其配备一套解决方案。和之前的一系列问题一样，LÖVE自然是不会提供的，所以又得自己折腾一套了，本文便记录其中心得。

层级

　　许多年前，因我年少没经验，写UI都是逐个显示对象并填写参数的。捞的嘛就不谈了，所以也就深刻意识到面向对象以及建立层级体系的重要性。所谓层级体系，也就是将显示对象之间根据需求建立起上下级关系，下级的显示数据会基于上级（如上级移动了坐标，下级也会随之改变），这种玩意在Cocos我称之为Layer-Node体系（如下图所示），在Unity则是以Transform组件实现。欣慰的是，在LÖVE11.0也追加了Transform，同时不幸的是，我用的是旧版本，所以最终是自己造了一遍轮子:(

　　在设计上我首先实现了集显示与层级管理于一体的对象——Renderer，不过在实现上有点用力过猛，把Shader的层级管理也做了（下级的Shader会与上级的合并）。完成了这个核心之后，再分别设计基本的显示元素（Sprite、Animation、Particle、Label、Layer），不过我并没有另它们继承Renderer，而是设计了一个基类，并将Renderer作为成员对象存在，主要是Renderer的信息量过大，实是不宜直接继承了。结构如下图所示:

焦点

　　要说UI对象与一般的显示对象最大的不同之处，那便是会接收来自玩家的触控输入了，尤其是作为手机游戏，会同时受到多个触控。再涉及到图层等问题后，便有必要建立一个焦点管理体系了。首先UI对象需要提供判定触控，以及按下、持续、弹起的接口。然后在UIManager提供接收触控输入、焦点管理、对象运行的服务。流程如下图所示:

　　至于“判定触控所在坐标是否有符合条件的对象”这一需求的实现，便与上文提到的层级体系相得益彰了:显示顺序为从尾到头，而判定自然也是从最顶部的显示对象开始的，于是乎只要将Layer的成员从尾到头遍历判定即可。至于不想参与判定的对象会设置专门属性跳过。

MVC

　　这个便是老生常谈的设计模式了，去年我也对此作了一篇文章。简要来说便是，UI对象只负责接收输入（Controller）以展示结果（View），UI对象所保存的数据为展示而服务，真正的数据保存在来源对象（Model）。示例如下图所示（这里的Event按照C#的Event去理解即可）:

　　当然以上只是个人的理解，在我看来Controller即Model与View的桥梁，只要符合这个性质的存在即为Controller，它不一定是个固定的形式。包括按钮的按下处理函数这样的存在只要是由外部传入的，那么它也算是Controller。

配置

　　都8012年了，自然不可能以手写代码的形式创建UI布局，配置化自然是理所当然的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

return {
    name = "mapName",
    script = "advanced/mapName",
    x = 1100,
    y = -30,
    subject = {
        {
            name = "bottom",
            script = "sprite",
            sprite = "mapName"
        },
        {
            name = "label",
            script = "label",
            font = "normal/18",
            color = {
                red = 241,
                green = 218,
                blue = 157,
                alpha = 255
            },
            x = 90,
            y = 42
        }
    }
}

　　通过这般类似HTML的方式进行编写配置文件，交给专门的创建函数处理即可，具体的数据处理方式则交由对应的类（script）处理。若是开发了相应的UI编辑器还可以直接制作生成配置，很显然这里也是契合了层级体系，可见其重要性。

后记

　　目前这套界面体系还缺乏相应的编辑器以及没有自适应布局的功能，不过实际上我也不太需要这些。只能说面向内部与面向公众的要求级别是不一样的，所以这并不能代表通用UI库的设计思想，仅供参考而已。