因为我认为这是一个跨工作室技术整合的有趣案例研究，涉及物理引擎架构、平台适配和设计哲学转移。

背景：

雷酷赛车是由NetEase开发的，官方合作公司为Codemasters的手机赛车游戏。2021年正式宣布，该游戏使用“Codemasters的专有的EGO技术” 伴随着UE4引擎。

EGO是迪RT系列、GRID和F1系列的专有技术。其汽车动态层被特定设计哲学所 characterization：连续物理模拟，其中汽车行为从建模的力上（重量转移、胎式摩擦曲线、悬挂几何）而来，而不是状态机或脚本动画。

架构问题：

如何将专有物理引擎（EGO的汽车动力学）整合到商业引擎（UE4）中，适配不同的平台（移动设备）？

标准的UE4汽车物理系统（基于PhysX）使用简化的胎式模型和悬停设置。如果CM贡献了EGO的汽车动力学，可能需要将UE4-default的汽车物理模块替换为自定义物理插件.— 从根本上讲，UE4用以渲染、资产管理和平台服务，而running下EGO的计算结果为汽车相关的计算。

可观察的玩家表现行为（来自附带截图的游戏）

经过游戏长时间的试验，并且参考社区分析，以下我所 catalogued 的行为：

重量转移：

刹车转移载荷向前→ 前胎抓地力增加，后胎抓地力减少（连续，非二元）

赛道进入转弯时打制动，产生旋转与持续制动力的比例增长

在转弯时中移动器，使后胎失稳通过未卸载重量

所有转移都表现出平滑曲线，非状态切换

胎式摩擦模型：

抓地力限制表现为连续曲线（可能是失速角slip-ratio基准模板）

失稳激发逐渐增加，其严重程度与过度输入程度相关。

不同地面状况改变摩擦曲线，非应用扁平乘数

温度影响出现在长时间的赛事里改变的抓地力范围

驱动系统不同式：

前驱：踩足油门，发生前胎失控

中驱：更高的切入率，旋转急剧增加

前后驱：在提速下，转向失控，稳定性第一，舍弃旋转

辅助系统架构：

关闭牵引控制会暴露出底层摩擦模型（逐渐失控、由油门精度调节），则会显示给玩家

稳定性系统改变哪些校正被应用，而不是物理。

本作读为一种模拟游戏，拥有通道和辅助的包围，而非轻骑车游戏可切换模拟或轻骑车模式

我的推断：

此行为表明的资料文件-连续物理，slide曲线-摩擦，驱动力几何不同，sim-style首先辅助一层的架构设计高度一致于EGO的基于游戏结构。 在迪RTRally中，关闭辅助系统不会改变物理，而是移除了自动校正。同样的architectural原理看起来也被运用在此。

问题：

如果您在UE4中整合专有汽车动力学模块，架构应该是什么样的？替代物理插件（重载PhysX）- 还是Middleware层向前提供力到UE4’s物理步骤？

在移动硬件上适配一个桌面目标的物理模拟，应该有哪些折衷和损失？减少模拟频率（60Hz → 30Hz）- 简化胎式模型（少了friction曲线点数）- 减少悬停个数？

从设计哲学上来说---汽车的“驾驶感受”来自物理模型本身还是上层调节calibration层？如果CM开发了它，而NetEase调节了参数，则“感受”归谁所有？