尔东巾1. 游戏调试面板的演进：为什么最终都选了Dear ImGui
1.1 保留模式GUI的痛，做游戏工具的应该都懂
做游戏开发的人，或多或少都被“调试参数”这件事折磨过。早期团队做第一人称射击游戏的原型时，我想调一下角色移动速度、重力加速度、子弹伤害这几项数值。传统做法是什么样的？改代码、重新编译、重启游戏、跑到指定场景、看效果，不满意再回来改代码。一轮下来快的时候也要一两分钟，慢的时候五六分钟。最崩溃的是，好不容易调到“手感不错”的状态，你还要把数值抄回代码里，重新编译一次确认没有把数抄错。
团队后来引入过一个基于Qt做的外部工具，把常用参数放到窗口里，通过进程间通信或者文件读写的方式和游戏本体交换数据。这个方案能在一定程度上解决问题，但维护成本很高：引擎里新增一个可调参数，工具那边也得跟着改界面；热更新逻辑稍微没写好，进程间通信就会丢包或者阻塞主循环。做工具的时间比节约出来的调试时间多得多，得不偿失。
1.2 即时模式：每帧重画，反而省心
第一次接触Dear ImGui是在同事的demo里，他打开游戏一个隐藏面板，里面有一堆拖拽条、复选框、下拉列表，鼠标拖一下数值，画面里的光照、雾效、粒子密度当场就变了。我当时的第一反应是：这个面板是用什么引擎写的？他告诉我就一个C++库，叫Dear ImGui，直接嵌在游戏进程里，不需要额外起进程，不需要消息协议，不需要维护控件状态。
Dear ImGui采用即时模式，这个设计思路和传统保留模式GUI是两个方向。保留模式里，你创建一个按钮，按钮这个对象一直活着，事件由框架分发给回调函数；而ImGui里没有“按钮对象”这个概念，你每一帧调用一次ImGui::Button("Play")，它返回一个bool告诉你这一帧有没有被点击，下一帧再调用一次，再次返回结果。开发者在代码里写的是一堆“立即执行”的界面描述语句，而不是一层持久的控件树。这个差异在普通桌面应用里可能感受不明显，但在游戏调试工具这个场景里是降维打击。
1.3 不是Silver bullet，但已经是行业“隐形标准”
当然，即时模式GUI不是万能的。它没有完整的无障