你好，我是方圆
我之前做过 Web 后端开发，后来慢慢把更多时间投入到了自己真正感兴趣的事情上：
Unreal Engine、游戏开发、内容创作，以及创造属于自己的产品。
你可能也在这些地方见过我：
这个网站则是我专门用来记录 Unreal Engine 学习、开发与实践 的地方。
如果你也是一个 UE 学习者，我希望这里对你来说，不只是另一个“教程网站”。
我更希望它能够帮你解决几类实际问题：
- 看懂一个功能为什么这样设计，而不只是照着连节点；
- 遇到 Bug 时，知道应该从哪里开始排查；
- 少踩一些我已经踩过的坑；
- 从“会做一个 Demo”，慢慢走向“会设计一个系统”；
- 把零散知识变成真正能够在项目里复用的能力；
- 了解一个真实项目从想法、实现、失败、修改到最终落地的全过程。
我自己也一直还在学习 UE。
所以这里不会是一个“大神站在终点告诉你标准答案”的地方。
更像是：
我先去研究、去实现、去试错，然后把真正值得留下来的东西整理出来。
如果我花了几天才搞明白的问题，最后能帮你省下几个小时，那这篇内容就有价值了。
为什么会有这个博客
其实我一直都有写博客和做记录的习惯。
大概从 2019 年开始，我就会把自己学到的东西、遇到的问题以及解决过程记录下来。
最开始的原因其实很简单：
好记性不如烂笔头。
Unreal Engine 里面的东西实在太多了。
今天刚研究明白一个功能，当时觉得：
这个我肯定不会忘。
结果可能过几个月再回来：
等一下，当时这里为什么要这么写来着？
尤其是 Gameplay Framework、动画、GAS、材质、C++、各种编辑器工具……
学得越多，越不可能全部依靠脑子记住。
所以对我来说，写博客首先是在给未来的自己留下资料。
把一个问题真正整理下来以后，下次再遇到的时候，不需要重新从零研究一遍。
所以第一个原因就是：
把学过的东西沉淀下来，慢慢建立一个属于自己的知识库。
写出来，也是一次重新学习
第二个原因，是我发现：
“我觉得自己懂了”和“我能把它讲清楚”，其实是两回事。
有时候一个东西自己用的时候，感觉：
嗯，我会了。
但真正准备写成一篇文章的时候，就会开始遇到很多问题：
为什么这里要这样做？
有没有其他方案？
这个变量到底解决了什么问题？
如果不用这种方式会怎么样？
我要怎么解释，别人才能听懂？
这时候才会发现：
原来自己有些地方只是“会操作”，并没有真正理解。
所以写博客对我来说，其实也是一种学习方法。
它会逼着我重新整理：
这个知识到底是什么、为什么这样设计、前后之间是什么关系。
我一直比较认同一句话：
如果你能够把一件事情清楚地讲给别人听，说明你自己大概率也真正理解了它。
当然，真正理解并不意味着永远不会错。
随着经验增加，我也可能发现以前的一些理解不够完整，甚至直接推翻以前的做法。
但这同样是学习的一部分。
所以写这些内容，也是在训练我自己的：
- 写作能力；
- 表达能力；
- 讲解能力；
- 信息整理能力；
- 对技术问题的理解能力。
某种意义上，你看到的一篇教程，也是我逼着自己把一个问题重新想明白之后留下来的结果。
如果顺便还能帮助别人，那就更好了
第三个原因，就是希望这些内容除了帮助未来的自己，也能够帮助其他正在学习 Unreal Engine 的人。
因为我自己学习 UE 的过程中，也看过大量别人免费分享的文章、视频和教程。
没有这些内容，我自己也不可能一路学到现在。
所以如果我已经花时间把一个问题研究清楚了，再把它整理出来，也许就能够让后来遇到相同问题的人：
少查一点资料，少踩一个坑，少浪费几个小时。
我觉得这件事情本身就很有价值。
而且互联网还有一个很有意思的地方：
你今天认真写下的一篇文章，可能几个月、几年以后，还有一个完全不认识的人通过搜索找到它。
然后它刚好解决了对方的问题。
一篇内容发出去以后，并不会像完成一次工作一样立刻结束。
它还可以继续被搜索、被阅读、被引用、被分享。
所以我也越来越觉得：
写过的内容，本身也是一种属于自己的长期资产。
它不仅记录了我学过什么，也记录了我一路是怎么成长过来的。
时间久了以后，这些文章、视频、项目和产品会慢慢组合成：
别人认识我的方式，也是我自己的作品集。
网上教程很多，但我还想多讲一个“为什么”
当然，Unreal Engine 的教程其实已经非常多了。
网上有很多非常优秀的作者，也有大量写得很好的文章和视频。
所以我并不觉得：
网上没有教程，我必须再写一份。
真正让我想继续写的一个原因，是我自己在学习过程中经常遇到一种情况：
教程本身没有错，而且你照着做确实能成功，但看完以后还是不知道为什么。
比如教程告诉你：
创建一个变量。
添加这个节点。
在 BeginPlay 里调用这里。
然后把它接到那里。
最终功能跑起来了。
但如果你再问：
为什么这个变量应该放这里？
为什么应该用这个节点？
为什么这段逻辑放在 Character，而不是 PlayerController？
有没有更适合大型项目的实现？
如果需求发生变化，这套方案应该怎么改？
可能教程就结束了。
这也是我自己非常想改进的地方。
所以如果我要写一篇教程，我会尽量不只是告诉你：
“怎么把它做出来。”
我更希望多往前走一步：
“为什么要这样做。”
如果能够再多走一步，那就是：
“以后遇到类似的问题，你能不能自己推导出答案。”
我觉得到了这里，一个教程才真正开始从：
教你完成一个功能
变成：
帮助你建立解决问题的能力。
所以现在再回头看，这个博客存在的原因其实很简单：
记录自己学过的东西，避免忘记；
通过写作逼自己真正理解；
把踩过的坑分享出来，帮助后来的人；
同时让这些内容慢慢成为属于自己的长期资产。
对我自己有用。
如果刚好也对你有用，那就更好了。
而如果有一天，你因为这里的一篇文章真正理解了一个以前一直没搞懂的问题，甚至以后不再需要这篇教程，也能够自己解决类似的问题——
那可能就是我最希望看到的结果。
如果你正在学习 Unreal Engine
这个博客会涉及很多 Unreal Engine 相关内容，例如：
- Gameplay 开发
- Blueprint 与 C++
- Gameplay Framework
- Enhanced Input
- GAS
- 动画系统
- Niagara
- 材质
- 编辑器工具
- 插件开发
- 项目架构
- 游戏开发中的问题排查
- AI 辅助 Unreal Engine 开发
但我不希望这里只是一个不断堆知识点的地方。
相比“今天学一个节点，明天再学一个节点”，我更希望这些内容能够慢慢帮助你建立几种长期能力。
把“为什么”讲清楚
有些 Unreal Engine 内容本身并不复杂。
真正困难的是：
你不知道为什么要这样设计。
比如一个系统能跑，不代表这个设计就是合理的。
一个逻辑放在 Character 里当然也能实现，但以后功能越来越多，会不会开始耦合？
Blueprint Communication 有很多方式，但什么情况下应该用 Interface，什么情况下更适合 Event Dispatcher？
一个功能直接写死最快，但如果下一关、下一个角色、下一个项目还想继续用怎么办？
这些问题往往不会在“5 分钟快速实现某功能”的教程里出现。
但它们会在你真正做项目的时候出现。
所以我会尽量从：
使用场景、职责划分、系统设计、可维护性和真实项目
这些角度去解释。
我自己也不喜欢那种：
你先照着做，不用管为什么。
因为需求稍微变化以后，照抄出来的东西通常就不够用了。
理解背后的逻辑，才有可能真正把知识变成自己的。
帮你少踩一些已经有人踩过的坑
真实开发通常不是：
想到方案 → 写完代码 → 一次成功。
更多时候是：
想到方案
↓
实现
↓
发现不对
↓
找原因
↓
修改
↓
又发现新的问题
↓
推翻一部分重新设计
所以我越来越觉得：
失败的方案，有时候和最后成功的答案一样有价值。
如果一个问题值得记录，我会尽量留下：
- 最开始为什么这样设计；
- 实际运行以后出现了什么问题；
- 哪个判断后来发现是错的；
- 我是怎么定位问题的；
- 最后为什么换成另一种方案；
- 这个问题以后应该怎样避免。
因为对于读者来说，真正有价值的不一定只是：
“最终答案是什么？”
有时候更重要的是：
“如果我也遇到这个问题，我应该怎样思考？”
如果我已经花了几个小时甚至几天，把一个坑完整踩过一遍，那么最好不要让每一个后来的人都再重新踩一次。
从 Demo 走向真正可以复用的系统
我现在非常关注另外一个问题：
这个功能做完以后，下一次还能不能继续用？
因为如果一直跟着教程做 Demo，很容易出现一种情况：
好像什么功能都做过，但真正开始自己的项目以后，还是不知道应该怎么组织。
所以这里以后会越来越多地关注：
- Gameplay 系统应该怎样拆分；
- 哪些功能值得组件化；
- 数据和逻辑怎样分离；
- 蓝图之间怎样降低耦合；
- 功能怎样支持扩展；
- 一个系统怎样迁移到其他项目；
- Demo 怎样逐渐变成真正可维护的东西；
- 做完一次以后，怎样让它成为自己的长期资产。
如果你最终想做的是自己的游戏，而不是永远跟着教程复刻 Demo，那么这些东西会越来越重要。
我希望这个博客最终能够慢慢形成一套：
我自己也会长期使用的 Unreal Engine 知识库和开发工具箱。
而如果你也能从这里找到某个可以直接解决当前问题的思路、方案或者参考，那就更好了。
我也在真正做项目
除了做教程，我自己也一直在开发东西。
因为我越来越不希望自己的 Unreal Engine 学习停留在：
这个功能我会做了。
我更想知道：
这些知识组合起来以后，到底能不能真正做成一个产品？
现在我会持续尝试：
- Gameplay 系统
- 游戏项目
- Unreal Engine 插件
- 教程项目
- 可以长期复用的开发资产
而这些项目对这个博客最大的意义是：
这里的很多内容，不只是为了写教程才临时做一个示例。
很多问题本身就是我在真实开发过程中遇到的。
所以你会看到的不只是：
“这个功能怎么实现？”
还可能包括：
为什么最开始的方案失败？
为什么测试通过了但实际效果仍然不对？
为什么一个模型可以，换一个模型就失败？
为什么一个看起来合理的架构后来必须重构？
这些事情，往往才是项目真正开始变复杂以后最难处理的部分。
EasyAutoRig：从教程思维走向产品思维
其中一个我投入时间比较长的项目是 EasyAutoRig。
它的目标是帮助普通开发者，更方便地把人物模型绑定到 UE5 标准骨架。
它涉及到了：
- 骨架生成
- Landmark
- 自动蒙皮
- 权重算法
- Twist Bone
- 物理资产
- 验证系统
- 自动化测试
- 不同模型之间的兼容
这个项目让我非常明显地感受到：
做一个教程 Demo，和做一个真正能够交给别人使用的产品，是两件完全不同的事情。
教程里很多时候只需要证明：
它能跑。
但一个产品还需要面对：
换一个模型还能不能跑？
输入不符合预期怎么办？
出错以后怎么告诉用户原因？
修改一个问题以后会不会破坏另一个模型？
怎样测试？
怎样避免回归？
怎样维护？
怎样继续升级？
这些问题其实同样适用于很多游戏系统。
所以即使你没有准备开发插件，这些开发记录里关于：
架构、调试、测试、回归、可维护性和产品化
的思路，也可能对你自己的游戏项目有参考价值。
这也是我愿意记录这些过程的原因。
AI 正在改变我的开发方式
EasyAutoRig 还有一个比较特别的地方。
它也是我第一次真正长期使用 AI 协助开发一个复杂产品。
现在很多人看到 AI 编程，会觉得：
把需求告诉 AI，然后代码就自动完成了。
但真正做复杂项目以后，我发现远没有这么简单。
AI 确实能够大幅提高开发效率。
但真正决定项目能不能继续推进的，仍然包括很多人的判断：
- 问题到底出在哪里；
- 一个复杂任务应该怎样拆分；
- AI 给出的设计是不是合理；
- 代码能编译，是否意味着逻辑正确；
- 测试应该怎样设计；
- 日志应该记录哪些信息；
- 为什么一个测试样本成功，另一个却失败；
- 修改一个问题以后有没有产生回归；
- 什么时候应该继续修改；
- 什么时候应该承认当前方案方向就不对。
所以以后这里也会出现一些：
AI + Unreal Engine 开发的真实实践记录。
如果你也正在使用 Codex、ChatGPT 或其他 AI 工具做开发，我希望这些内容能够帮你看到的不只是：
“这个 Prompt 很厉害。”
而是：
一个真实项目，到底应该怎样和 AI 长期协作。
包括哪些事情 AI 很擅长，哪些判断仍然需要自己做，以及怎样避免在看似效率很高的情况下不断积累技术债。
我自己也还在学习这件事情。
但正因为项目是真实的，所以遇到的问题同样是真实的。
免费内容和付费内容
随着做的事情越来越多，我未来也会制作一些 付费内容和产品。
比如：
- Unreal Engine 插件；
- 完整的 Gameplay 系统；
- 系统化教程；
- 可复用项目资源；
- 类似 Gameplay Practical Library 这样的内容产品。
我觉得这件事情没有必要避讳。
因为如果我希望长期投入时间研究、开发和制作高质量内容，那么它最终必须能够形成一个可持续的循环。
不过我希望免费内容和付费内容解决的是不同的问题。
免费内容帮助你理解和解决问题
博客、公众号、B站和抖音，我依然会持续公开分享真正有价值的内容。
比如：
- 一个系统为什么这样设计；
- 一个功能应该怎样实现；
- 一个 Bug 怎样定位；
- 一个开发方案为什么失败；
- 某个 UE 功能到底应该怎样理解；
- 项目里踩过的坑；
- 插件和游戏开发过程中的经验。
如果一个问题适合通过一篇文章讲清楚，我会尽量把它讲清楚。
我不希望采用那种：
前面说很多，但最重要的信息故意留到付费内容里。
因为如果免费内容本身都不能真正帮助到人，别人也没有理由相信后面的产品值得购买。
所以：
免费的内容，本身就应该有独立价值。
付费内容帮助你减少整理和试错的成本
但一篇文章解决一个问题，和把整套东西真正整理成可以使用的成果，是两件不同的事情。
比如一篇免费文章完全可以讲清楚：
为什么一个交互系统适合使用 Actor Component？
但如果要把它变成一个完整、可以迁移到自己项目里的 Gameplay 系统，还要继续解决很多东西：
- 系统职责怎么拆；
- 接口怎么设计；
- 数据怎么组织；
- 蓝图之间怎么通信；
- 怎样支持不同交互对象；
- UI 怎么接入；
- 怎么扩展；
- 哪些地方容易踩坑；
- 怎么测试；
- 怎么迁移到其他项目；
- 文件怎么组织；
- 后续怎样继续维护。
最后还需要把这些内容：
实现、测试、整理、解释，并持续维护。
所以我越来越觉得：
真正值得付费的，并不是什么别人不知道的“秘密知识”。
而是：
整理、验证、系统化、复用性、维护，以及替你节省下来的时间。
如果一篇免费文章已经能够解决你的问题，那很好。
直接拿走这个思路，去把自己的项目做出来。
如果你刚好不想从零重新搭建，希望获得一个已经整理、测试、可以直接作为起点的完整成果，那么未来也可以选择我的付费内容或者产品。
这两种需求都很正常。
我希望把这些事情长期做下去
以前做教程的时候，我更多只是觉得：
这个东西我学会了，那就顺便分享出来。
现在我的想法发生了一些变化。
我希望有一天，这些事情不只是业余时间的兴趣，而是真的能够成为我长期投入的一份事业。
我希望能够继续：
- 学习 Unreal Engine；
- 研究 Gameplay；
- 做游戏；
- 开发插件；
- 写文章；
- 录视频；
- 研究 AI 开发方式；
- 做真正有人愿意使用和付费的产品。
而这件事情如果能够持续，对读者也会更有价值。
因为只有它本身能够产生收入，我才有可能投入更多时间：
研究更复杂的问题、完成更大的项目、做更系统的教程、维护更完整的产品。
我理想中的循环其实很简单：
免费内容帮助更多人理解知识、解决问题。
付费内容和产品帮助有更高需求的人节省时间、获得更加完整的成果。
然后这些收入又支持我继续研究、开发和分享新的东西。
这不是“用爱发电”。
而是希望慢慢建立一个：
内容对读者有用 → 产品解决更深的问题 → 收入支持继续创造 → 再产生更多有价值内容
的正循环。
如果有一天能够稳定做到这件事情，我会非常开心。
关于自媒体和内容创作
除了 Unreal Engine，这几年另外一件让我投入很多时间的事情，就是做自媒体。
从最开始只是：
把自己学到的东西发出来。
到后来慢慢开始接触：
- B 站
- 抖音
- 微信公众号
- 长视频
- 短视频
- 图文内容
- 选题
- 标题和封面
- 内容定位
- 平台分发
- 流量
- 用户需求
- 内容产品化
这个过程也让我意识到：
会技术、会表达、会做内容、会做产品，其实是完全不同的能力。
有的视频认真做了很久，结果没有几个人看。
有时候自己觉得只是一个普通知识点，反而会得到很多反馈。
有时候停更一段时间，再重新开始，也会发现：
下一条到底应该做什么？
这些事情本身也在慢慢影响我做 Unreal Engine 教程的方式。
比如：
怎样把复杂问题讲得更简单？
怎样判断一个知识点是不是真的值得讲？
怎样让教程不是看完就忘？
怎样把几十个零散内容逐渐组织成一个完整知识体系？
所以虽然这个网站主要还是 Unreal Engine Blog，但我在做内容、做产品和做自媒体过程中学到的东西，也会反过来帮助我把 UE 内容做得更清楚、更实用。
至于更偏自媒体、产品和个人成长的内容，我会更多放在个人网站或者其他更合适的平台。
我的目标
以前我给自己写过一个目标：
用 Unreal Engine 做出一款 Steam 好评如潮的游戏，实现财富自由。
现在重新修改这个页面，我还是不准备把它删掉。
只是我对它的理解已经发生了变化。
以前可能会觉得：
做出一款成功的游戏，然后就成功了。
现在我越来越觉得，真正重要的是培养一种更底层的能力：
持续创造真正有人愿意使用、愿意观看、愿意付费的东西。
可能是一款游戏。
可能是一个 Unreal Engine 插件。
可能是一套 Gameplay 系统。
可能是一门课程。
也可能是现在还没有想到的东西。
而对关注这里的人来说，我希望你能够看到的，不只是最后那个成功或者失败的结果。
还有中间完整的过程：
怎么学习，怎么判断方向，怎么做项目，怎么失败，怎么修改，怎么把一个想法慢慢变成真正的东西。
如果这些过程也能够给你自己的路提供一点参考，那就很好。
我希望自己慢慢从：
学习别人创造的东西
走向：
创造属于自己的东西。
如果你也正在走类似的路，希望我们可以一起。
这个博客以后会怎么更新
现在我的 Unreal Engine 内容主要会发布在：
目前整体上会以 微信公众号为主。
比较完整的技术文章、教程和学习内容，我会优先发布或者整理到公众号。
B 站和抖音则更多会发布视频内容。
这个博客不会强求固定更新频率。
我更希望把它当成一个长期的 Unreal Engine 资料库。
一些内容特别适合留在这里，例如：
- 篇幅比较长的技术分析；
- 不适合短视频表达的问题；
- 项目开发日志；
- 完整的问题排查过程；
- 插件开发记录；
- 在其他平台不太方便发布的内容；
- 值得长期保存和搜索的资料。
所以如果有一段时间这里没有更新，也不用奇怪。
我可能只是跑去写代码、做项目、录视频，或者又掉进了一个新的坑里。
等这个坑值得写的时候，它大概率还会回来变成一篇文章。
如果你关注我，能得到什么
如果你看到这里，还在考虑：
那我为什么要关注你？
我想给一个比较直接的答案。
如果你也在学习 Unreal Engine，我希望长期关注这里能够让你得到几样东西。
少走一点弯路
很多问题，我可能已经替你踩过一遍。
能留下经验的，我会尽量留下。
不只知道“怎么做”，还知道“为什么”
我会尽量少做纯粹的节点照抄，更关注背后的思路和系统设计。
看到真实开发，而不是只有漂亮结果
成功的方案会分享。
失败的方案、调试过程、重构和回归问题，同样值得记录。
慢慢建立自己的开发能力
我希望这里最终帮助你的，不是记住几十篇教程。
而是：
以后遇到一个新的问题，你开始知道应该怎样分析它。
获得可以长期复用的思路和成果
免费的文章可以成为参考。
更加成熟的内容，我也会继续整理成系统、资料和产品。
你可以根据自己的需要选择。
一起跟上 AI 正在带来的变化
AI 正在快速改变软件开发。
我也会把自己真实使用 AI 做 UE 项目的经验留下来。
哪些地方好用。
哪些地方容易出问题。
哪些东西看起来很厉害但实际并不可靠。
我们一起慢慢搞明白。
我不会承诺：
关注我以后，你很快就会变成 Unreal Engine 高手。
这种话我自己也不信。
但我希望能够做到：
我继续去学，继续去做，继续去试。
有价值的经验，我认真整理。
踩过的坑，我尽量留下。
值得免费讲清楚的问题，我就把它讲清楚。
值得产品化的东西，我就把它认真做成产品。
如果这些东西刚好能让你开发得更顺一点、少浪费一点时间、学得更明白一点，那你关注这里就是值得的。
如果这些内容对你有帮助
如果你看过我的文章、视频或者教程，而且其中某个内容刚好解决了你的问题，那我就会觉得这些时间没有白花。
如果愿意继续一起学习，也欢迎关注：
目前比较完整的 Unreal Engine 图文内容，会更多放在公众号。
公众号文章里偶尔也会有广告。
如果哪天刚好看到，也刚好有感兴趣的内容，可以顺手动动你的发财小手支持一下。
当然，不强求。
愿意阅读、收藏、评论、分享，或者以后遇到 Unreal Engine 问题的时候，还能回来搜一搜，对我来说都已经是支持。
如果未来某一天，我做的某个系统、教程或者插件刚好能够真正替你节省时间，那也欢迎用购买产品的方式支持我继续做下去。
我更希望我们之间最后形成的是一种很简单的关系：
我认真创造真正有价值的东西。
你从中拿走对自己有用的部分。
如果某个东西值得付费，再选择付费。
然后我继续拿这些支持去做下一批更好的东西。
最后
如果你也是一个 Unreal Engine 学习者、游戏开发者、独立开发者，或者正在努力做属于自己的东西：
欢迎来到这里。
这里不会只有标准答案。
更多时候，你会看到的是一个普通开发者不断：
学习 → 实践 → 犯错 → 找原因 → 推翻 → 重来 → 再理解
的过程。
但我希望这些过程最终不只是我的开发日志。
而是能够变成你的参考。
当你遇到类似的问题时：
能少踩一个坑。
能多理解一点为什么。
能少浪费几个小时。
能把自己的项目再往前推进一点。
那这篇文章、这个博客，就真正有意义了。
有用的，我们一起学。
新的东西，我们一起研究。
值得产品化的东西，我也会认真把它做出来。
希望几年以后再回来看这个页面的时候，我已经走出去很远。
也希望一路看到这里的你，同样如此。
继续学习，继续创造，一起变强。
然后继续寻找属于自己的 One Piece。