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

前言 其实本文倒没有什么技术含量，纯纯的记录一下这个有趣的过程 环境：Unity 2020.3 正文 今天接到了要实现图文混排和超链接需求，第一反应是基于UGUI去做，然后我就去找各种开源库实现，一开始自然是去Github找了各种开源库实现，比如排行第一的：https://github.com/coding2233/TextInlineSprite 但遗憾的是自从Unity2019更改了UIText顶点构建策略之后，几乎所有网上现有的实现都失效了（反正我是基本上尝试了每一个看起来靠谱的仓库） 比如这个仓库的超链接功能 其中绿色矩形为超链接点击区域的可视化Debug，可以发现，当UIText无法显示完全所有文本时，碰撞检测是正常的，但当UIText可以完全显示所有文本时碰撞检测又是错乱的 当然不仅如此，其图文混排也是有问题的 第一个表情显示正常，第二个表情就直接乱码了，归根到底还是因为这个仓库的实现已经不适配新版本Unity的顶点构建策略了 怎么办呢？我都想硬着头皮读作者的源码然后一点点修复了，想想都觉得头疼，涉及到DSL（自定义的富文本语言）解析，顶点重计算，Sprite占位 ...

前言 最近开坑了一个状态帧同步战斗系统视频教程，总共有5个视频 其中第一个和最后一个都好说，我自己乱吹就可以了，但是中间三个重量级比较难处理，我的计划是实时录制原GDC视频 + 分享自己的理解和思路，原视频的平均时长都在一个小时左右，如果直接莽上去很有可能在讲解的时候思路断掉，所以我需要针对他们梳理出一个大纲来理清楚讲解思路，顺带方便大家自己在学习守望先锋GDC视频的时候有针对性的去了解自己需要了解的部分。 《守望先锋》架构设计和网络同步 原视频链接 视频内容大纲 00 : 00 - 1 : 00 ：守望先锋游戏与开发团队介绍 1 : 00 - 7 : 15：ECS概念介绍与守望先锋中使用ECS的示例 7 : 15 - 8 : 07：ECS VS OOP，核心问题还是庞大工程中引用和解耦问题。传统OOP中，抛开常知的继承炼狱问题不谈，一个类既是数据又是逻辑，那么当一个类会与多个不同的类进行交互的时候，就会面对如何拆解数据和逻辑提供给相对应的类的问题，如果选择不拆，那么就需要面对越来越庞大的类，如果拆了，那么一些只有其他类才需要用到的数据和逻辑就应当被其他类在Update或 ...

游戏设计精粹《总目录》 死亡搁浅：一封针对云玩家的挑战书 文章概要个人总结 段落一 作为一名极富才华的游戏设计者，小岛秀夫最擅长的，就是基于能够“点火”的导火索来设计游戏，然后通过出色的设计技巧来感化他的用户——他开发生涯中最著名的那些设计例子大多都是这样实现出来的。先“玩火”，然后再“感化”，就是他成为顶级制作人的秘诀。 小岛秀夫成名作的《合金装备》，是世界上第一个鼓励玩家不要和敌人战斗也不要被发现的“潜行”游戏；他做出这个设计的原因，是因为MSX这款非主流主机相对于街机和FC贫弱的处理技能，不允许玩家和敌人同时用大量的子弹互相交战占用太多活动块资源。在《合金装备固体（MGS）》初代中，最著名的对Mantis战，则是利用了PS上记忆卡的硬件设备，以及游戏机手柄可以热插拔的新机能，让这个“拔下手柄插在另外一个手柄口里来躲避BOSS读心”的设计成了最著名的超游戏设计之一。到了MGS3，植被技术的提升让游戏内加入了大量围绕着草地和森林的生存设计，游戏主机操作系统内的时钟更是让小岛秀夫想出了“让游戏内的老人BOSS按照玩家的真实时钟老死”这种充满了吐槽点的设计。在MGS5里，一个几乎不 ...

前言 Unity的UIElement已经发布两年多了，最近才开始正式重度与其打交道，此文章主要介绍UIElement和一些常用功能和一些不常见的坑，并且提供一些UIElement的学习资料。 正文 UIElement介绍 UIElement（现更名为UI ToolKit但是程序集名称还是UIElement，雀食没话说）是Unity新推出的一种UI解决方案，目标是一站式解决Editor+Runtime的UI设计需求，使用C# + HTML的形式进行开发，其中HTML用以定义UI样式和内容，C#引用HTML定义内容+绑定数据，并且与GamePlay进行交互。 我们来看看他的底层是怎么样的： UIElement使用了名为UIElements Renderer（UIR）的渲染后台，为UIElement渲染量身定制，尽可能提高性能。 使用Retained Mode GUI (RMGUI)以及按需更新的模式，当UI元素没有发生变化的时候几乎0消耗。 渲染时分配一个大的VB/IB缓冲区，使用特制的Uber Shader，减少渲染状态切换，一个DrawCall即可完成整个UIElement ...

今年是我从学生变成社畜的一年，感触良多。 一月~六月 这几个月都在学校摸鱼，玩了很多游戏，奥日与萤火意志，恐怖黎明，破坏领主，只狼，空洞骑士，Hades，神界原罪2，枪火重生。。。并且给之前玩过的很多盗版游戏补了票，丢人，就不多说了 5，6月份和在南京的同学好好的聚了几次餐，至今仍然在回味的是那次东北菜馆里的猪肉白菜炖粉条，啧啧，真的绝啊 还去了一次奥特曼展会，说来也奇怪，小时候我喜欢奥特曼喜欢的死去活来，但是自从上了初中之后就很少主动去搜索奥特曼相关内容了，我觉得这和年龄没什么关系，毕竟初中生不也是小屁孩嘛，有可能还是不够热爱吧 朋友们兴高采烈地参观着，我只能看着那些有点陌生的奥特曼带着点兴奋，带着点尴尬的陪衬 技术上面值得说道的有两个 Rendering 一是断断续续进行了半年的渲染相关学习，仔细复习实践了一遍Shader入门精要，URP等内容 https://www.lfzxb.top/categories/图形渲染/应用实战/ https://github.com/wqaetly/URP_Practise 总体的感悟就是，渲染的学习翻来覆去就是一些矩阵变换，一些GPU ...

简介 幕府时代末期，外忧内患，山河动荡，百姓生活困苦，且生命时刻受到威胁。少年心太因其善良纯洁之心感动飞天御剑流高手比古清十郎，被其收入门下学习剑法，更名剑心。在国家危难之际，年轻的剑心怀揣改变时代的梦想下山，加入奇兵队，日后更被桂小五郎纳入麾下，以刽子手的身份为时代的变革尽一份绵薄之力。年仅15岁的剑心接连刺杀多名政府要员，令对手闻风丧胆，直到某一天，一名下级武士在他的脸上留下一道无法愈合的伤疤。来至京都寻找爱人的雪代巴邂逅了剑心，正是眼前这名瘦弱的男子将爱人从她的生命中带走。巴走入剑心的生活，随之经历了政治斗争的血雨腥风和田园乡下的宁静淡雅。也许她正是剑心那把狂舞之刀的刀鞘，但在大时代的背景之下，两个人的渺小幸福一触即碎…… 有感 绯村虽已杀人无数，但内心依旧无比纯洁，但正是这份纯洁，让他开始陷入了迷茫 “ 我不想死，我心爱的人还在等着我 ”，绯村恍惚之际，这位身手仅仅是中下的武士已经在绯村脸上留下了永远无法愈合的伤口 “ 你还真是，能掀起腥风血雨呢 ”，说着，身穿溅满鲜血的纯白和服的女人就昏倒过去 “ 为了开创所有人都能安居乐业的时代，我会不断杀人，直到新时代的来临 ” ， ...

前言 当我们在进行网络游戏开发的时候，往往想要在本地测试弱网环境下游戏的同步表现如何，正巧一位友人@Ray告诉了我Clumsy这款工具，使用之后感觉非常良好，推荐给大家。 Clumsy Clumsy是一个开源MIT协议的弱网模拟工具，基于WinDivert实现，可以在本地非常方便的模拟弱网效果 延迟（Lag），把数据包缓存一段时间后再发出，这样能够模拟网络延迟的状况。 掉包（Drop），随机丢弃一些数据。 节流（hrottle），把一小段时间内的数据拦截下来后再在之后的同一时间一同发出去。 重发（Duplicate），随机复制一些数据并与其本身一同发送。 乱序（Out of order），打乱数据包发送的顺序。 篡改（Tamper），随机修改小部分的包裹内容。 TCP RST攻击模拟（Set TCP RST） 带宽限制（BandWidth），通过限制带宽来达到不同级别宽带下的表现 仓库地址：https://github.com/jagt/clumsy 可以直接从Release列表下载 官方使用说明：http://jagt.github.io/clumsy/cn/index.h ...

前言 最近除了拼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帧，那么 ...