Por qué JavaScript Vanilla
La pregunta más común sobre el stack tecnológico de CONTRABAND: ¿por qué no un motor de juego? La respuesta resultó ser sobre trade-offs que no apreciaba completamente cuando empecé.
La pregunta
Cada vez que alguien mira la arquitectura de CONTRABAND, preguntan lo mismo: "¿Por qué no Unity? ¿Godot? ¿Phaser? ¿Por qué construir todo esto desde cero?" Es una pregunta justa. Un motor de juego me habría dado renderizado de sprites, gestión de audio, manejo de input y transiciones de escena gratis. En lugar, construí todo eso.
La respuesta honesta es que empecé con vanilla porque quería aprender, y seguí con vanilla porque resultó ser la elección correcta para este juego en particular. No todos los juegos. No todos los desarrolladores. Este.
Lo que vanilla me dio
Tamaño de archivo
El juego CONTRABAND entero está por debajo de 120KB de código. Incluyendo assets (el audio es procedural, los retratos son ASCII, solo los modelos de naves son archivos GLB), el payload completo que un usuario descarga es de aproximadamente 2-3MB — la mayor parte de los cuales es el propio Three.js. Un build de Unity WebGL para un juego equivalente sería de 20-50MB. Esa diferencia de tamaño significa que mi juego carga en segundos en un móvil. Un juego Unity carga en 15-30 segundos, que es suficiente tiempo para que un jugador cierre la pestaña y nunca vuelva.
Velocidad de arranque
De clic en URL a jugable en menos de 2 segundos en un móvil moderno. Sin calentamiento del motor. Sin streaming de assets. Sin compilación de shaders. El jugador hace clic en un enlace y el juego comienza. Esta es la mayor ventaja de jugabilidad individual de vanilla sobre motores: los jugadores que no pueden instalar nada en su dispositivo aún pueden jugar. Eso importa para un juego de navegador.
Arquitectura modular
Cada sistema en CONTRABAND es su propio archivo con una frontera limpia. El combate no sabe de historias. Las historias no saben de combate. Se comunican a través de un EventBus. Cuando añadí el sistema de monetización en v3.0, no modifiqué combate ni historia en absoluto — simplemente me suscribí a eventos existentes. Eso no es un beneficio exclusivo de vanilla, pero vanilla te fuerza a ello por defecto. En un motor, el camino de menor resistencia es acoplamiento fuerte a través de singletons compartidos.
Cero lock-in de vendor
Si Unity cambia su modelo de precios, aumenta las tarifas de licencia o (hipotéticamente) cierra, mi juego no se ve afectado. Los estándares web no se rompen. El JavaScript que escribí en 2024 correrá en navegadores en 2034. Esto importa más de lo que parece. Varios juegos indie construidos en Flash se volvieron injugables cuando Flash murió. Los juegos construidos en motores descontinuados están en modo museo. Los juegos construidos en estándares web son atemporales.
Lo que vanilla me costó
Todo lleva más tiempo
Escribir un renderizador de sprites, un sistema de audio y un sistema de guardado es trabajo que un motor habría hecho gratis. Gasté aproximadamente el 30% del tiempo de desarrollo en infraestructura que cualquier motor habría proporcionado. Para un desarrollador primerizo, esto fue aprender — valioso. Para alguien que ya conoce motores, sería desperdicio.
Sin conocimiento comunitario
Si me atasco con un problema de Unity, busco en los foros de Unity y encuentro a alguien que lo resolvió. Si me atasco con un problema vanilla-JavaScript juego-navegador, a menudo encuentro que nadie más está construyendo lo que estoy construyendo, así que no hay respuestas. Tuve que resolver la mayoría de las cosas solo.
Debuggear es más difícil
Las herramientas de desarrollo del navegador son excelentes para apps web, aceptables para código de juego y dolorosas para problemas específicos de Three.js. Unity tiene un profiler que te dice exactamente qué frames son lentos y por qué. El profiler de Chrome te da un flame graph que requiere interpretación. Mejoré leyendo flame graphs, pero llevó tiempo.
Lo que aprendí sobre el trade-off
El trade-off vanilla-vs-motor es esencialmente: velocidad de arranque y portabilidad (vanilla gana) vs velocidad de desarrollo y herramientas (motor gana). Para la mayoría de los juegos, el motor gana. Para un juego de navegador donde la audiencia puede tener dispositivos lentos, puede estar con datos móviles medidos y abandonará cualquier cosa que no cargue en 3 segundos — vanilla puede ganar.
CONTRABAND específicamente se beneficia de vanilla porque:
- Sus visuales no son un cuello de botella. No necesito un pipeline de renderizado.
- Su jugabilidad es guiada por texto-y-menú. No hace falta motor de física.
- Su economía depende de jugadores casuales que podrían probarlo en un móvil durante un viaje. El arranque rápido importa.
¿Lo haría de nuevo?
Para este juego: sí, absolutamente. La arquitectura encaja con el contenido. Para mi próximo juego, si tiene requisitos distintos — física en tiempo real, gráficos complejos, despliegue multi-plataforma — usaría un motor. Vanilla es un bisturí, no un martillo. Saber cuándo usar cuál.