Ayin

  又是一年阳炎日将近，时值刚参加工作，也是时候再来个硕士阶段的总结。毕竟记忆总是会随着时间慢慢消散的，我想我应当抽出一些完整的时间去把自己的所思所感记录下来。 关于自己  要自我评价的话，我觉得自己和pjsk的ena有些类似：恰巧有那么一点天赋，可以觊觎天才们那片殿堂, 却不够进入。从小家里管的比较严，市重点初中重点班，省重点高中重点班……一路都异常顺利。但高中时实在受不了家里的管控，自己私买了手机开始报复性打游戏：崩三，王者，FGO…..成功掉到了普遍班，玩了两年，学了一年，再加之高考发挥有点砸，最终只够双一流非热门专业。这对我来说算是一次很大的打击，还以为自己天赋异禀，只需略微出手即可拿下高考。这结果个人肯定是无法接受，故而去了周边县城复读一年，去的前夜以手机发了最后一条说说，便将其从窗外扔下。   那边是合作的培校，在图片右侧的老居民楼里，六点半跑操，十点半下晚自习。老师信奉棍棒教育，打骂是每天日常，不论男女。个人当时喜欢在晚饭的半小时隔着铁丝网看下方的居民区：街灯一点点亮起，楼中传来炒菜声，小孩在巷子里打闹…...

开篇  资源保存大概是引擎里最不显眼但最折磨人的部分。渲染有画面，物理有碰撞，脚本能写玩法，资源系统做对了往往没人注意，做错了就是“我昨天还能打开的场景今天怎么全丢引用了”。   最早项目小的时候确实可以偷懒：图片按路径加载，脚本记文件名，场景里直接写资源路径。只要文件不改名不移动，问题不大。但这显然不是编辑器项目的常态。资源会整理目录，Prefab 会复制，材质会换 Shader，Demo 做着做着文件夹就会开始膨胀。   所以最后还是得做 AssetDatabase、.meta、GUID、Scene 序列化和 Prefab。听起来有点像 Unity 那套，实际上小引擎做到这个阶段也很难绕开这些东西。 路径不是身份  路径引用最大的问题是路径太脆。比如一张图原来叫： 1Assets/Sprites/Bird.png   你把它挪到 Assets/Sprites/Characters/Bird.png，它本质上还是那张图，但所有保存旧路径的地方都会失效。场景、Prefab、材质全...

开篇  最早写 Ditto 渲染时没什么包袱，OpenGL 能画就行。毕竟引擎起步阶段需要的是“屏幕上有东西”，只要能把 mesh、sprite、UI 画出来，Editor 看着像那么回事，其他都可以往后放。但这种写法很快就会到头。刚开始一个 Renderer 管全部还挺爽，后面一来 Game View、Scene View、RenderTarget，二来 Shader 和 Material 也要变成资源，再加上 DX12、Vulkan 这些更为现代化后端，原来那套 OpenGL 直连就有点撑不住了。继续往里塞只会变成一坨“能跑但没人敢改”的代码。   所以后面就把渲染层抽象成了 RHI，Rendering Hardware Interface。名字听着挺高大上的，但实际想解决的问题很简单：上层无需在意底层到底是 OpenGL、Vulkan 还是 DirectX 12。 为什么要抽 RHI  RHI 并不是为了显得架构高级，毕竟这次抽象确实是被需求推出来的。上层真正需要的是创建，绑定，绘制这些高层的指令，这些需求如果全写...

开篇  之前文章中讲述了引擎的初始架构和基础渲染、物理模拟与并行化，本想告一段落专心论文春招的，但某天刷到了隔壁的Krystallos Engine。就是一种很奇妙的心态，觉也睡不下去了，肝了一周有了这次大改。   上一篇已经把引擎的基本框架搭起来了，也有了一个能跑的Editor界面。但到这个阶段其实还挺尴尬的，它看起来像个引擎，用起来却更像一个 C++ Demo 框架。但不能所有逻辑都在引擎层做，支持用户层自定义脚本才能赋予创作自由和权责分离。   所以脚本系统就绕不过去了。Unity 用 C#，Godot 有 GD Script，UE 虽然主力是 C++，但蓝图本质上也是把 gameplay 逻辑从底层代码里拎出来。个人小引擎当然没必要一上来整套蓝图虚拟机，能把程序跑起来、访问常见组件、在 Editor 里调字段，就已经能让项目开发体验跨一个台阶。这里最后还是选了 C# + Mono。原因倒也简单：个人之前主用Unity，C# 语法舒服，Mono Embedded API 虽然有点老旧但资料多，自己折腾起来也不至于完...

后记：这篇就不大动了，毕竟写的就是 Ditto 最早那层骨架。后面几篇会按现在归档时更重要的模块重新排一下：脚本、渲染、资源保存，不再完全沿着当时的提交顺序走。 开篇前言可能是想试下目前能力极限，证明下自己还是没忘引擎的本，顺便备战春招；也可能是受动物井，Games104等的启发；还有可能是最近拆了Godot以及Jolt的设计感觉好像也没那么难。总之就是开始写自己小引擎，值此新年之际算是有了阶段性成果，故而才有了这个系列。 来的应该基本都是内行，这里也就简单介绍下功能：物体树状组织，组件赋予功能，场景序列存取。渲染采用OpenGL+GPU Instance，模拟采用线程池+工作窃取。然后重点再介绍下名称和图标，名称与宝可梦的多变怪同名，因为开始就想的以物理模拟为主，毕竟个人很注重游戏中的交互体验，反馈到技术栈上就是图形学的模拟动画。图标形象则主要取自洛克王国的多灵，大概是个人页游退坑前夕出的宠物，很喜欢其背景设定的“传说中灵魂的收集者，通过吸收其他宠物的灵魂，来塑造自己的身躯”，个人在写引擎功能架构时也多有借鉴成熟引擎的操作。 准备首先，在写之前应该对引擎架构及自己的能力有...

前言  前一篇Godot 物理源码分析把Godot内置的3D物理流程分析了下，接下来再扩展的话就是其在4.4版中集成的Jolt物理引擎了。本来想单开一篇介绍的，但看了下感觉Godot对Jolt也只是简易集成，功能方面与自己的已有的物理功能做了对齐阉割，性能方面接了个适配器又传回自己的通用线程池并行。与其介绍Godot中的Jolt，不如把两者独立开来，分别进行下介绍。   各物理引擎最为差异化的地方在哪？个人认为不在算法(Impulse, PBD)，而是并行化处理。如何构建调整Island，如何设计ThreadPool，这直接决定了效率，且不同平台上可能表现截然相反。以下就将展开这两点进行比较。 构造约束  先从较为简单的构造约束讲起，毕竟Godot这边的逻辑十分简单。前文介绍过仅分了区域，刚体和软体三处不同逻辑，简单来说区域部分就是逮着一个就扔进去（毕竟不进行计算），刚体是检测与其关联的刚体软体，软体只检测与其关联的刚体。  v而Jolt的处理相对就复杂些，执行的是8位掩码图分割逻辑，其中7位并行，1位非并行，...

前言  看引擎源码应该是引擎岗的基操了，且了解我的可能知道我主物理模拟。之前在项目组实习时改过Unity的源码，返校后就只能接触些开源引擎。UE的Chaos有些过重了：Init时Scene依次创建Scene、Solver、Evolution，Object依次RegisteEvent，CreateState，InitBody；Simu时先将游戏线程的AOS数据Push到SOA的物理线程中，经过一系列复杂的计算（毕竟个人比较在意移动端的表现）后将改动的脏数据Pull回去。而Godot的源码轻量，结构清晰，干脆就着拆解下3D物理部分。   看Godot最新版本4.5的文档其实还挺有趣的，如Godot的内存管理：对小对象采取预留空闲内存的堆分配，对大对象采取动态内存池 （用PooledList记录list和freelist）。与操作系统的分页选择截然不同，算是特化与通用的差异？以及Godot在21年发布的解释Godot为什么不基于ECS的架构和抽象层次的选择 （提供了一种新的视角，但个人其实不大认同，不过既然开源了有需要自己搭框架就好）。还有God...

前言  ML-Agents是Unity官方的一个强化学习框架，使用gRPC进行Python和Unity间的通信，让开发者得以仅在Unity中写C#，配置yaml训练参数就可训练所想要的模型 。个人在学习过程中找到的资料多为不兼容的旧版，故感觉还是有些必要记录下相关。 准备资源准备  参照官方文档，Unity端的话ML-Agents在Unity的Package Manager中可以直接安装。Python环境的话建议用Conda，毕竟Python3.10.1-3.10.12这版本要求还真不常见。之后克隆下官方Github代码库，键入 1234pip install mlagentscd /path/to/ml-agentspip install ./ml-agents-envspip install ./ml-agents   安装必要库即可。需要指正下cuda版本的torch不是刚需，这又不是练大模型，用Burst跑甚至兼容性更强。 大致用法  Unity代码中控制智能体的框架大抵如下。Heurist...

前言这几个月主要是在忙着秋招和硕士论文。承蒙之前我实习临座的那位AIGC工程师的关照，对AI有了进一步的了解，以及最后和他一前一后被开倒也挺有趣的。 整个秋招期间个人程序策划美术混投，多次被泡池子导致无缘同司的二志愿和补录。相反华为AI原本只是投着玩，倒是进展神速。这能怎么说，点AI春招接着转呗。现在想想和那些HR说话都太客气了，既然收到的多是冷漠而公式化的回答，那为什么不能同样冷漠而公式化的反制回去呢？说干就干，这就把冰冷的HR炼成我简历上温暖的项目。 准备前期研究总结而言有提示词工程，流程约束控制，RAG和模型微调四种方案。简单尝试了下光靠提示词的话稳定性不够，有时还会因文明礼貌的底层逻辑而拒绝任务；流程约束控制的话，风格这也不好写规则，评价是否足够冷漠而公式还得人工；RAG个人感觉主要是用于扩充知识库，冲不破它这文明礼貌的底层逻辑。所以最后采用的PEFT微调，在Ollama上运行验证。 方案 简介 优点 缺点 提示词工程 通过提示词描述表达规则，引导模型生成符合的文本。 实现简单，适合快速验证。对模型与部署环境无侵入。 风格稳定性有限，易受上下文影响。难以保证长...

前言  奇怪的技术栈招来了奇怪的暑期实习岗，概括而言目前作为技术美术在主导某个小游戏项目: 写策划案立项，做程序功能架构及负责美术表现。等美术资源时实在无聊，顺手把项目UI画了些，再试着研究下给项目上个热更，也以此确立下后续代码，美术资源规范。 准备前期研究  热更可以分为资源热更和代码热更两块：目前资源热更方案底层都是AssetBundles，AB包管理繁琐故有Addressable以及YooAsset以此延伸，各家公司貌似也都在此基础上自己魔改作为资源热更方案。据说Addressable坑有亿点多所以选择了后者；而代码热更则有Xlua，ILRuntime，InjectFix，HybridCLR。Xlua之前项目用过注入式对Update不友好，ILRuntime看着还行但也要插桩，InjectFix的话疑似Xlua Plus但HybridCLR的代码一致和原生性能直接杀死了比赛。 资源热更方案 Asset Bundle Addressable YooAsset 简介 Unity的传统资源打包与管理方案。 Unity推荐的资源管...