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

前言 《守望先锋》2017 GDC系列的分享前几年给了我很多帮助，尤其是kevinan大神的翻译更让我受益良多，如今我再想温习一下相关技术却发现很多网络上的文章图片都已经坏掉了，故在此收集网络资源发布重置版，当成备份。 重制版内容：新增多级标题，方便分块阅读，部分图片已由本人重置，一些必要的地方我录制了Gif图，方便观看。 全系列链接：《守望先锋》GDC2017技术分享精粹重制版总目录 原视频链接：https://www.youtube.com/watch?v=W3aieHjyNvw&t=2886s&ab_channel=GDC ECS ECS概述 哈喽，大家好，这次的分享是关于《守望先锋》（译注：下文统一简称为Overwatch）游戏架构设计和网络部分。老规矩，手机调成静音；离开时记得填写调查问卷；换下半藏，赶紧推车！（众笑） 我是Tim Ford，是暴雪公司Overwatch开发团队老大。自从2013年夏季项目启动以来就在这个团队了。在那之前，我在《Titan》项目组，不过这次分享跟Titan没有半毛钱关系。（众笑） 这次分享的一些技术，是用来降低不停增长 ...

前言 《守望先锋》2017 GDC系列的分享前几年给了我很多帮助，尤其是kevinan大神的翻译更让我受益良多，如今我再想温习一下相关技术却发现很多网络上的文章图片都已经坏掉了，故在此收集网络资源发布重置版，当成备份。 重制版内容：新增多级标题，方便分块阅读，部分图片已由本人重置，一些必要的地方我录制了Gif图，方便观看。 全系列链接：《守望先锋》GDC2017技术分享精粹重制版总目录 原PDF链接：本文部分图片如果想查看高清大图，可前往 《守望先锋》中网络脚本化的武器和技能系统 PDF 下载PDF 原视频链接：https://www.youtube.com/watch?v=ScyZjcjTlA4&ab_channel=GDC 嗨，大家好，我叫 Dan Reed, 是暴雪娱乐的游戏工程师（gameplay engineer，译注：游戏机制工程师，或者游戏工程师，都可以），今天主要跟大家分享《守望先锋》（后面统一用Overwatch表示）中的网络脚本化的武器和技能系统。 那么这里先简单介绍下我在Overwatch中的主要工作。 Statescript脚本系统，这也是今天 ...

前言 《守望先锋》2017 GDC系列的分享前几年给了我很多帮助，尤其是kevinan大神的翻译更让我受益良多，如今我再想温习一下相关技术却发现很多网络上的文章图片都已经坏掉了，故在此收集网络资源发布重置版，当成备份。 重制版内容：新增多级标题，方便分块阅读，部分图片已由本人重置，一些必要的地方我录制了Gif图，方便观看。 全系列链接：《守望先锋》GDC2017技术分享精粹重制版总目录 原视频链接：https://www.youtube.com/watch?v=W4oZq4tn57w&ab_channel=GDC 设计目标 那么回放系统的概要设计(high level design)目标是什么呢？ 这次分享的标题就预示着必须给出答案，对吧？概要需求是创建一个单一的中央系统，能够支持阵亡镜头、全场最佳和亮眼表现，除此之外我们还特别需要能够生成录像文件，在开发期间可以用来做内部调试。 下面开始深入介绍每个议题。 每次玩家死亡时，游戏里就会显示临死前几秒钟的――大部分情况是以凶手（killer）视角来看的――死因及死亡过程。阵亡镜头可以帮助玩家理解他们是怎么死的，以及为什么 ...

前言 前几天在网上看到一位大神的 Unity Shader-热空气扭曲效果 文章，感觉应该是个常见的效果，所以准备在URP里实现一下，正好再次深入使用一下URP，期间也遇到了一些匪夷所思的坑，也会在文章中说明。 原文中的全屏扭曲和基于GrabPass的方式都省略不谈，这里来用URP实现一下基于后处理的热空气扭曲。 环境 URP版本：7.3.1 Unity版本：2019.4.8f1 正文 原文中的实现核心思路是在需要扭曲的地方摆放一个面片，然后将这个面片渲染到一张RenderTexture上作为Mask，后处理的时候以Mask为基准决定ColorTexture哪些地方需要扭曲，然后对一张Noise图进行采样，对目标像素做偏移，达到扭曲的效果。 仔细分析后发现其实就一个难点，就是如何在URP下将物体渲染到一个RenderTexture上。 恰巧前阵子 研究战争迷雾 的时候看到了这篇文章：流朔 -【Unity URP】以Render Feature实现卡通渲染中的刘海投影 ，其中就有将物体渲染到RenderTexture的相关操作，这样一来就没有问题了，开搞。 首先创建一个Rende ...

本文章已于2021.9.24更新，提供一个JobSystem加速示例。 本文章已于2021.3.23更新，将用到的Shader代码转为HLSL语言，支持SRP Batcher（虽然在这里并没有什么卵用），优化模糊Blit次数。 前言 这阵子在研究战争迷雾相关的内容，在网上找了一些文章和开源库，主要有两种做法： 一是直接在场景上放一张大面片，用作迷雾，这种方式适用于相机角度不会发生改变的情况，否则会有穿帮的风险，但这种方案性能比较好。 二是基于屏幕空间对迷雾纹理进行采样，然后通过后处理的方式得到最终游戏画面，这种方案最为稳妥，但相应的性能会低一些。 但是网上找得到的战争迷雾方案全都是Built-In管线下进行的，那么对于基于屏幕后处理的战争迷雾，就会不可避免的涉及到OnRenderImage和Blit操作，这些操作在默认不指定相机RenderTexture的情况下会涉及对GPU中的FrameBuffer进行拷贝 + 和CPU与GPU之间的数据传递，都是比较消耗性能的操作，需要尽量减少，单一个战争迷雾可能还好，后处理特效多起来后，对于移动平台来说，本就不富裕的带宽再次雪上加霜。 ...

前言 我个人非常喜欢诺克这个英雄，原因是多方面的 1. 他会回血 2. 伤害高 3. 坦度高 4. 大招帅，还能刷新连劈 视频链接们 炸胡视频：

前言 事情起因是在用Lua根据文件模板生成CPP过程中出现的问题。 文件是正常生成了，但是编译遇到了错误，报错就是检测到Mac文件格式：请将源文件转换为DOS格式或UNIX格式 查找问题 几番百度谷歌，大家一致认为是每行末尾的CR LF出了问题 在Windows下换行使用CRLF两个字符来表示，其中CR为回车（ASCII=0x0D），LF为换行（ASCII=0x0A） 但是无论是记事本和IDE都无法显示这两个字符 网上说Notepad++可以显示 我试了下，可行！ 到这里问题就很明显了，就是有部分文本行结尾是CR，而不是Windows标准的CRLF 但是问题出在哪呢？ 文件模板没问题 我在Lua那边的字符串拼接（..）和替换（string.gsub）过程打印了一下，也都是正常的字符串 那问题只可能出在最后的往文件内写入字符串（file:write）了 想了想原因，应该是我直接整个读入的文件模板，而不是逐行读入，造成了写入文件过程中他会自动用CR分割每行内容，所以就出现了这个问题 解决问题 找到问题根源就很好解决了，我们只需要在最后写入文件前，逐行替换'\r'为'\n' ...

本文章已于2024.7.7更新，原因是被校园卡的高额月消费搞得焦头烂额，废了好大劲才处理好。 前言 大家好，我是一位来自南京二本院校的CS专业的大四学生，你们可以叫我烟雨。这篇博客主要分享我的大学学习/生活历程和建议，以及对于一些想作为一名程序员进入游戏行业的人的建议。 本篇博客仅仅是建议，仅供参考，每人有自己的人生观，价值观，人生路线规划，我也尊重每个人的人生观，价值观，人生路线的规划，如果某些言辞刺痛了你，我提前道歉。 目标人群 仅限在校大学生。 正文 行业介绍 在游戏行业，细分了很多工种，比重比较大的，有GamePlay程序员，策划，美术，测试，当然还有比较稀缺但珍贵的技术美术(TA)，这也是我当前在努力的方向和目标，由于我本身学习路线是属于GamePlay工种，所以主要讲Gameplay方面的内容了。 先给大家大体介绍一下这几个工种的具体分工吧 GamePlay程序员：主要负责游戏逻辑代码的编写，功能/架构的开发，插件开发 策划：策划游戏的玩法，战斗系统，游戏的活动 美术：主要负责提供游戏中的美术素材，比如我们看到游戏中的UI，模型，特效等 测试：负责对程序功能进 ...

推荐大家配合音乐食用嗷（国际惯例，不含剧透）！ 正文 今天偶然在QQ看点刷到了《大贵族》的片段，里面几个主要角色颜值都很高，遂决定去看看这部动漫，结果确实没有让我失望，剧情，画面皆属上乘。（我是很少写动漫观后感的嗷） 动漫大体脉络还是男主龙傲天开局，但动漫整体风格偏阴暗，甚至可以说是残酷。人类也好，吸血鬼也好，改造人也好，每个人都有自己想要守护的东西，都想努力的活下去。 最难得可贵的地方是它能够将每个主要角色的形象和情感都刻画的非常丰满，真实。顺带提一句，剧中有多达10余个主要角色。 剧情不拖沓，但也没有太明显的类似一些动漫因为赶进度而过于激进的推进，节奏很舒服。 男主莱的人格塑造的很有魅力，为了大贵族的责任，甘愿承受百年孤独，直到遇到了因与吸血鬼抗争而身负重伤而逃入自己城堡的管家。 很优秀的一部动漫，十分推荐大家去观看！

影响性能的因素 对于一个游戏来说，它主要需要使用两种计算资源，CPU和GPU，他们会互相合作，来让我们游戏可以在预期的帧率和分辨率下工作。 所以，我们可以把造成游戏性能瓶颈的主要原因分成以下几个方面 -CPU – 过多的draw call – 复杂的脚本或者物理模拟 -GPU – 顶点处理 – - 过多的顶点 – - 过多的逐顶点计算 – 片元处理 – - 过多的片元 – - 过多的逐片元计算 -带宽 – 使用了尺寸很大且未压缩的纹理 – 分辨率过高的帧缓存 对于CPU来说，限制它的主要是每一帧中draw call的数目，draw call简单来说就是CPU在每次通知GPU进行渲染之前，都需要提前准备好顶点数据（如位置，法线，颜色，纹理坐标等），然后调用一系列API把它们放到GPU可以访问的指定位置，最后调用一个绘制命令，而调用绘制命令时，就会产生一个draw call，过多的draw call会造成CPU的性能瓶颈。 对于GPU来说，它负责整个渲染流水线，它从处理CPU传递过来的模型数据开始，进行顶点着色器，片元着色器等一系列工作，最后输出屏幕上的每个像素，因此CPU的性能瓶颈和 ...