Cómo RUST LTD creó la simulación de armas de fuego avanzada para Hot Dogs, Horseshoes & Hand Grenades 2

Crear Hot Dogs, Horseshoes & Hand Grenades 2 (H3VR2), un sandbox de armas de fuego de física VR independiente y roguelike de extracción, significó empezar de nuevo en lugar de cargar con una década de deuda técnica y de diseño en una secuela.

En lugar de portar el juego original, RUST LTD comenzó con un proyecto fresco de Unity y pasó casi seis meses centrándose en la arquitectura y las herramientas antes de pasar a la producción completa de contenido.

Esa base soporta todo, desde componentes de armas de fuego y balística hasta percepción del enemigo, renderizado, audio y herramientas de editor. Los datos del mundo real alimentan muchos de esos sistemas, permitiendo que surjan diferencias mecánicas a través de la simulación en lugar de que el equipo las redacte como valores de jugabilidad aislados.

Hablamos con Luke Noonan, cofundador y jefe de producción de RUST LTD, y Anton Hand, cofundador y director de juego, sobre la reconstrucción del juego desde cero, el impulso de la complejidad de la simulación, el equilibrio entre la fidelidad física y el rendimiento de VR, y la creación de las herramientas necesarias para gestionar cientos de armas de fuego mecánicamente distintas.

Qué ha cambiado para la secuela: en alcance y en ambición?

Luke Noonan: Una de las cosas grandes que queríamos hacer con el nuevo título era arreglar mucha de la deuda técnica y de diseño que se había acumulado.

Hicimos una reescritura desde cero para H3VR2. Este era un proyecto fresco de Unity cuando empezamos. Vimos fragmentos del juego existente y sacamos esa experiencia de ella, pero esto no fue un puerto. Fue una reconstrucción.

AH: Técnicamente, construimos este proyecto casi exactamente opuesto a la manera en que construimos H3VR.

Con H3VR2, pasamos casi seis meses en arquitectura y herramientas puras antes de ocuparnos de algo que se acercara a la producción de contenido completo. Sabíamos cómo construir los fusiles ya que lo habíamos hecho durante 10 años. Necesitábamos sistemas que pudieran escalar a un proyecto de adiciones de contenido de cinco o diez años.

LN: También sabíamos desde el principio que este sería un equipo mucho más grande. H3VR fue en gran parte Anton con otras personas apoyando diferentes partes de la producción. Con H3VR2, somos más de 20 personas.

Eso requería mejores operaciones de desarrollo desde el principio: buena higiene de Version Control, Build Automation, herramientas de Editor personalizadas y procesos de producción que funcionen para un equipo distribuido en cinco zonas horarias diferentes.

¿Qué implica a nivel de simulación bajo el capó, y qué determinaste que debías hacer bien?

AH: Nuestro proceso comienza con una cantidad obsesiva de investigación clásica. Comenzamos encontrando material de referencia real, incluyendo libros y documentación técnica reales.

Desde un punto de vista de simulación, nuestro principio básico es construir un modelo donde podamos introducir datos reales y hacer que el modelo converja en algo entre el realismo coloquial recibido y algo que funcione para el juego.

Eso se vuelve importante en el momento en que construyes una simulación realmente compleja con una gran cantidad de entradas. Eventualmente tendremos cientos de armas, cientos de cartuchos y docenas de materiales.

Con H3VR2, hemos podido llegar mucho más lejos. Podemos preguntar si podemos introducir constantes de resorte reales en un sistema y descubrir que, sí, podemos. ¿Podemos incorporar dimensiones del mundo real y relaciones mecánicas en el sistema de operación del arma de fuego? Sí.

LN: Pagamos un costo por adelantado por ese enfoque sistemático, pero obtenemos muchos beneficios más adelante. Si queremos añadir un nuevo tipo de cartucho, por ejemplo, podemos observar propiedades como la masa del proyectil y las características del cartucho en lugar de inventar un número mágico de jugabilidad.

¿Dónde encaja NVIDIA PhysX en la pila y dónde decidiste que necesitabas sistemas personalizados en lugar de, o junto con, el motor de física incorporado?

AH: Usamos una cantidad bastante restringida de la complejidad disponible a través de NVIDIA PhysX.

Los motores de física de juegos realmente no manejan componentes diminutos dentro de un marco de referencia local mientras el jugador lleva el objeto padre y potencialmente lo lanza a través de la habitación. Así que tenemos muchas simulaciones internas muy personalizadas para componentes de armas de fuego que efectivamente existen en sus propios universos. Gestionamos la traducción de fuerzas e impulsos entre esos sistemas internos y el espacio de juego más grande.

A nivel de espacio de juego, usamos la física de manera mucho más directa. Los Sosigs, nuestros personajes de salchicha, son probablemente nuestro mayor uso de la física. Son muñecos de trapo de física perpetuos.

LN: A muy pequeña escala, para la simulación de componentes dentro de los cañones hemos construido sistemas personalizados. Al otro lado, para balística y una parte significativa de los sistemas de agentes construimos otra capa usando ECS for Unity y Burst.

Cómo arquitectaste la simulación balística usando ECS para Unity?

LN: Sabíamos que teníamos que tener muchos fusiles disparando, que los fusiles pueden disparar muy rápido, y que toda la refriega de disparos podría estar ocurriendo al mismo tiempo. Eso ejerce mucha presión de rendimiento en la simulación, y tuvimos que hacer concesiones al respecto en el primer juego.

Usar ECS para Unity y Burst nos permite generar enormes cantidades de Entities balísticas para armas de fuego, explosiones y otros sistemas.

Nos ayudó a aumentar la fidelidad en lugar de simplemente alcanzar nuestro objetivo original. Podemos hacer muestreo de subpasos más pequeños para una colisión más precisa, modelar la resistencia del aire de manera más precisa y realizar un manejo de mayor fidelidad de la penetración y los proyectiles que entran y salen de diferentes materiales.

¿Cuáles fueron los mayores desafíos de rendimiento que creó una simulación tan profunda?

LN: Gran parte del período de desarrollo inicial se trató de probar sistemáticamente esas áreas. ¿Qué es barato? ¿Qué es caro? ¿Qué puede o no puede hacer esta nueva plataforma? Una vez que tuvimos esos límites, fue mucho más fácil mantener el tiempo de fotograma en línea.

AH: Desarrollamos una comprensión muy afinada de lo que es rápido y lo que no lo es durante H3VR. Es una de las razones por las que nos mantuvimos fuera de la VR independiente hasta Quest 3.

En el lado de la CPU, eso significaba construir los sistemas de simulación centrales en torno a ECS y Burst. En el lado del renderizado, sabíamos que los modelos 3D sofisticados de armas consumirían una parte significativa del presupuesto de fotogramas, por lo que todo lo demás —el recuento total de polígonos, la memoria de texturas, el ancho de banda, la estructura del entorno— tenía que permanecer muy ligero.

No estábamos dispuestos a diezmar la cosa por la que la gente viene al partido. Así que diseñamos los entornos, la densidad de interacción, la tipología de contenido y la estructura de niveles en torno a esas restricciones desde el principio.

La optimización no fue una vía paralela que surgió después de un conjunto de decisiones de diseño inflexibles. Formó parte del proceso de gestación verticalmente a través de todo el proyecto.

LN: La instalación utiliza niveles ensamblados proceduralmente que construimos a partir de kits modulares, por lo que también validamos muy temprano cómo funcionaría el modelo de iluminación. Vimos cómo podríamos usar sondas de luz, sondas de reflexión y el resto de la pila de iluminación, y luego seguimos esas decisiones hacia atrás hasta la dirección artística misma.

Cómo benefició la actualización a Unity 6.3 al proyecto?

AH: Pasar a Unity 6.3 para H3VR2 es básicamente un salto de una década en comparación con H3VR.

Hay las obvias mejoras de calidad de vida, como nested prefabs, pero algunas de las cosas más impactantes para nosotros han sido el rendimiento de SRP Batcher, las mejoras en la compilación de shaders y el post-procesamiento en mosaico.

La compilación de shaders ha ayudado a hacer que esos grandes shaders uber sean más pequeños en disco. El post-procesamiento en el mosaico fue especialmente importante para nuestro enfoque visual. No quiero enviar un juego sin mapeo de tonos, pero originalmente escribimos nuestro paso de mapeo de tonos HDR directamente en nuestros shaders porque tener un blit de efecto posterior separado no era lo suficientemente eficiente en hardware VR independiente. Con el post-procesamiento en línea, pudimos eliminar ese código.

LN: La estabilidad y fiabilidad general de la versión actual de Unity también han sido genuinamente importantes. Estamos impulsando muchas herramientas personalizadas a través del Editor, y ese proceso ha sido muy fluido.

Cada arma en el juego tiene su propio comportamiento mecánico. ¿Cómo lo autores y lo mantienes basado en datos, y cómo mantienes una lista de ese tamaño?

AH: Mantenerlo mantenible es una lucha constante. El gran volumen de documentos de Google que tenemos para todo es bastante loco, aunque los activos en sí se convierten finalmente en la única fuente de verdad sobre cómo configuramos esas armas de fuego.

Vuelve a tener herramientas de Inspector muy potentes. Esas herramientas no son simplemente para introducir información. Tenemos herramientas de editor centradas en el cálculo, herramientas de validación y herramientas de análisis que construimos específicamente para las armas de fuego.

La simulación es lo suficientemente profunda como para describir gran parte del trabajo como más cercano a la fabricación de armas de fuego en la vida real. Estamos introduciendo cosas como constantes de resorte y masas de componentes. Los cartuchos tienen datos de curva de presión e información que describe los diferentes componentes del cartucho.

Si esos valores son incorrectos, el arma de fuego en la simulación no cicla correctamente.

¿Cómo ayudaron Odin Inspector y la Asset Store a tu equipo a gestionar la complejidad de desarrollar y mantener el juego?

AH: Si tuviera que identificar la propuesta de valor central de Unity para un juego como el nuestro, sería la extensibilidad del Editor.

Usamos Odin Inspector extensamente y no creo que este proyecto sea factible de la misma manera sin él.

Todos los que han escrito código para el juego han escrito inspectores personalizados. Odin minimiza drásticamente la cantidad de trabajo involucrado porque te da una abreviatura increíblemente potente para construir esas herramientas.

Eso es especialmente importante cuando se trata de algo tan ontológicamente y taxonómicamente complejo como un arma de fuego. Para cualquier arma individual, quizás el 95% o el 98% de todo lo que el sistema base podría configurar teóricamente es irrelevante para ese objeto en particular. Odin nos permite suprimir esas opciones irrelevantes.

Technie Collider Creator 2 de Triangular Pixels en el Asset Store también ha sido un cambio radical. Ha ahorrado al equipo cientos, si no miles, de horas durante el proceso de producción.

Para un juego de VR con mucha física, la creación de cascos de física requiere una combinación incómoda de trabajo manual y automatización. Una solución totalmente automatizada generalmente no es apropiada. Quieres usar primitivas de física tanto como sea posible y luego mallas convexas solo cuando absolutamente lo necesites.

¿Cuál es tu mejor consejo para desarrolladores que buscan crear un juego de simulación técnicamente complejo?

AH: Valida lo que necesitas con suficiente antelación. Hay una gran diferencia entre construir sistemas de simulación porque disfrutas el proceso de construir sistemas de simulación y construir sistemas de simulación que tu juego necesita.

Si miro hacia atrás en H3VR, hay trabajo de simulación que escribí que no era legible para el jugador. El usuario final no experimentó realmente su presencia. No me hizo la vida más fácil, en algunos casos me hizo la vida más difícil como desarrollador y diseñador, y no resultó en una jugabilidad más gratificante.

Ese es el riesgo con cualquier juego de simulación complejo. Puedes terminar haciendo un trabajo que no beneficia a nadie excepto quizás a tu propia experiencia al hacerlo, mientras te alejas más del objetivo macro del proyecto.

LN: También señalaría a la gente. Nos hemos beneficiado inmensamente al encontrar a los expertos adecuados para el equipo: un experto sólido que también tiene un profundo conocimiento de las armas de fuego, artistas de armas que entienden el tema y las necesidades de VR, e ingenieros interesados en los tipos de sistemas que estamos construyendo.

Hot Dogs, Horseshoes & Hand Grenades 2 se puede pre-ordenar ahora para Quest 3. La versión Steam se puede añadir a la lista de deseos ahora antes de su lanzamiento en 2027. Echa un vistazo a más historias de desarrolladores en el Blog de Unity y en el Unity Resource Hub.