Tramway SDK – la unión impía entre los motores de Half-Life y Morrowind

• Tramway SDK es un paquete gráfico/framework/motor de juegos desarrollado durante los últimos 3 años, orientado a ser un motor liviano que se opone a los altos requisitos y al flujo de editor monolítico de los motores convencionales
• Considera que motores populares como Unity y Godot exigen hardware excesivo incluso para juegos simples de bajo poligonaje, por lo que apunta a ejecutarse incluso en hardware de hasta 15 años y hasta con rasterización por software
• En lugar de alternar entre una GUI de nodos y código, su método de desarrollo consiste en escribir código mediante herencia de la clase Entity y usar solo los editores necesarios
• La creación de niveles se basa en un flujo de trabajo tipo Quake con brushes, aprovechando conversor de .map, lightmaps, sombreado Gouraud y un sistema de entradas/salidas al estilo Source
• Apunta al streaming de mundo abierto y a un framework RPG cercano a un RPG Maker 3D, pero todavía está en una fase temprana de desarrollo, así que hay que considerar API inestable y elementos aún no implementados

---

El problema al que apunta Tramway SDK

• Tramway SDK es un paquete gráfico, framework y motor de juegos, y también usa la escritura estilo heavy metal “T̈ra̦m̊ẅa̦ÿ SD̈K”
• Su crítica a los motores convencionales se centra en el Turbobloat
  • Considera que Unity requiere hardware muy potente y mucho consumo eléctrico
  • Ve a Godot como un poco mejor que Unity, pero aun así necesitado de hardware relativamente capaz
  • Sostiene que juegos como un horror roguelite deckbuilder simulator low-poly deberían poder ejecutarse sin problema en hardware de hace 15 años
• Tramway SDK presume que, al no tener Turbobloat, puede ejecutarse en casi cualquier hardware de los últimos 15 años
  • Puede cambiar a rasterización por software para funcionar incluso sin tarjeta gráfica
  • Incluso pone ejemplos de mostrar gráficos en dispositivos como una tostadora o un refrigerador
• A la objeción de “simplemente compra una mejor computadora”, responde con tres razones
  • El problema de la accesibilidad económica: mucha gente no puede pagar hardware potente
  • El problema de los residuos electrónicos: producir chips es malo para el medio ambiente, y si el software no fuera tan inflado, solo haría falta comprar hardware nuevo cuando el anterior se descomponga y ya no se pueda reparar
  • La postura de que, si ya tienes una computadora que funciona bien, no hay razón para comprar otra nueva por culpa del Turbobloat ajeno

Método de desarrollo y funciones

• El método de desarrollo basado en nodos es criticado porque obliga a tratar con “muchas cosas que parecen una sola” y a alternar entre la GUI de nodos y el código
• En Tramway SDK basta con escribir código heredando de la clase Entity y luego crear el nivel con el editor de niveles
  • Se organiza en torno a entidades sin usar nodos
  • Evita el flujo de ir y venir entre código y GUI de nodos
• El editor monolítico de los motores convencionales también se considera un problema
  • Se critica tener que esperar a que cargue el editor completo, incluyendo funciones que ni siquiera se usarán
  • Todos los editores de Tramway SDK son opcionales
  • Si solo se quiere usar como framework, se puede usar únicamente el runtime de C++
  • Si solo hace falta crear niveles, se puede usar únicamente el editor de niveles
  • Los archivos de datos usan un formato de valores separados por espacios, así que también se pueden editar a mano sin editor
• En el apartado gráfico, las imágenes de ejemplo pueden lograrse solo con lightmaps y sombreado Gouraud
  • Ese ejemplo incluso podría renderizarse en el pipeline fijo de una tarjeta gráfica de nivel Direct3D 7
• La creación de niveles admite un flujo de trabajo basado en brushes al estilo de la familia Quake
  • Tramway SDK ofrece un conversor de archivos .map que transforma brushes en mallas trianguladas
  • Muestra un flujo donde se crea el nivel en Trenchbroom y se configura en el editor de niveles de Tramway SDK
  • El motor renderiza dentro de sí mismo el nivel con lightmaps aplicados
  • Con un sistema de entradas/salidas similar al de Source, se pueden configurar interacciones entre entidades dentro del nivel
  • A futuro planea implementar por completo las logic entities de Source para permitir scripting visual dentro del editor de niveles
• En la parte RPG, considera interesante cómo herramientas como RPG Maker y los mods y total conversions basados en Morrowind permiten crear muchas cosas cambiando datos
  • Tramway SDK incluye una extensión de framework RPG cercana a un RPG Maker para 3D
  • El motor fue diseñado desde el inicio para soportar streaming de niveles, y considera que eso puede hacer más rápida y sencilla la creación de juegos tipo RPG de mundo abierto
• En resumen, Tramway SDK es un motor de juegos basado en entidades al estilo Quake/Source, con extensiones opcionales como streaming de mundo abierto y framework RPG
• Su estado de desarrollo sigue siendo muy temprano
  • La API es inestable
  • Las funciones pueden fallar o no funcionar
  • Todavía hay muchos elementos sin implementar
  • Afirma que está mejorando rápidamente
• Repositorio en GitHub: racenis/tram-sdk

[GN⁺]

Opiniones de Hacker News

• Algunos dirán “simplemente compra una computadora mejor”, pero por eso estoy totalmente de acuerdo en que comprar una computadora mejor es algo malo. Mucha gente, especialmente en países en desarrollo, no puede darse el lujo de comprar hardware para correr Turbobloat, y la producción de chips tiene un impacto negativo en el medio ambiente.
  Si el software moderno no estuviera tan inflado, compraríamos hardware nuevo solo cuando el existente se rompiera y no pudiera repararse. No hay razón para comprar una computadora nueva por culpa del software inflado de otros cuando ya tienes una que funciona bien; con ese dinero también podrías comprar 1000 latas de Dr. Pepper. Es un proyecto realmente bueno, así que ojalá sigan publicando avances.

  • Dice “resoluciones de pantalla desde 320x200 hasta 800x600”, pero las resoluciones más altas no se inventaron solo por culpa de Turbobloat.
  • Aunque dice eso, el motor parece requerir una GPU OpenGL 4, cuando los gráficos se ven a un nivel que hasta una tarjeta Voodoo podría manejar.
  • No sé qué es Turbobloat. Por el contexto se lee como “tecnología gráfica que no me gusta”, pero no queda claro dónde empieza o termina Turbobloat.
  • Construir y enviar computadoras nuevas podría valer la pena a largo plazo, porque las mejoras en rendimiento y eficiencia energética pueden compensar con el tiempo el impacto ambiental.
    Claro, si es para entretenimiento la evaluación es más difícil, y un Game Boy viejo podría ser más divertido que una PC gamer moderna de 1000 W.

• La frase “Uno debe ser uno. No deben ser varios fingiendo ser uno. Con nodos, hay que hacer que varias colecciones finjan ser una” suena muchísimo a Terry Pratchett y es excelente.
  Me gusta porque parece una frase que se le ocurriría a Sam Vimes durante una investigación complicada, y espero que siga evolucionando. Todavía no lo he probado directamente, pero tengo ideas para usarlo en mi proyecto de IA.

  • Si se toma esa frase de forma aislada, más bien me parece claramente falsa. Siempre pensamos en colecciones de varias cosas como si fueran una sola.
    Un ser humano es una colección de partes del cuerpo; las partes del cuerpo son colecciones de sustancias químicas; las sustancias químicas son colecciones de moléculas; las moléculas son colecciones de átomos, y aun así en cada nivel las vemos como una sola cosa. No tiene sentido impedir eso. Aun así, el proyecto se ve genial.
  • Me imagino a Sam Vimes diciendo eso y luego, por culpa de Sybil, pasando por un doloroso crecimiento personal hasta admitir a regañadientes que “a veces, quizá, uno simplemente tenga que ser más que uno”.
    Y el sistema de entidades y componentes de Vetinari parece complicado, pero funciona correctamente y mantiene en marcha a la maldita ciudad.
  • Esa frase parece apuntar a gente que probó otras soluciones y no le gustaron, pero como alguien que nunca ha usado un motor de juegos, me gustaría una explicación sencilla de cómo se relaciona que los nodos “hagan pasar una colección de varias cosas por una sola”.
    Supongo que significa que la experiencia de usuario de un editor de nodos te empuja a asignar propiedades y relaciones a cosas como un Vector de Finger, pero al final un Vector es solo una “colección de cosas”, no un “tipo” con comportamiento propio, y por eso es difícil adjuntarle código.
    Me pregunto si “todo es una Entity y simplemente escribe código” significa que, en vez de usar un Vector, deberías crear una clase Hand que contenga Fingers y tenga su propio estado y comportamiento. O si significa que, en lugar de crear una instancia de nodo que ya agrupe ciertos valores estáticos y miembros de relación, deberías volver a heredar de una subclase de Entity para hacerla más específica.
  • El párrafo inmediatamente siguiente es interesante: “cuando haces algo con nodos, tienes que ir y venir constantemente entre la GUI de nodos y el código”.
    La composición Node/GDScript de Godot puede verse como una especie de respuesta a esta afirmación. Es un intento de hacer que ese “ir y venir” sea lo más fluido e integrado posible con cosas como el operador $ y el autocompletado. Aun así, al final hay que lanzar el juego, así que creo que la mentalidad de “uno es uno” termina ganando.
  • Lamentablemente, todo es una colección de cosas que fingen ser una sola, incluso una cosa individual. Lo mejor que podemos hacer es seguir fingiendo, o evitar que nos descubran.

• Con el paso del tiempo, da la impresión de que hay fuerzas externas que reducen la calidad de los motores de juego. En tecnología en general, lo que se masifica suele ser aquello para lo que es fácil armar un currículo.
  Los editores basados en nodos como Unity tienen una estructura ideal para explicarlos a lo largo de varias clases. En cambio, un motor como raylib se puede entender en una tarde, así que es difícil que exista una clase universitaria de raylib. Por eso se genera un ciclo en el que de escuelas tipo bootcamp salen desarrolladores amateur que solo conocen Unity/Unreal, las empresas contratan gente de Unity/Unreal y las universidades vuelven a enseñar eso. Es parecido al fenómeno de la popularidad de Java.
  Además, como cada empresa tiene requisitos distintos para sus proyectos en Unity, Unity tiene que seguir adaptando el motor no como un programador inconforme, sino como una empresa con fines de lucro que atiende a clientes, y al final se convierte en Turbobloat. Los motores de Half-Life y Morrowind surgieron de una situación particular en la que programadores apasionados recibían dinero para desarrollar lo que les parecía genial, y de ahí salieron motores mínimos adecuados para desarrolladores profesionales de juegos y tecnología excelente.
  Este proyecto parece estar en algún punto entre raylib y Unity. Me preocupa que no alcance para atraer a programadores amateur y que, para programadores que quieren un motor pequeño, haga demasiadas cosas. Ojalá me equivoque; el rendimiento y el nivel de acabado se ven buenos. Sin duda hay desarrolladores cansados de Unity, y a medida que el ciclo de nostalgia avanza hacia los años 2000, también existe una demanda real por jugar y crear juegos que no sean más complejos gráficamente que Half-Life 2. El diseño web y el tono de la documentación también están buenos.

  • También es importante que, cuando el juego y el motor se crean juntos, ambos pueden ajustarse entre sí. En Doom no se podía poner un piso encima de otro piso; era una limitación del motor derivada de las restricciones de CPU, y los diseñadores de niveles inventaron trucos para que pareciera que sí.
    Si se diseñan ambos en conjunto, se pueden aprovechar activamente las funciones agregadas y evitar las que no funcionan bien, o incluso adaptar el estilo artístico al motor. Los mobs pixelados y angulosos de Minecraft encajan bien con el motor, pero si uno empieza a hacerlos más detallados, cae en un valle inquietante donde se ven más anticuados e incómodos que Minecraft hasta que se renderizan de forma aceptable con suficientes polígonos.
  • Recuerdo que alguien que trabajó en Bioshock, quizá el diseñador principal, dijo en una entrevista: “En la empresa, para experimentar con una idea nueva, hay que armar un equipo y dedicar al menos un mes antes de poder tocar algo. En cambio, en casa puedo crear una campaña completa de Doom en una sola noche”.
  • Me gusta el desarrollo de juegos basado en bibliotecas como raylib o libgdx, pero hay una razón por la que un juego como Slay the Spire pasó por Unity y luego por Godot para su secuela.
    No creo que la gente use Unity porque aprendió mal con profesores a los que les gusta la complejidad.
  • Los juegos de antes eran realmente nítidos, pero los de hoy corren pésimo, crashean, necesitan 150 GB de descarga y tardan 150 años en arrancar. Si jugáramos por los gráficos, uno de los MMO más populares no estaría basado en un juego de navegador de 2002 y, para empezar, no jugaríamos videojuegos sino la realidad.
    Basta ver lo que Epic Games le hizo a Fortnite. Mató un juego centrado en una escena competitiva que corría fluido por culpa de los gráficos Turbobloat y las skins.
  • El fenómeno de “salen programadores que solo conocen Unity/Unreal, las empresas contratan gente de Unity/Unreal y las universidades vuelven a enseñar eso” también se ve de forma parecida con ArcGIS.

• Estoy totalmente de acuerdo con el problema de la turbobloatedad. Aunque las máquinas de hoy son mucho más potentes, la mayoría de los programas se sienten más lentos que antes.
  El proyecto también está muy bueno y el diseño del sitio web es A+.

  • Eso de que “la mayoría de los programas son más lentos que antes” me parece cierto solo para quienes tuvieron la suerte de usar hardware algo sobrado para su época.
    Desde la perspectiva de alguien que usaba hardware común en la época de Windows 98/2000/XP, correr Windows 10/11/KDE/Gnome, etc. en una laptop moderna barata con SSD resulta mucho más responsivo, incluso al ejecutar webapps consideradas pesadas como vscode o Slack.
  • No entiendo el término Turbobloat. He hecho juegos, pero nunca lo había oído; quien escribe tampoco lo define, y al buscarlo en Kagi solo aparece el post enviado, mientras que en Google no hay resultados relacionados.
    Me pregunto si simplemente significa “muy inflado”. Al leer más del sitio vi expresiones como “simulación física hiperrealista”, así que parece que al final significa “muy inflado”.

• La postura de que “la mayoría de los juegos de Unity se ven muy mal incluso si usan shaders llamativos, normal mapping y otras técnicas” parece volverse cada vez más común entre cierta generación.
  Está claro que se perdió algún tipo de técnica de mapeo de texturas. Los fondos de Ikaruga son mejores de lo necesario, especialmente ese efecto simple de bosque al principio. Algunos simuladores de trenes de la era PS2 también lograban esto.
  Pero si una fuente de luz direccional fuerte como el sol ilumina un objeto brillante y el jugador se mueve, este método se viene abajo. Si el entorno está nublado y no hay objetos dinámicos, se pueden esquivar bastante los trucos modernos.

  • Exacto. El problema es que algunos juegos modernos están nublados y no tienen iluminación dinámica, pero aun así usan Lumen porque sí. El remake de Silent Hill hacía eso: corre lentísimo, se ve peor en PS5 Pro, y hasta el pasto se ve peor que en juegos antiguos.
    La ambientación original de Silent Hill se creó para justificar trucos de optimización. Para facilitar la gestión de objetos en pantalla, tenía un espacio permanentemente cubierto de niebla, una “zona de niebla”; el remake, en cambio, desperdicia una enorme cantidad de procesamiento intentando crear niebla realista en vez de una niebla de aspecto sobrenatural.
  • Los juegos atractivos hechos con Unity no se ven “como juegos de Unity”, así que la gente no los piensa como ejemplos de “cómo se ve un juego de Unity”. Por eso el estereotipo del juego de Unity sigue siendo “bastante tosco”.
    Las habilidades artísticas para hacer que algo se vea bien no desaparecieron en absoluto; simplemente están distribuidas de forma muy desigual. Si un equipo tiene buenos modeladores, artistas de texturas, animadores y capacidad de programación visual, puede verse excelente ya sea con Unreal, Unity o un motor propio.
  • Existe la insistencia de que los materiales por sí solos pueden compensar un texturizado y un normal mapping deficientes. No es cierto; es el resultado de malinterpretar o distorsionar el marketing de cosas como Unreal Engine.
    En Super Mario Sunshine, las sombras “nítidas” que GameCube no podía renderizar en realidad usaban mallas planas. En Delfino Plaza, la sombra bajo el toldo cerca de Shine Gate no es una textura, es una malla. En cambio, la razón por la que la plaza de mosaicos donde cae esa sombra se ve bien no es una textura enorme, sino decenas de texturas de 128x128px correctamente mapeadas con UV.
    Un juego moderno usaría dos texturas de ladrillo y un patrón de ruido para mezclarlas, las tres de 2048x2048px, y la sombra tendría bordes nítidos mediante ray tracing. Irónicamente, aunque aumentaron la VRAM y la velocidad del bus, elegimos texturas más grandes en vez de más texturas. Con el normal mapping pasa lo mismo: en vez de usarlo junto con modelos más subdivididos, creemos erróneamente que los normal maps son anticuados y que modelar todos los detalles de verdad es el camino técnicamente más avanzado. Una esfera menos angulosa está bien, pero modelar físicamente cada grieta y rayón de una esfera es tonto y un desperdicio de cómputo.
  • Con algo como Unity puedes hacer que algo funcione bastante rápido, pero lograr que se vea realmente genial requiere habilidades y pulido aparte.
    Incluso un juego “2D” como Factorio tiene una diferencia enorme de pulido entre su primer lanzamiento, la versión 1.0 y la versión actual. Esta diferencia también es evidente en juegos con mods: los assets de mods suelen ser “utilizables”, pero no se ven tan pulidos como los del juego base.

• Hace poco volví a jugar Half-Life 2 y me sorprendió lo bien que se sigue viendo hoy, incluso sin paquetes de texturas en alta resolución.

  • Creo que esto se debe a que eligieron un estilo artístico extremadamente inteligente. Hay muchas superficies de reflexión difusa donde el horneado previo de iluminación funciona muy bien, y el cielo nublado permite luz ambiental difusa en lugar de una iluminación direccional que obligue a usar sombreado dependiente del ángulo y contornos de sombras duros y de alto contraste.
    También ayuda que la mayoría de las superficies brillantes no sean demasiado lustrosas. Estas decisiones encajan de forma creíble con un mundo viejo, ocupado y extremadamente distópico, y las texturas de colores apagados unifican todo.
  • Por eso creo que una dirección de arte realmente buena siempre vence al rendimiento gráfico puro. Source ya era impresionante en su época, pero lo que aguantó el paso del tiempo es lo cuidadosamente diseñados que están los entornos y modelos.
    Valve concentró sus recursos en meter detalle dentro de las limitaciones técnicas y exprimirlas al máximo, y 20 años después sigue viéndose cohesivo y bien diseñado.
  • Half-Life 2 recibió varias actualizaciones de shading y nivel de detalle después del lanzamiento, así que se ve un poco mejor que cuando salió. Aun así, ya era un juego visualmente impresionante en su momento.
  • Volví a jugar Half-Life 2 hace menos de una semana y terminé pensando que “aunque los niveles no estén tan llenos de detalle como los de los juegos modernos, la dirección artística de los gráficos y el diseño de niveles es mejor que la de muchos diseñadores modernos con presupuestos mucho mayores”.
  • Black Mesa, el remake de HL1 en el motor de HL2, también vale la pena. Lo jugué durante la pandemia y no me arrepiento.

• Como alguien que trabaja en un equipo pequeño haciendo un juego low poly con Godot, esto está genial.
  Me resonó mucho eso de “cuando construyes algo con nodos tienes que ir y venir constantemente entre la GUI de nodos y el código” y “los motores mainstream tienen un único editor de juegos enorme, y sin importar qué función uses tienes que esperar 10 minutos a que cargue todo”. Incluso en Godot casi no usamos funciones vistosas, pero el ciclo de depuración se sentía muchísimo más lento que cuando programo en otros entornos.
  También me gusta la idea de varios editores trabajando alrededor de una especificación única de archivos de datos. Un IDE integrado facilita que varios desarrolladores generen conflictos de merge, así que editores con propósitos más específicos también podrían ayudar a que desarrolladores con distintos roles limiten el alcance y la naturaleza de sus cambios. Me interesa ver cómo evoluciona el motor.

  • Me dio bastante orgullo haber descubierto en el hackatón del mes pasado cómo hacer desarrollo guiado por pruebas de módulos C# sin abrir Unity.
    Incluso con una netbook poco potente pude aportar mi parte. Nunca había escrito ni una línea de C#, pero no pensaba renunciar al TDD desde la línea de comandos. Descubrí que era posible y al final lo hice funcionar. Todos pensaban que estaba loco, y los encargados de relaciones con desarrolladores del patrocinador no sirvieron de nada.
    La mayor fricción de ese fin de semana seguía siendo que la mejor computadora tenía que perder una eternidad abriendo y reabriendo el maldito IDE de Unity. Es increíble las cadenas que la gente tolera.

• Usa términos como “Turbobloat” y dice que los motores están “inflados”, y hasta cierto punto tiene razón. Pero valdría la pena explicar qué significa eso para él, qué funciones considera bloat y qué quitó del proyecto Tramway.
  Por ejemplo, para algunas personas incluir un framework de RPG podría considerarse bloat, y Tramway lo incluye.

  • Por eso lo puse como extensión opcional. Forma parte del proyecto de motor más grande, pero es totalmente opcional.
    Me gusta el principio de C++ de “solo pagas por lo que usas”.

• Dice “Cómo usar el framework para principiantes a quienes C++ les da miedo o simplemente no se les da”, y yo soy de los segundos, así que agradecí la página Getting Started
  Apareció una tetera y entendí cosas que pensé que no iba a entender. Ahora solo tengo 30 minutos para almorzar y no me da tiempo de terminar el tutorial, pero el hecho de que me haya dado ganas de seguir muestra lo divertido y accesible que es este documento.

• ¿Alguien encontró la página Design Patterns? Es un marcador con una meta del 100% y me encanta

  • Está enlazada en la página de inicio: “Patrones de diseño usados: 82%. Cuando usemos todos los patrones, borraremos el proyecto y lo reescribiremos en Rust. Sin orientación a objetos”
  • La busqué un buen rato, pero todavía no la encuentro