Hace un par de años, nuestro equipo tuvo el honor de crear un "Almaty" móvil. Cumpliendo con las reglas "hacemos un juego, no tecnología" , creamos un prototipo de lo que ya está en el motor. Era UE 4.9, basado en el modelo físico: vehículos PhysX, y mucho dolor (con y sin).

Además, nuestro equipo creó el complemento de código abierto PsRealVehicle , disponible bajo la licencia MIT . Este complemento está ajustado para la física de tanques y vehículos con ruedas para tiradores de red altamente cargados, y puede observar su trabajo en cualquier momento en nuestro proyecto Armored Warfare: Assault .

Nombres, apariencias, contraseñas.

Claramente Ya veo Y solo por negocios.

Repositorio de complementos

Documentación de configuración principal

Usado en el proyecto: Armored Warfare: Assault

Un poco de historia, o de vuelta a las raíces

Comenzamos a trabajar en el proyecto en Unreal Engine 4.9 . En ese momento, la física de máquinas "lista para usar" solo admitía vehículos de cuatro ruedas, y para los "bancos" de seis ruedas (LAV-400, nuestro primer vehículo prototipo de "combate"), tuvimos que usar inmediatamente el conjunto de motor personalizado. Con la física incorporada de los tanques fue aún peor: los datos sobre cómo funciona todo y cómo se configura, tuvieron que ser poco a poco para extraer el código.

Siguiendo la regla "prototipo" , hemos formado los siguientes requisitos para nosotros mismos:

• La física debe simular el movimiento de un tanque (programa mínimo) y vehículos con ruedas (muy deseable, esta es una característica de la serie de juegos AW).
• Un servidor dedicado debe soportar hasta 20 máquinas por sesión en línea , y el cliente debe manejarlas.
• Todas las ruedas y orugas deben seguir las irregularidades de la superficie, la suspensión debe funcionar y el tanque debe girar.
• La configuración física debe determinarse por valores reales (masa de la máquina, potencia del motor) y conducir a un comportamiento realista (la capacidad de superar ciertos tipos de terreno).
• Cuanto menos código técnico escribamos, mejor: Epic Games debería hacer el motor, no nosotros .

Entonces, los requisitos son aproximadamente claros, ponte manos a la obra. Rápidamente, armamos el primer prototipo, los tanques se fueron, los autos condujeron, pero tuvimos dos problemas:

1. Todo esto es muy alegremente engullido el procesador.
2. La imagen creada del mundo no quería encajar en el marco del comportamiento realista de los equipos pesados. El tanque de treinta toneladas en cualquier configuración no podría soportar un aumento de 15 grados (y esta es una de las opciones más fáciles). Pasamos mucho tiempo jugando con la configuración para la simulación y la fricción del paisaje, pero esto condujo a una potencia que se elevaba a valores cósmicos (más de 20 veces más que los valores reales, y como resultado, los autos se comportaron de manera inestable e impredecible), o a masas de equipos de juguete (PhysX funciona bien con una masa de vehículo en la región de una tonelada y media).

Los diseñadores de juegos de esto estaban lejos de ser entusiastas. Los programadores lloraron, pincharon, pero continuaron comiendo un cactus (¡la fiesta requiere una solución que funcione!). El prototipo fue aprobado por el liderazgo y enviado para crear una versión alfa (por cierto, el video del prototipo está en Youtube . Pero el tiempo pasó y las esperanzas de un futuro más brillante para tal física se hicieron cada vez menos. La configuración no fue suficiente, su comportamiento parecía magia negra. Y la posición "Juego, no tecnología" se ató las manos a su manera, al menos con dudas sobre si podríamos sacarlo.

Armado en silencio con Wikipedia, el conocimiento residual de la escuela y la experiencia trabajando en física "en pontones" a la Assassin's Creed, en un par de días creé un prototipo de la nueva física de tanques, que formó la base del complemento PsRealVehicle. En una semana, la prueba de concepto se puso de pie, los equipos de CTO se mostraron y protegieron mediante pruebas de carga. Los números decían: ser tu física.

...-..., y en producción

El camino desde el prototipo hasta las ventas se ha extendido mucho más. Si una semana era suficiente para una verificación conceptual, entonces tomó un mes y medio para una versión beta adecuada . La creación de una versión completa "prod" llevó aproximadamente seis meses, constante perfeccionamiento y corrección, durante todo el tiempo de trabajo en el proyecto. De muchas maneras, le debemos una gran velocidad al desarrollo e implementación de la física en el proyecto al diseñador técnico de juegos Igor, quien vino a nuestro equipo en ese momento, cuya meticulosidad en los aspectos del modelo matemático y su percepción subjetiva por parte de los jugadores condujo al resultado actual. Debo admitir, en un sentido tecnológico, que soy un bárbaro : es mi trabajo hacer un hacha para cortar un bosque. Después de que Igor procesó y ajustó el modelo con otros muchachos, obtuvimos una solución abierta lista para producción que es escalable y altamente optimizada para las necesidades del multijugador . Hay algo de lo que estar orgulloso: de los muchos complementos disponibles en el mercado (incluidos los vehículos incorporados PhysX), nuestra configuración más rápida y transparente.

Por cierto, hubo algunos casos divertidos. Mientras estábamos trabajando con el Vehículo PhysX y nuestros vehículos de múltiples ruedas extremadamente resbaladizos no podían escalar pequeñas colinas, escuché reproches más de una vez, diciendo que nuestro equipo no podía configurarlo para que la gente lo tuviera. Se tomó la decisión de usar su complemento, incluso bajo la influencia de este marco:

¡El último desarrollo del ejército soviético! Un tanque de araña que puede escalar paredes de 89 grados . Simplemente no había nada que cubrir: D

Características de nuestra solución.

Antes de pasar a describir la configuración de tanques y vehículos en PsRealVehicle como un ejemplo de nuestro AW: Asalto, quiero mencionar un par de cosas que formaron la base del modelo físico utilizado.

En primer lugar, nos adherimos claramente al hecho de que no estamos haciendo un simulador de física de tanques, sino un juego que sea suficientemente arcade. Es triste, pero pocas personas necesitan un verdadero tanque en su comportamiento; esto es genial solo en videos de presentación, y no en control, y aún más en un tirador. El jugador necesita un tanque que se comporte como un tanque en el sentido que otros éxitos de taquilla ya han creado. Y para trabajar en un dispositivo normal, y no en un Titán.

El primer punto tiene una consecuencia: algunas cosas en el juego funcionan muy falsas. Si algo se parece a un tanque y se comporta como un tanque, entonces es un tanque , y no importa que dentro sea una pequeña fragata, o que parte de la física esté configurada con magia de fricción condicional. Una de estas convenciones es controlar la rotación de la máquina cambiando la velocidad angular, y no por las fuerzas aplicadas a las ruedas y la suspensión. Convencionalmente, el tanque gira X grados por segundo, porque decidimos esto sobre la base de consideraciones de juego, y no porque sus pistas giran a tal o cual velocidad.

Por cierto, esto no niega el hecho de que "bajo el capó" puede activar la física de rotación "real", se utilizó en los primeros prototipos . En el buen sentido, vale la pena sujetar el trabajo de la suspensión angular, la base de la rueda, etc. Si comenzamos a hacer simulaciones de carreras, definitivamente volveremos a esto, pero por ahora este es uno de los elementos en la lista de posibles mejoras.

Estructura del tanque en AW: Asalto

Jerarquía de clases

AAwmVehicle es la principal clase de C ++ responsable de la máquina en el juego, dividida en muchos componentes (movimiento - UPsRealVehicleMovementComponent , sonidos, UPsRealVehicleMovementComponent , estadísticas, armadura y otros). El BP_DefaultVehicle hereda de él, que es una capa adicional para la configuración predeterminada para todas las máquinas. Todos los demás son planos privados de configuraciones para cada equipo en el juego.

Cada máquina es un conjunto de tales datos:

• Blueprint, donde se registran todos los activos externos , sonidos, propiedades a la "vehículos con ruedas / orugas" y configuración física.
• Un esqueleto de malla y activos atados a él:
  - Activo físico (no hay magia, todo es estándar).
  - Árbol animado.
• Texturas (difusas, mapa normal, RMM).
• Material de instancia (casco, pistas + condición destrozada).
• Un conjunto de mallas de armadura para el sistema de penetración.
• Cámaras, comprobadores de nivel de agua y otras colisiones auxiliares.

Animación de tanque

Configurar un tanque es muy sencillo, no importa cuán complejo sea el árbol de animación. Configurar docenas de tales tanques y mantenerlos actualizados al cambiar huesos, mallas, etc. es una cantidad completamente inadecuada para el trabajo manual . Afortunadamente, en nuestro caso estamos hablando de un "personaje" bastante estandarizado: un tanque se puede diseccionar en entidades y llamarlo estereotipado. Esto, por supuesto, se trata de nombrar huesos.

Este enfoque nos permitió utilizar esencialmente el mismo árbol de animación, que hace que Ctrl + C / Ctrl + V se multiplique por cualquier número de tanques y no requiere ningún soporte, excepto el control de calidad original.

Toda la magia ocurre dentro de nodos sipy personalizados. Esto permitió no solo estandarizar el árbol, sino también reducir en gran medida el número de cálculos por animación (a los nodos estándar les gusta conducir sistemas de coordenadas de un lado a otro).

Materiales del tanque

Para todas las partes del tanque, se utiliza un material maestro , personalizado por un par de nodos Switch.

A continuación tenemos un árbol como este:

  - M_Vehículos
  - - MI_Vehicles_Clean_Body
  - - - MI_Leopard2
  - - - - MI_Leopard2_LOD
  - - MI_Vehicles_Clean_Treads (marcado "Botines")
  - - - MI_Leopard2_Treads
  - - - - MI_Leopard2_Treads_LOD 

El "peso" real aquí es solo M_Vehicles y MI_Vehicles_Clean_Treads , todas las demás instancias son solo conjuntos de parámetros y consumen un mínimo de memoria y espacio en disco.

En general, el conjunto de recursos gráficos para el tanque es muy estándar para cualquier juego.

Trabajo de armadura

Varias veces, cuando nos comunicamos con colegas, surgió la pregunta: ¿por qué cada pieza de armadura tenía una malla separada y por qué no utilizamos el sistema de colisión Anrilov?

De hecho, usamos las colisiones habituales de Anrilov, pero solo para "atrapar" la bala . Una vez que el proyectil se ha atascado en el tanque, el daño se calcula poligonalmente en todas las capas de armadura, teniendo en cuenta las propiedades de cada pieza, las capas múltiples, la reflexión del proyectil, el embudo acumulativo y otras mecánicas interesantes.

Lo más conveniente para este caso es leer los datos de malla "desnudos", que no eliminamos para un servidor dedicado.

Red y Optimización Extra

Un par de puntos "cercanos al tanque" que también me gustaría mencionar brevemente.

• Todo el movimiento de los tanques se realiza solo en el servidor , los clientes solo interpolan los valores recibidos. No se utiliza extrapolación. La frecuencia de sincronización es de 10 veces por segundo .

  
  

• Dependiendo del tamaño de pantalla del tanque, omitimos uno u otro número de ticks de la malla del esqueleto, que incluye un cálculo de todas las animaciones y algunas interacciones físicas. Si el tanque no está visible en la pantalla, es una caja estúpida y no animada que flota en el espacio . La optimización de la tasa de actualización incorporada, a pesar de una buena idea, tiene una implementación muy cruda que no brinda un aumento tangible del rendimiento. Especialmente cuando se trata de teléfonos celulares.

  
  

• Para todos los tanques, excepto el suyo, todos los componentes, excepto los más básicos, están cortados en el cliente: cámaras, verificadores y otras cosas que componen el tanque. De hecho, no tienen nada más que apariencia .

  
  

• Un tanque dedicado LOD1 conduce en un servidor dedicado. Menos picos, menos uso de CPU. Además, la actualización de la posición de las piezas de armadura personalizadas se produce solo en el momento en que impacta el proyectil: no tiene sentido actualizar el estado de las partes en cada tic.

Yo, yo mismo y tanques

En Pushkin Studio, creemos que el intercambio de experiencias de desarrollo es muy importante, incluso para el crecimiento del nivel profesional dentro del equipo. Los proyectos de código abierto son un componente importante de este enfoque, y me alegra poder presentar a la comunidad tecnología como PsRealVehicle .

En mi opinión, es muy importante que nosotros mismos usemos todos los complementos y utilidades que publicamos a diario. Después de todo, el camino claramente demostrado por Epic Games es que el éxito de una buena tecnología es utilizarla por los propios desarrolladores en sus propios productos. Ahora ya estamos trabajando en la versión UE 4.20 , nuestro complemento se ha ido hasta aquí y no vamos a parar.