基于行为树的MOBA技能系统:基于状态帧的战斗,技能编辑器与录像回放系统开发手札
前言 基于行为树的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
ET6.0使用手册
前言 本文章不包含代码分析,仅仅为使用手册。 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就是...
FGUI插件开发指南(Lua)
前言 前几天给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官方推荐的注释方式 进行...
ET6.0学习笔记
前言 由于之前已经写过很多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 dbserver...
xasset 7.0入门指南
前言 这阵子终于有空来整框架相关的内容了,目前处理到资源管理相关,自然还是选择我们的老朋友xAsset,简洁强大的资源管理框架!老版本的xAsset(4.0)我也写过一篇入门笔记,前阵子它发布了7.0版本 对比上一个开源版本(4.x),7.0 最大的变化是: 编辑器和运行时高度剥离,代码结构更精炼和模块化。 使用只读的物理文件数据进行版本管理,版本检测稳定性和效率得到前所未有的提高。 打包后的文件的文件名自带文件内容的版本信息,天生可以避免CDN缓存问题以及一些其他的冲突。 全新的多线程文件下载组件,真机环境比之前 UnityWebRequest 版本更稳定。 自动分帧机制为程序运行的流畅度提供保障。 加载资源默认支持自动更新。 相对详细的官方文档 今天就来学习下 正文 下载 xAsset地址,也是本文写作时的Commit版本:https://github.com/xasset/xasset/commit/69f04a06e4a900ce1f77f46e7a494fd19037c579 下载好之后直接将其中的Versions和Versions.Example放到项目根目录即可...
Early-Z和Late-Z规则
前言 已经不止一次看到有文章说:不管有没有Early-Z最后的Late-Z一定会执行了,仔细想一下其实是不合理的: Early-Z相当于把Late-Z提前,一样会有逐片元的深度测试和深度写入,如果Early-Z和Late-Z是共存的,那么就有两次Z-Buffer的读取和写入,造成带宽浪费 Early-Z因为种种原因失效了,执行Late-Z无可非议,但如果Early-Z没有失效,我们都在Early-Z处理好了,为什么还需要在Late-Z处理一次? 这篇文章就把深度缓冲区的所有操作都整理起来,并且还会包含一些引申出来的知识点,给每位看官进行一条龙服务。 正文 名词规范 国际惯例了属于是,为了避免歧义,本文中所有用到的名词,英语词汇都将在此处列出,希望看官们能把此处列出的名词和释义代入文章中,而不是自己脑海里的,这样你好我也好: PS:片元着色器 Z-Buffer:深度缓冲区 Z-Test:深度测试 Z-Write:深度写入 Early-Z:提前Z-Test和Z-Write,位于光栅化阶段之后,PS阶段之前,以pixel quad为单位(既以4个像素为一组,因为深度缓存内的数据是...
基于GPU Instance的草地渲染学习笔记
前言 其实这篇文章的内容一直是在我的学习计划中的,但是由于种种事情而耽误了,最近正好有空,可以静下心来好好学习下,这篇文章应该是我2021年渲染学习的一个句号,剩下的一个季度要把精力放到技能编辑器的完善和状态帧同步的实现上。 学习对象依旧是Colin大神的仓库,这次的效果最为震撼和炫酷——基于GPU Instance的草地渲染 本文章主要涉及到的技术内容为: GPU Instance的底层原理 GPU Instance API 基于GPU Instance的草地渲染实现 草地渲染内容拓展 GPU Instance的底层原理 简单概括一句话就是:传递一个对象的Mesh,指定其绘制次数和材质,Unity就会为我们在GPU的统一/常量缓冲区开辟好必要的缓冲区,然后以我们指定的材质对Mesh进行我们指定次数的渲染,这样就可以达成一次Drawcall绘制海量对象的目的。 好处在于: 传统渲染方式(无合批情形):绘制多少个对象就要整理和传递多少次数据,其中整理和传递数据的过程消耗极大,多数为性能瓶颈 GPU Instance:只用从CPU往GPU传递一次数据,大大提高了渲染效率。 ...