Zong's blog

前言零散的笔记，是我在学习过程中的思考，自认为简单的东西并不会记录在内。 Direct3D 基础初始化 D3DFactory 和 Device说实话 DirectX 中的架构思路真的值得去学习，这里的工厂和驱动都是蕴含了很多的设计思想的，但我目前还不能真正的理解。 WRAP应该不需要去写它的意义吧，猜猜就知道了。 命令个人感觉 CommandList 类似于资源描述符，而 CommandAllocator 类似于缓冲区，将 CommandList 中的命令传入 CommandQueue 中，但是 CommandAllocator 还是原来的，这也是为什么在 CommandQueue 的命令被执行完前不能重置 CommandAllocator。 渲染流水线目前这里指的就是普通的光栅化流水线。 这里特地拍了一张我在书上的笔记，是想展示一下数据的流向。 Step1 内存数据流向显存可以先到后面看一下流水线状态，可以发现主要就是绑定根签名表和 Shader，缓冲区都是在创建时绑定的，当然绑定的都是描述符，绑定数据的话带宽直接废掉了。 书里也说得很清楚了绑定的时候 GPU 会自动创建描述符 ...

前言不只是阅读《游戏引擎架构》的笔记，更多的是做引擎时的心得。 项目管理版本控制、项目构建等等其它方面的工具自选就行，好用就完事了。 引擎核心层引擎入口建立 Engine 的基类，同时在 main/WinMain 中创建 Engine，将其编译成 Lib 库后暴露给编辑器，编辑器通过继承 Engine 类以实现对引擎的配置。 1234567891011121314class Editor : public Engine{public: Editor() {}; ~Editor() {};private:};Engine* CreateEngine(){ Editor *editor = new Editor(); return editor;} 实例化引擎顺序书里面说要注意，但我觉得还好，不容易崩，实在不行就用书里面的优先级队列吧。 不过引用友元也是会初始化的，所以最好还是在 PreInit 或者 Init中完成。 事件日志管理和计时器这种都是自己想怎么弄都行，不会消耗太多性能，不同的日志和计时 ...

前言最近在写游戏引擎，在这里将主要记录一下如何架构跨平台的 Rendering Pipeline。 在大部分人眼中，这就是 Rendering Pipeline，但是其实这只能说是 Shader Pipeline，真正的渲染管线远比这更加复杂。 光栅化的渲染管线固定的渲染管线这是早期架构的渲染管线，因为引擎的交互还不完善，所以暂时不需要考虑动态的情况。 Rendering/ RenderingInterface.hpp Platform/ Windows/ WindowsRenderingPipeline.hpp WindowsRenderingPipelineState.hpp DirectXInterface.hpp Android/ AndroidRenderingPipeline.hpp AndroidRenderingPipelineState.hpp OpenGLInterfac ...

前言感觉自己一开始没有认真学，所以现在基础有点差，最近打算重学一遍，该手推就手推，不偷懒了。 这次主要是跟着 GAMES-Webinar 的课程学习，所以如果你想要看懂这份笔记，我建议先去学习相应的课程。 TransformationView transformation相机需要设置的参数。 将相机平移至原点并同时将 look at 和 up 及其叉乘共三个向量同时对其标准坐标轴的矩阵即为 View matrix。 唯一要注意的就是由于直接计算旋转矩阵比较复杂（从任意向量变换到标准坐标轴），所以先计算其逆矩阵（从标准坐标轴变换到任意向量）。 Projection transformation其实只要求从四棱台压缩到矩形的矩阵就行了。 直觉上其实很容易得出结论，难点在于求出相应的变换矩阵。 为了计算出来就得补充两个假设。 Any point on the near plane will not changeAny point’s z on the far plane will not change 解方程后也能求出来最后的投影矩阵（还需要用 FOV 和长宽比进行参数替代）。 ...

1 构建作品集与在线影响力 在GitHub或ArtStation发布项目代码与设计文档，撰写技术博客分析经典游戏机制（如《塞尔达》的物理交互、《文明》的资源平衡），吸引潜在雇主注意。 21. 理论基础：从设计原则到数学模型 核心概念 推荐学习材料 搜索到的《游戏平衡性设计原则》PPT（网页2）详细拆解了平衡性设计的方法论，如通过玩家反馈、数据分析和A/B测试发现问题。 《游戏设计心得——实现游戏平衡性的技巧》（网页8）提出“模块化设计”和“复杂性控制”原则，例如将游戏要素功能单一化以简化调整流程。 2. 技术工具：数据分析与快速迭代 数据分析工具学习使用游戏引擎内置的Analytics工具（如Unity Analytics）或第三方平台（如GameAnalytics），分析玩家行为数据（如胜率、资源消耗、流失节点），定位平衡问题。 数学建模工具结合计算机背景，用Excel或Python建立平衡性模型。例如，通过马尔可夫链模拟玩家决策路径，或利用博弈论优化多人对战的经济系统。 3. 实践方法：从原型到测试 小型项目实践设计一款简单游戏（如卡牌对战或平台 ...

前言个人认为 SuperHot 的核心是时间控制和回放，一个一个实现。 试了一下发现时间控制实现起来挺简单的，因为 Unity 已经提供了时间尺度（时间流速）的接口，所以只需要包装一下就好了。 代码暂时先不传，等后面的回放做完再一起传吧。 TimeScaleManager由于 UnityEngine.Time.timeScale 是 static 的，所以我这边用单例模式进行管理。 之后如果做成联机，让每个玩家都是独立的话，不知道难度怎么样。 12345678910111213141516171819202122232425262728293031323334353637383940414243public class TimeScaleManager{ // Singleton instance private static TimeScaleManager _instance; // Data private float _timeScale = 1f; public static TimeScaleManager Instance & ...

前言项目已经传到 github 上了 https://github.com/zong4/SuperHot，3D 版本的会在后续上传。 3D 的版本已经上传好了，推荐阅读 3D 版本的代码，更加优美和完善。 回放的话其实不外乎两种方法，分别对应了服务器的两种状态同步方式：帧同步和状态同步。 帧同步的话就是每一帧都记录所有玩家的输入，然后回放时重新执行一遍。 状态同步的话就是每一帧都记录所有玩家的状态，然后回放时直接把状态设置过去。 因此我们也可以同样的通过记录每一帧各角色的信息或者输入来实现回放，但是由于帧同步就意味着要重新模拟一遍世界，所以我这边现用了实现起来简单的状态同步。 ControllerManager那不管是哪种方法，我们都需要一个 ControllerManager 来管理所有的角色。 我这边由于是状态同步，所以记录信息的任务就统一交给 ControllerManager 来做，在 LateUpdate 中收集所有角色的信息并保存。 其中 Action 中的 Time 是为了在实现 wait 的，从而保证回放时的时间间隔和录制时一致，这里我为了方便才把它放在 Actio ...