几年前，我们团队很荣幸创建了一个移动“阿拉木图”。遵循“我们创造游戏而不是技术”的规则，我们根据引擎中已有的内容创建了原型。它是基于物理模型PhysX Vehicles的UE 4.9，并且有很多痛苦（有和没有）。

此外，我们的团队创建了开源插件PsRealVehicle ，可在MIT许可下使用。该插件针对高负荷网络射击者的坦克和轮式车辆的物理特性进行了调整，您可以在我们的项目Armored Warfare：Assault中随时观察其工作。

名称，外观，密码。

显然。知道了并且仅在业务上。

一段历史，或者回到根源

我们开始在Unreal Engine 4.9上进行该项目。当时，“开箱即用”的机器物理仅支持四轮车，而对于六轮“基准”（LAV-400，我们的第一款“战斗”原型车），我们不得不立即使用定制的发动机总成。借助坦克的内置物理特性，情况变得更糟：必须逐点收集有关一切工作和配置方式的数据，以摆脱代码的束缚。

遵循“原型”规则，我们为自己形成了以下要求：

物理学应该模拟坦克（最小程序）和轮式车辆的运动（非常需要-这是AW游戏系列的功能）。
专用服务器必须每个联机会话最多承受20台计算机 ，并且客户端必须处理它们。
所有车轮和履带均应遵循表面不平整规定， 悬架应正常工作 ，且油箱应摆动。
物理设置应由实际值 （机器的质量，发动机功率）确定，并导致真实的行为（克服某些类型的地形的能力）。
我们编写的技术代码越少越好： Epic Games应该制造引擎，而不是我们 。

因此，要求大致明确，可以开始工作。很快，我们组装了第一个原型，坦克去了，汽车开了，但是我们遇到了两个麻烦：

所有这些都极大地困扰着处理器。
创建的世界图景不适合重型设备的实际行为框架。在任何设置下，重达30吨的战车都无法上升15度 （这是最简单的选择之一）。我们花了很多时间修改景观的模拟和摩擦设置，但这导致功率提升到宇宙值（比实际值大20倍以上，结果，汽车的性能不稳定且不确定），或者导致大量设备（PhysX）可以在一辆半吨左右的车辆中正常工作。

因此，游戏设计师们并没有热情。程序员哭了，被刺了，但继续吃仙人掌（聚会需要有效的解决方案！）。原型获得了领导层的批准并被发送来创建一个Alpha版本（顺便说一下，该原型的视频在Youtube上。但是时间流逝，人们对这种物理学的美好未来的希望越来越少。设置还不够，它们的行为看起来像是黑魔法。 “游戏，而不是技术”以自己的方式束手无策，至少在怀疑我们是否可以拉动它方面。

几天后，我在Wikipedia上静静地武装着残留的学校知识和在刺客信条上“浮桥”上从事物理学工作的经验，我创建了一个新的坦克物理原型，该原型构成了PsRealVehicle插件的基础。在一周之内，概念验证就付诸实践，CTO团队受到了负载测试的演示并受到了保护。 数字说：做你的物理学。

...-...，以及在生产中

从原型到销售的路径已经更长了。如果一周的时间足以进行概念上的检查，则需要一个半月的时间才能获得适当的Beta版本 。在项目的整个过程中，创建完整的“产品”版本大约花了六个月的时间，不断完善和修正。在很多方面，我们都得归功于当时在团队中工作的技术游戏设计师伊戈尔（Igor）在项目中开发和实施物理学的速度，伊戈尔在数学模型方面的细致入微以及玩家对其的主观感知导致了目前的结果。 从技术上讲，我必须承认我是野蛮人 ：砍斧砍伐森林是我的工作。经过Igor与其他人的处理和模型的微调之后，我们得到了可立即投入生产的开放式解决方案，该解决方案可扩展并针对多人游戏的需求进行了高度优化。值得骄傲的是：市场上有很多插件（包括内置的PhysX Vehicles），我们最快，最透明的设置。

顺便说一句，有一些有趣的案例。当我们使用PhysX车辆，而我们极滑的多轮车辆无法爬上小山丘时，我听到了不止一次的责难，说我们的团队无法进行安装，以致于人们无法忍受。决定使用他的插件，包括在以下框架的影响下：

苏军最新发展！ 可以爬到89度墙壁的蜘蛛罐。根本没有什么要掩盖的：D

我们解决方案的特点

在我继续以PsRealVehicle中的坦克和车辆的配置作为AW：突击的示例进行描述之前，我想先说几件事，它们构成了所使用的物理模型的基础。

首先，我们明确地坚持这样一个事实，即我们不是在制造坦克物理模拟器，而是在开发一款足够街机的游戏。很难过，但是很少有人需要真正的行为举止-这仅在演示视频上很酷，而不受控制，在射击游戏中更是如此。玩家需要一种在其他重磅炸弹已经产生的意义上表现像坦克的坦克。并且要在常规设备上工作，而不是某些Titan。

第一点有一个后果：游戏中的某些东西非常虚假。 如果某物看起来像一个坦克并且表现得像一个坦克，那么它就是一个坦克 ，而里面的护卫舰是没有意义的，也可以用条件摩擦魔术来设置物理学的一部分。这些约定之一是通过改变角速度而不是通过施加在车轮和悬架上的力来控制机器的旋转。按照惯例，坦克会每秒旋转X度，这是因为我们是根据游戏玩法来决定的，而不是因为它的轨迹以这种速度旋转。

顺便说一句，这并不能否定一个事实，那就是您可以在“引擎盖下”开启“真实的”旋转物理学， 这是在第一个原型中使用的 。很好的方法是固定角形悬架，车轮底部等的工作。如果我们开始进行赛车模拟，那么我们肯定会回到这一点，但是现在这是可能改进列表中的一项。

AW的坦克结构：突击

类层次

AAwmVehicle是负责游戏中机器的主要C ++类，它分为许多组件 （运动UPsRealVehicleMovementComponent ，声音，VFX，统计信息，装甲等）。 BP_DefaultVehicle继承自它，这是所有计算机的默认设置的附加层。所有其他都是游戏中每个设备的私人设置蓝图。

每台机器都是一组这样的数据：

蓝图，其中注册了所有外部资产 ，声音，设置了“轮式/履带车”属性，并设置了物理。
网格骨架和与其相关的资产：
-实物资产（没有魔术，一切都是标准）。
-动画树。
纹理（漫反射，法线贴图，RMM）。
实例材质（船体，航迹+破碎状况）。
一套用于穿透系统的装甲网。
相机，水位检查器和其他辅助碰撞。

坦克动画

不管动画树多么复杂，设置一个坦克都是一件小事。配置数十个这样的水箱并在更换骨骼，网格等时保持最新状态对于手动工作来说是完全不足的 。幸运的是，在我们的案例中，我们所谈论的是一个相当标准化的“角色”：一个坦克可以分解成多个实体，并称其为原型。当然，这与命名骨骼有关。

这种方法使我们可以使用基本相同的动画树，其中Ctrl + C / Ctrl + V乘以任意数量的坦克 ，除了原始的质量检查外，不需要任何支持。

所有魔术都发生在自定义sipy-nodes内部。这样不仅可以标准化树，还可以大大减少每个动画的计算数量 （标准节点喜欢来回驱动坐标系）。

坦克材料

对于储罐的所有部分，使用一种母材 ，由一对Switch节点自定义。

接下来我们得到一棵这样的树：

  -M_Vehicles
  --MI_Vehicles_Clean_Body
  ---MI_Leopard2
  ----MI_Leopard2_LOD
  --MI_Vehicles_Clean_Treads（选中“ Treads”）
  ---MI_Leopard2_Treads
  ----MI_Leopard2_Treads_LOD

此处的实际“权重”仅为M_Vehicles和MI_Vehicles_Clean_Treads ，所有其他实例只是参数集，并且占用最少的内存和磁盘空间。

通常，坦克的图形资产集对于任何游戏都是非常标准的。

装甲工作

与同事交流几次时，出现了一个问题，为什么每件装甲都有单独的网格，为什么我们不使用Anrilov碰撞系统？

实际上，我们使用了通常的Anrilov碰撞，但仅仅是为了“抓住”子弹 。弹丸推入坦克后，要考虑所有部件的特性，多层，弹丸的再反射，累积漏斗和其他有趣的力学原理，对所有装甲片进行多边形计算。

在这种情况下，最方便的方法是读取“裸”网格数据，我们不会剥离专用服务器的数据。

网络和额外优化

我也想简短地提到几个“近箱”点。

储罐的所有移动仅在服务器上进行 ，客户端仅对收到的值进行插值。不使用外推法。同步频率是每秒10次 。
根据水箱的屏幕尺寸，我们跳过骨架网格物体的一次或多次滴答，其中包括所有动画的计算和一些物理交互。如果无法在屏幕上看到坦克，则它是一个漂浮在太空中的愚蠢， 没有动画的盒子 。尽管有一个好主意，但内置的“更新速率优化”具有非常粗糙的实现方式，并没有明显提高性能。特别是在手机方面。
对于所有储罐，除了其自身的储罐外，客户端都会切断除最基本组件之外的所有组件：照相机，检查器和其他组成储罐的物品。实际上， 它们只不过是外表而已 。

专用LOD1储罐在专用服务器上驱动。峰值更少-CPU使用率更低。而且，仅在射弹命中时才进行定制装甲件位置的更新：在每个滴答声中都没有更新零件状态的意义。

我，我自己和坦克

在普希金工作室，我们认为开发经验的交流非常重要，包括对于团队内部专业水平的提升。开源项目是这种方法的重要组成部分，我很高兴能够向社区介绍PsRealVehicle之类的技术。

我认为，我们自己每天使用我们发布的所有插件和实用程序非常重要。毕竟，Epic Games自己清楚地表明，好的技术的成功在于开发商自己在自己的产品中使用它 。现在我们已经在使用UE 4.20版本了 ，我们的插件已经一路走了，而且我们不会停止！

PsRealVehicle或装甲战中的开源坦克物理插件：突击