几月前，Split Circuit Arena 仍然只是一个想法：两个玩家控制一个战斗机器人一起玩。

现在，我们已经有了我们的第一款可玩原型、一个预告片和一个实时的Steam页面，但到达那里需要经过大量的测试、丢弃一些东西和找到哪些部分的想法实际上是有趣的。

物理

迄今为止最大的陷阱是运动。我们开始使用自定义运动学运动，基本上将左/右玩家输入转换为前进速度和 yaw。这样做使机器人可读，但它也太受限了——当我们这样做时，任何类型的环境交互都需要手动处理和模拟。

然后我们尝试更多地依赖Chaos Vehicles，得到了更接近的吻合，包括悬挂、轮胎接触和物理反应，但它仍然没有完全符合我们游戏的奇怪核心思想：两个玩家争论同一条链条。

当前的设置是基于Chaos Modular Vehicle的自定义EV风格电动机模块，每个侧有一个玩家提供左/右油门。一个玩家喂左油门，另一个玩家喂右油门，机器人转向是因为这两个输入不一致。相反，各自侧询问一个目标轮毂转速，然后电动机根据轮胎离该目标转速有多远来应用限定的扭矩。这样做使我们获得了更好的调节点——最大扭矩、最大转速、制动、电动机纠正的难度以及轮胎离开地面的情况下发生什么。

控制

大量的工作是找到“有趣的混乱”和“控制不佳”的界限。（好吧，我们仍然不确定我们是否属于前者类别，但前几位玩家测试者没有抱怨 :)）我们必须处理一下异步物理更新周期吃掉油门输入、空中轮胎永远旋转、单侧输入太敏感、翻转需要有可恢复的感觉而不是随机的。现在有一个小型赛车辅助层来软化只有一个侧在驱动的情况下出现的案例，而仍然保持机器人足够的笨拙以至于协调才是关键。它很混乱，但现在它的混乱是正确的：玩家可以学习它、与之抗争、指责对方而不是物理系统（至少我们一直在告诉自己）。

网络

网络在原型中比我们预期的要大得多。在纸上看起来简单：两个玩家连接，每个玩家控制机器人的一侧，Unreal复制结果。在实践中，共享机器人使每个小延迟或纠正都更加明显。如果一个玩家的输入晚到，或一个客户端看到机器人在物理纠正后定位不同，整个机器人都感觉不对劲。我们最终保留了机器人服务器所有权，并围绕分配站、复制站状态和明确输入路由构建多人流，而仍然依赖Unreal的内置复制在它表现良好的地方。主要的工作是确定哪些部分可以保持“vanilla” Unreal，哪些部分需要我们自己的粘合剂以使机器人仍然响应。尽管有粗糙的边缘，Unreal处理物理网络做得很好。

与Unreal一起工作

而且，总的来说，Unreal在快速移动方面是非常棒的，但它的缺点是你经常工作在已经具有非常特定形状的系统内部。当你需要的东西符合这种形状时，你会得到很多免费的东西。当它不符合时，选项就会变得不那么舒服：绕过它、复制系统的一部分或修复引擎/插件代码并承担维护成本。我们已经遇到过几次这样的情况，特别是在物理和多人游戏中，内置工具使我们接近但不总是达到我们需要的位置。

虽然仍然很早且在某些地方很粗糙，但看到想法转变为可玩的东西已经是一个巨大的里程碑。

我们收集了一段进展视频，展示了开发的前几周，从粗糙的测试到当前的原型。很高兴与那些对物理/网络方面感兴趣的人分享更多细节。

对于任何感兴趣的人，我们的Steam页面是：

https://store.steampowered.com/app/4708120/SplitCircuitArena