云风的 BLOG

CEGUI的设计思路现在也是“布局+皮肤”两部分，布局描述各个UI的盒式布局，皮肤描述各个UI元素的显示样式。这种思路看起来很好用，但是我们的产品经常吐槽要自定义某个按钮的样式的时候，得拷贝一份皮肤配置来修改，对于很多经验不多的开发者来说，也是一个很痛苦的事情。HTML+CSS的方式似乎是目前最为灵活的方案，但这个对于游戏来说过于重度，期望能有个简化版的布局样式系统能真正应用到游戏里。

常年使用FairyGUI，UI重在工具链

@operali
你怕是对div+css、react、vue有什么误解……

UI，
一件看似容易却从来不容易的事，很多人说，游戏制作有很大的工作耗在上面（这里指程序员工作量）
UI 为何困难，以html为例, 用div+css直接制作UI,效率其实甚低（缺少抽象组合能力，所以早期那种单调风格的web), 后来有reactjs,vue 这些结构化UI，大大提高了webUI开发效率和可重用性，大家也倾向于制作高度交互，精美的UI了，
vue用作实现编辑器或是游戏UI困难吗，恐怕没什么差别，
今天的游戏UI变得越来越复杂，也有了很多数据可视化的需求，甚至，我期待编辑器创造也会是游戏乐趣的一部分

@Cloud

感谢百忙之中回答。路线不一样我认为主要是目标的差异。我的目的不是做一个通用的游戏引擎，而是为了写现在手上的游戏，基本上是想到哪写到哪。

您的大部分观点我都是认同的。我也不喜欢很大的东西，也许Reactphysics3d会是一个更好的选择（谢谢推荐，后面会去看下能不能更好的换掉我现在的模块）。bullet方面，我主要说的是bullet2，我看blender内部的代码用的就是2，好像体积和复杂度方面也很小。

对于第三方库的选择问题，我觉得最重要的还是功能性代码的可控和可扩展，bullet2内部使用的一套vector math就已经被我换成我自己使用的mathfu，但是IK方面和骨骼动画的结合现在解决起来也很难受。（librocket内部估计也会被很愉快的换掉。对包体积我觉得我可能有点执念一类的玩意，另外实现同样的功能的代码在codebase里出现多次看着也挺难受的）。对于freetype这种纯数据到数据的处理，我觉得可控性可能不是那么重要（不过他的一些东西也被我砍掉了，因为harfbuzz的交叉编译起来太恶心了）。

对于动态语言的问题。
* 我觉得主要还是我当时太年轻了，这个项目最开始是我上大学的时候开始写的，一开始想的是如何更好的利用到多核更快的加载资源，对此来说js的异步逻辑写起来真的挺舒服的（c++的话我得写future + thread + 某个任务class，没有引用元对象的存在我估计写代码会写的很辛苦）。但是我后面发现js没有操作符重载，自己上手改v8和jsc我估计也改不动，所以才会在多个动态语言之间纠结。最近打算看一下quake3的gameplay通用模块然后再考虑一下。
* 对于lua，我一开始试着用它的协程去解决音频解码的一堆坑爹回调问题（苹果的AudioToolbox产生数据真的成谜），后面发现好像直接在c++里写用指针取址测量一下用到的最深调用栈大小直接写在c++里可能是个更好的选择。
* 最后琢磨了一下似乎把flutter的fml拆出来直接用c++写算了，也不用考虑写binding的问题。脚本语言可以在真正产生问题的时候再拿出来考虑。

对于shader和图形api。
* shader的话，我觉得我可能没太表述清楚。我认为宏可能已经够用了（至少对于我来说）,前面对于slang那些项目的使用也只是尝试。我现在是用一套对于glsl来说添加了include的工具链，写完了一套简单的延迟渲染（前向的透明部分还没做）+ 一堆后处理特效，光照模型也在向pbr改。（前面一直在解决gbuffer部分包含了对于skinned+morphed两种动画存在于同一个mesh的组合这样比较复杂的情况。）
* 在多次试过D3D12\Vulkan\Metal这些玩意的糅合之后，我放弃了，因为我意识到糅合这些玩意的成本远大于我对于这些api单独写一些能更简单描述一个渲染器的方法，然后直接去写渲染器。
* 我觉得对于RHI的模拟和类似ShaderLab的方案对于游戏引擎这个需要生态的方案来说可能是必须的。但是对于我现在来说，单独写一下似乎并没什么。

@foxerzhou

谢谢分享。看下来你的路线和我的差得非常远。我列一下我的选择，可能没什么参考价值。只能代表我的个人想法，没什么对错。

脚本方面，对于我来说，不太可能有 lua 以外的其它选择。其实我并不把 lua 看成是脚本，而承担的是整个开发任务。在和 C/C++ 嵌入协同工作方面，我看不到有任何别的动态语言可以取代。

我觉得在 3d 开发方面，不应该把精力放在动态语言的性能上。所有性能问题最终都能克服的。不能克服的也不会是语言的问题。单说用 lua 开发，不同的写法不同的设计，就可以轻易差 10 倍以上的性能。选用 lua 本质上选择的是 lua 的数据模型：即把所有的数据结构用 lua table 表达，即使是最终用 C/C++ 去操作这些数据，也访问的是 lua table 。这通常不会比访问一个 struct class array 有数量级上的差距。

而原本 3d 游戏，GPU 本来就可能将承载 50% 甚至 80% 的工作，所以不必太看重 CPU 上的开销。把它看作是固有的性能牺牲，会换取到其它价值即可。如果出了性能问题，也不要急于归结到语言上，更不用绕开具体实现，去找 jit 这样的方案。能解决性能问题的，往往是对问题的重新分析，找到适合该开发语言的具体方法重新解决。Lua 留的口是方便你写 C 扩展。但写 C 扩展的前提是对问题的拆分，把热点真正分层剥离出来。

物理库我个人觉得 bullet 已经不错，但还是庞大。我不喜欢复杂的东西。所以我更推荐 Reactphysics3d 。我觉得第三方库的代码规模还是在自己可能把控的范围内会比较好。评判标准是：如果这个库的原作者放弃维护了，你自己有没有兴趣和精力接手下来延续下去。

shader 方面，我暂时接受 bgfx 的方案。可能是我还没有到写复杂的 shader 的时候，只实现了一套简单的 pbr 的流程。因为很多可变的东西是用宏实现的，我们只在工具链上稍微加强了对宏的支持。这个以后发现需要定制更复杂的 DSL 的时候，再考虑一个更完善的方案。btw, 我和 bgfx 作者交流过。他也觉得有个比宏更高级的 DSL 会有用，但是现在并没有强烈的应用上的驱动力去设计这么一个东西。

我自己和朋友私底下写点游戏，参考了一下您引擎的技术方案，这边也有点想法，想和您交流一下，请不吝赐教。

1. 前面也尝试抽象了RHI，也参考了下UE的源码，感觉还是直接写renderer的形式来直接做游戏会比较好用。后面也可以根据各大api的特性做特定优化。当然您这边引擎需要考虑开发者和通用性可能类似ShaderLab的形式更好些。

2. 另外感觉统一shader语言坑也挺大的。。。前面去做spv->msl的时候感觉很多行为都对不上。也尝试过一些包括slang、bgfx、glsl-opt这样的东西，最后在看smaa的代码的时候，看到他用宏的形式去做了抹平，尝试了一下感觉自己写游戏还是挺好用的。

3. 脚本选取的方面。
* 首先尝试了tcc，主要是想在后面写逻辑的时候辨明白经常更新的逻辑和变动逻辑之后直接就可以把那部分代码改成编译的，但是纯c代码写的很长还是太痛苦了（见vulkan）。。。
* 用过js，前面用用FloatArray/Int32Array和函数ID的模拟堆栈的形式写context在单线程里做Box2D和WebGL的更新，感觉效率还可以，后面感觉iOS上必须要用jsc，android上不用v8开jit感觉还是亏了，这样得写两层binding或者把两个vm的api抹平感觉还是很麻烦。
* python我以前写的很多科学计算，感觉在库扩展方面很好，一些Profiler图片什么的生成一下都很轻松，但是带一堆包什么的还是算了，不知道是不是错觉，感觉blender的py-api就不是那么好用。也看了下AS3和avm2，他也支持AOT了，暂时观望。另外感觉as的使用链路太长了，。
* 对比下来，感觉还是js可能会比较方便（尝试玩过quickjs，不知道能不能直接用在工程里），感觉做一些polyfill一些写ui的形式都可以直接拿来用（不知道redux的状态模式拿来写游戏逻辑会不会很好用），虽然网页这边ui很大一部分都是adobe的延续（mxml和jsx差的真的不大。flex感觉甚至更好用一点。），但是js的异步更新（promise、await）这些写ui和逻辑还是更舒服。

4. 音频
* 这地方感觉现有的东西都没什么比较好用的。所以直接Apple设备用CoreAudio、Win上直接用WinMM，Android上OpenSLES（也许可以在Api-21以上用AAudio替代？）去做系统级别的播放节点。然后写个resampler混个音，转换一下psm数据格式。codec方面，不知道opus会不会比ogg更好用一点，不过听说主要是rtc方面的编码和人声的效果更好，如果存在配音的数据包的话，估摸着应该更好用。
* 尝试过OpenAL和android上的OpenMAX，感觉对于游戏来说都不是很好用。
* 游戏方面很多都是需要重用的效果音，还有就是一个基本不会变的bgm，做的更好一点大概还要把hrtf加上，像是一些ns、aes类的效果我觉得作用反而不是很重要。OpenAL以OpenGL的形式写起来感觉也很麻烦。
* 另外自己做这个感觉以流式去做音频数据decode也很舒服，内存占用能少不少。甚至于网络传输也可以边传边播放。

5. ui算是个麻烦事。。。
* nuklear和OpenGL基本绑死了。
* NanoGUI写起来代码量感觉要死，c++ lambda的形式直接让我现有逻辑涨了将近3M，最坑的还得编译。嵌入已有项目改起来也挺麻烦，因为和GLFW也绑死了。
* imgui倒是很好用，但是如您所说，ui定制化方面和字体方面非常难受，看了看代码结合了一下android的libhwui的字体处理，感觉工作量要炸了，拿来做调试ui感觉还是挺不错的，而且他本来也是这个定位。
* webkit改的吐血。。。甚至于后面甚至想我们本来就是私底下做着玩玩，把opera presto的泄漏代码拿来改改，但是发现他那一套给予yaml的客户端代码改起来也很要命。。。
* netsurf看代码也是看的很难受。。。
* gnome的那一套东西都是基于glib的，他们甚至搞出来vala来写这个，c代码混着宏，感觉又回到了最开始我看blender愚蠢的想把blender-ui代码拆出来的日子。
* 最后甚至于前段时间还想试试flutter，一看它的ui代码全在dart里，随后就完全不想看了。
* librocket是很久以前发现的，但是因为我手头主力开发都是在osx下完成的。Apple又在10.14以后完全干掉了32bit，导致我根本跑不起来用Carbon写的librocket的例子。自己用libgumbo + libcorco搭了一套，感觉自己写需要的标签往上加东西也很麻烦。最后狠心用glfw换掉了librocket里shell的实现，感觉还是好用。现在先用固定管线画着，后面再用nanovg换掉他的渲染底层。RmiUI我看了一下，多了动画我觉得是很好，但是感觉后面对librocket熟悉了之后可以用lottie去做ui动画甚至一些简单的2D tween动画跟舒服点，美工对ae也更熟悉一点。甚至于后面还可以把facebook的libyoga加进来，支持flexbox的排版。不过感觉css2 百分比 + 像素偏移的形式去做可能大多数场景应够用了。

6. 物理
* ode和bullet，感觉似乎都是很好的选择，3D物理的底层我还真没写过，但是看操作模式似乎和box2d差不太多。
* 反向动力学方面，因为狠下心来把libfbxsdk的skinned、morphed动画都按着它demo拆出来用shader画出来了，感觉问题也不算太大。
* 另外看了叶劲峰大佬《爱丽丝疯狂回归》的海飞丝发丝效果，确实挺想写出来试试。

7. 粒子
* 这个Houdini最强，但是他的脚本完全没写过。fbx的粒子部分并不能导出。
* 另外打算看一下UEViewer这个项目能不能直接从ue里提出来粒子。
* u3d的粒子信息是yaml封装的，感觉要完全还原还是挺麻烦的。
* 最后 https://github.com/fredakilla/spkgen 这个粒子编辑器感觉还挺小的，qt写的界面，感觉扩充一下似乎还是可以用的。

总的来说，感觉还是写游戏的时候感觉缺了哪，就去加哪的代码。。。有一段时间美工大大比较忙，我完全脱离游戏去写功能感觉完全不知道在写什么。。。

如果云凤大佬您看我废话到了这里，真的感谢= =，如果有什么意见能提出来让我少走一点弯路就更好了。。。

P.S. 大概触景生情看您写的文章有感于此，废话的有点多了。
最后吐个槽，stellaris的资源一个一个分开的，甚至于音效也是。。。游戏加载好慢。。。

真巧，我刚把librocket的代码逻辑分块，改了glfw在osx上跑起来。但是他底层应该还需要些抽象，打算接上nanovg然后换掉它那个功能有限的render interface。

就等云风大哥的游戏引擎一统国内游戏客户端开源引擎了
光大Lua

这引擎有点666 嘿嘿

云凤大哥是否有了解过FairyGUI？无论开发游戏还是开发工具，都能胜任。甚至还有纯lua的sdk。
另外，字体动态贴图这个，在FairyGUI for threejs里有一个简单的实现，为了效率，只能使用简单的bin packing算法，所以贴图使用率不高，但rgb每个通道都可以用来画，等于3倍的使用率，解决了这个问题。

风哥这引擎啥时候能出来，甚是期待。

贴图、背景音乐太多，也是麻烦

Unity最新推的UIElement就是类似的html+css结构，而且准备editor+runtime通吃

云大既然用过wxwidgets，那么直接用xrc文件来描述是不是就可以了？

“布局+修饰+逻辑行为”好用。