登峰造极者，殊途亦同归。

前言 最近除了拼UI之外也在断断续续做着渲染性能优化工作，其实这块内容说难也不难，说简单肯定也不简单，不难是因为当今Profiler工具相当完善，甚至可以精确到每一条Shader汇编指令的耗时，XCode还可以给出优化建议，不简单是因为很多时候就算得知了性能热点，但却不知道如何下手，因为需要掌握的知识很多，比如要会看Nvidia，OpenGL，Vulkan等后端API的汇编码，要知道做了优化操作之后对渲染流程中各个模块的影响，比如为了减少OverDraw把Alpha Blend改成Alpha Test，Early-z会不会失效，在移动平台是不是性能更高，还有些情况让人纠结，比如优化了下ALU耗时，带宽又上去了。 对于老手来说可能一行代码写下来，什么带宽，ALU耗时，精度转换，甚至汇编码都知道是什么个情况了，对于新手来说，就得老老实实对着Profiler工具慢慢看，慢慢调。当然这是少数情况了，大部分情况下老手们依旧要看Profiler，因为谁也捉摸不透不同的GPU架构和指令集会做出怎么样的优化（负优化），所以于情于理Profiler工具的学习还是很必要的。 目前用下来感觉最好用的移动 ...

前言 基于行为树的Moba技能系统系列文章总目录：https://www.lfzxb.top/nkgmoba-total 在2021年的最后一段时间里，我决定将业余的时间和精力放到我的老朋友MOBA项目的技能系统的网络同步部分的开发和完善上来，主要工作内容是： 在原本行为树的基础上再接入一套Timeline系统用于更加方便和直观的编辑技能 将原本状态同步的方案转变到状态帧同步方案 这里还是简单的谈一下为什么不选择帧同步而选择状态帧同步，如果基于帧同步进行开发的话，定点数的使用会大大增加各个模块的时间和人力成本，并且稍不注意就会有毁灭性的不同步出现，再者，帧同步出于安全考虑需要服务端进行校验工作，工作量和状态同步基本上没什么区别，帧同步真正的价值在于其 “帧” 的概念，有了帧的概念，就可以去预测，去回滚，去做录像，去做观战。。。而状态帧方案就可以让我们在不受限于帧同步条条框框的基础上拥有帧同步的开发体验与项目效果，其相对于帧同步来说，最为困难的部分就是根据服务端传来的帧数据进行重新模拟+回滚，这要求状态和逻辑分离的非常纯粹，也就是说对于客户端，接收任意帧内相同的输入必须能回滚到与 ...

前言 基于行为树的Moba技能系统系列文章总目录：https://www.lfzxb.top/nkgmoba-total 承接上篇 基于行为树的MOBA技能系统：基于状态帧的战斗，技能编辑器与录像回放系统设计 这篇文章记录一下将状态同步切换为状态帧同步所做的改动 网络同步 首先是最基础的网络同步模块 目前业界主流有两种做法 使命召唤：客户端落后于服务器，服务器收到客户端消息时根据帧号回滚到那一帧进行模拟，并将得出的结果返回客户端 守望先锋：客户端领先于服务器，服务器收到客户端消息以当前服务器所在帧为准，统一进行模拟 两种做法都是可以的，最大的不同在于服务器收到客户端消息时的处理方式，其他逻辑（比如预测，回滚）本质都是一样的，因为守望先锋的分享更加详尽一些，细节处理的可参考度也就更高，所以这里选择守望先锋的做法 这块内容在 基于行为树的MOBA技能系统：技能系统与网络同步 有提到，此处不再过多赘述，其中需要注意的一个概念是客户端一定是领先于服务器的，因为我们发送的网络包会在半个RTT+一个缓存帧时长才会到达服务端，所以如果服务端当前是95帧，RTT是8帧，缓冲帧时长为1帧，那么 ...

序言 时间一转眼来到2021年年底，我的程序学习之路应该暂时画上一个逗号了，当然还有一些Big Things需要去做，剩下的两个多月主要精力就是处理这些Big Thing。 言归正传，一直关注我文章的朋友知道我的最终目标只是做游戏，目前为止所做的所有工作都是为了在未知的将来的某一款游戏，我认为游戏设计和技术一样，都是需要去系统学习的，举个例子就是一个程序员是否学习过操作系统，编译原理的决定了他所能到达的高度，这个观点可以说很常见了，甚至称之为计算机定理都不为过，但是为什么游戏设计界鲜有人提出呢？我认为，是因为大部分人游戏设计的水平并没有到达需要使用系统学的游戏设计框架的地步，就像同样是写增删改查，菜鸟程序和大神程序基本上没什么差距一样。 那么为什么现在才10月份就要开始明年才正式去做的事情呢？emm，主要是要换换脑子，程序写多了难免有点神智不清，扭头学一波游戏设计，看看前人留下的精华，也算是为以后的游戏开发铺路了，写成文章记录下来也是为了给自己一个备忘，好记性不如烂笔头嘛（还能避免博客长草，太棒了）。 《游戏设计精粹》（其实只是我一时兴起起的名字）系列文章持续更新，但不定时，平时有 ...

游戏设计精粹《总目录》 决战刘谦！魔术VS超高速摄影机，能拍到破绽吗？：MisDirection 视频概要个人总结视频内容本身就是UP主用高速摄影机挑战魔术师手速的内容，当然人的速度是不可能快过千分之一秒甚至万分之一秒的高速摄像机的，但是视频的后半部分魔术师为了捍卫这一职业的尊严，提出，实践了MisDirection这一概念，把高速摄像机UP主治的服服帖帖，我个人看完视频后对魔术师这一职业更加的发自内心的尊重，他们也是一种艺术家，与游戏设计者算半个同行。回到MisDirection这一概念上来，直译过来就是错误引导，这在游戏开发中是很常用的技巧，通过剧情，旁白，场景，音乐把玩家朝着错误的方向引导，随后马上“摆玩家一道”，当然了，摆这一道不能是玩玩家，得让玩家感到心悦诚服才行，不然玩急眼了人家就不玩了。 这种让玩家心中所预料与实际发生的事情落差很大的手法如果把握不好很容易让玩家产生挫败感，也就是说你得让最终的反馈远大于玩家的挫败感才能震撼到玩家，例子也有很多，例如《ICE》里会有一个旁白不断地指引你的道路，如果玩家反方向走就会触发彩蛋，算是小惊喜，但也平添了几分别样的乐趣，再比如《 ...

前两天电脑坏了，重装了系统，还是从MSDN上下载的，但是当我打开系统的应用列表。。。我吐了，光秃秃的什么都没有啊，怀着忐忑的心情打开Unity，老子操了，全是缺库报错 现在微软官方都不默认给发布版系统添加这些库了吗，雀氏是够可以的，我想啸啊！ 其实只要打开应用列表，发现没有这么一大坨东西的话，说明系统缺了运行时库 不禁让我回想起 YUN OS 工作室 的优秀作品，提供的系统都是运行时库齐全的，真的装上就能用，但是可能有的小伙伴不想再换系统了，就一个个对照着dll名字去百度搜索下载了，解决了还好，但是大部分情况下是解决不了的，要模式dll版本与当前系统不兼容，要么是dll注册失败，真的很折磨人，我在网上找到了一个 一键安装微软运行时库的EXE文件，试了一下，完美解决 下载链接提取码为wlil

前言 本文章不包含代码分析，仅仅为使用手册。 ET本身就是一个很优秀的框架，对于ET的设计理念和核心思想，可以去阅读下原作者写的一系列文章：ETBook 这里也列举出一些学习资料，供大家参考 ET 6.0学习笔记——着重介绍ET6.0的新概念与设计思路 我的B站ET6.0视频教程——偏代码解读 字母哥Binary的B站ET6.0视频教程——偏实践 环境 服务器 .Net版本：.Net Core 5.0 云端服务器：CentOS 7.6 公共部分 基础架构 ET是一个单线程，多进程的框架，好处是单线程的开发效率更高，写出的代码更安全，Bug也更好查，多进程可以做分布式架构，均衡负载等。 ET框架采用了ECS架构（Entity-Component-System），而非传统的OOP架构，好处是开发效率非常高，并且借助于ECS的解耦功能，重构起来也很快。 但是ET的ECS也并非纯正的ECS，而是在架构学术派与实用派做了折衷，严格来说是E + S（Entity是纯数据，System是纯逻辑），那么把Component放哪了呢？在ET里Component就是Entity，Entity ...

前言 前几天给ET6.0写了一份FGUI代码生成插件，期间被一些容易混淆的变量名折磨的不轻，这篇文章就记录下从零开始的FGUI插件开发过程。 正文 环境 IDE：Rider 2020.3 Unity 2020.3.17f LTS EmmyLua 1.3.6.215 FGUI Plugin Lua API 首先下载FGUI-Editor，然后解压，定位到 FairyGUI-Editor/plugin/LuaAPI 目录，记住这个目录，我们后面需要用到他 安装EmmyLua插件 直接在Rider的应用市场下载安装即可 搭建插件开发环境 使用Rider随便新建一个项目，然后在这个项目里添加上面那个FGUI Plugin Lua API文件夹引用 然后再如法炮制，添加我们要开发的插件目录引用，比如 ET/FGUIProject/FGUI_ET/plugins/NKGCodeGenForET6 目前为止，我们插件的开发环境已经集成完毕了，并且得力于EmmyLua插件，我们还有了完善的Lua API提示（前提是在开发插件的过程中严格按照 EmmyLua官方推荐的注释方 ...

前言 由于之前已经写过很多ET相关教程，本篇文章主要提及ET6.0的新概念和新特性，其实6.0很多知识点和之前版本一样适用，想看ET之前版本教程的，可以前往：ET篇：个人笔记汇总 本文写作时对应的commit版本：https://github.com/egametang/ET/commit/43abb90cd05445f2e9a0625ac12caaab59486672 基础概念 此部分内容参考：ET6.0的设计思路 推荐大家有问题先去ET论坛逛逛，里面有很多管理员整理好的日常讨论答案，技术教程，以及其他朋友提出的问题，可以学到很多知识。 ET 6.0创新概览 之前每个功能是一个进程，比如realm gate location map，现在改成每个功能是一个Scene，一个Scene可以放到一个进程中。这样一台物理机先启动固定的进程，然后各个scene放到进程中运行。非常类似docker。 所有的Scene放在一个进程就变成了AllServer模式 服务器内部全部使用actor发送消息，比如realm发给gate，其实是发个actor消息到gate scene dbserve ...

前言 这阵子终于有空来整框架相关的内容了，目前处理到资源管理相关，自然还是选择我们的老朋友xAsset，简洁强大的资源管理框架！老版本的xAsset（4.0）我也写过一篇入门笔记，前阵子它发布了7.0版本 对比上一个开源版本（4.x），7.0 最大的变化是： 编辑器和运行时高度剥离，代码结构更精炼和模块化。 使用只读的物理文件数据进行版本管理，版本检测稳定性和效率得到前所未有的提高。 打包后的文件的文件名自带文件内容的版本信息，天生可以避免CDN缓存问题以及一些其他的冲突。 全新的多线程文件下载组件，真机环境比之前 UnityWebRequest 版本更稳定。 自动分帧机制为程序运行的流畅度提供保障。 加载资源默认支持自动更新。 相对详细的官方文档 今天就来学习下 正文 下载 xAsset地址，也是本文写作时的Commit版本：https://github.com/xasset/xasset/commit/69f04a06e4a900ce1f77f46e7a494fd19037c579 下载好之后直接将其中的Versions和Versions.Example放到项目根目录即 ...