我在过去六个月里从零开始构建了这个项目。后端使用 TypeScript 和 WebSockets（uWebSockets.js），前端则是纯 JavaScript，结合了 WebGL 和 DOM。
对于美国西海岸，往返时间（RTT）小于 100 毫秒，而东海岸大约在 150-200 毫秒之间。世界模拟运行在一个单一的权威服务器上，具备基本的二维物理引擎。客户端与一组水平可扩展的副本进行通信。副本是简单的聚合器，从不在主服务器之前进行模拟。每个副本都拥有完整的世界模拟状态，客户端根据真实世界的位置连接，而不是根据模拟世界中的位置。当用户在世界中移动时，不会发生切换。每个副本在体验开始下降之前，可以处理大约 1000 个客户端。
客户端会在主服务器之前进行模拟，以最小化感知延迟。我发现使用两个模拟并将它们融合在一起能够创造出最佳体验。虽然仍然会发生不同步现象，但游戏的设计减轻了其影响。例如，“对决”机制是基于累积的碰撞时间，因此不同步会导致结果的变化不那么明显。
对决（也称为迷你游戏）在一组独立的机器上托管。迷你游戏的用户界面显示在世界之上，因此尽管迷你游戏是一个独立的实例，你仍然不会觉得自己离开了主世界。
虽然我还没有进行过 10 万名真实用户的全规模测试，但各个系统的负载已经超出了所需的负载。
核心模拟可以在相对平稳的 50Hz 下处理 10 万个机器人。这些时间以毫秒为单位，来自一台 EC2 c7a.4xlarge 服务器：
- Wall（平均：19.999；标准差：0.575；最大值：22.919）
- Sim（平均：3.81；标准差：0.387；最大值：7.428）
- Emit（平均：1.028；标准差：0.368；最大值：4.174）
当我增加更多副本时，这些时间变化不大，因为副本连接是均匀处理的，并且在不同线程中进行。
返回首页
最新
我在许多网站上看到，比如……
* 英文: https://www.theverge.com/news/759016/tesla-in-car-graphics-unreal-engine
* 德文: https://www.golem.de/news/fahrzeugvisualisierung-tesla-soll-wechsel-zur-unreal-engine-planen-2508-199152.html
……提到特斯拉可能会从“Godot”引擎切换到“Unreal”引擎。
有没有已知的真实原因导致这样的切换？（例如，关于支持不佳、性能差、定制化困难、整体方法不当等……）
原因是：我刚开始寻找3D引擎（目前候选有Godot和Bevy，其他选项待定），这条消息让我想知道我是否应该对Godot“更加谨慎”……？