Construir un motor propio: aprender rompiendo cosas
Después de definir que Nightfall Dominion existiría primero como un juego de cartas, el siguiente paso parecía lógico: hacerlo funcionar. No había todavía un engine adquirido, ni una base previa sólida. La única opción real era comenzar desde cero, con código propio, entendiendo cada sistema desde su fundamento.
Este post no es una celebración del “hacerlo todo a mano”. Es un registro honesto de lo que significa aprender desarrollando, incluso cuando el resultado no es el esperado.
Empezar sin red
El primer prototipo se construyó directamente en Unity, con C# puro y una estructura mínima. No existía un framework que resolviera turnos, estados de cartas o flujo de partida. Todo debía definirse:
- cómo ataca una unidad,
- cómo responde una IA,
- cómo se mueve un elemento en pantalla,
- cuándo una acción termina y otra comienza.
El objetivo no era crear algo escalable desde el día uno. Era entender el problema completo.
Las primeras mecánicas: movimiento, ataque, reacción
El foco inicial estuvo en lo más básico: lograr que una entidad hiciera algo visible.
Moverse. Atacar. Reaccionar.
Se implementaron animaciones simples, lógica de turnos rudimentaria y una IA básica capaz de tomar decisiones elementales. El resultado funcionaba… a veces. El juego respondía, pero de forma frágil. Cada nuevo comportamiento rompía otro.
Ahí apareció una verdad incómoda: hacer que algo funcione no significa que esté bien hecho.
La IA: cuando lo “simple” deja de serlo
Uno de los mayores focos de tiempo fue la inteligencia artificial. Decidir cuándo atacar, a quién, en qué orden. En teoría, eran reglas sencillas. En la práctica, cada excepción agregaba complejidad exponencial.
Pequeños cambios generaban comportamientos erráticos.
Animaciones que no terminaban.
Turnos que no cerraban.
Estados que quedaban colgados.
Nada era realmente grave… hasta que todo empezó a acumularse.
El costo invisible del control total
Tener control absoluto del código parecía una ventaja. Pero con el tiempo se volvió claro el costo real: mantenimiento.
Cada sistema dependía de otro. Cada corrección requería revisar múltiples scripts. Agregar una nueva mecánica implicaba reescribir partes que ya funcionaban. El proyecto avanzaba, pero cada paso era más pesado que el anterior.
El problema no era la falta de capacidad técnica. Era la falta de tiempo para convertir ese prototipo en algo robusto.
Aprender lo que no se ve
Aunque el motor propio nunca se convirtió en la base final del juego, dejó aprendizajes clave:
- Cómo estructurar turnos.
- Qué estados son realmente necesarios.
- Qué errores evitar al diseñar IA.
- Qué sistemas deben ser modulares desde el inicio.
Nada de eso fue tiempo perdido. Fue formación práctica.
Ese primer motor no era el juego. Era el entrenamiento.
El momento de aceptar un límite
Llegó un punto donde la pregunta dejó de ser “¿puedo hacerlo?” y pasó a ser “¿tiene sentido seguir así?”. El objetivo no era demostrar que se podía construir todo desde cero, sino terminar un juego funcional.
Reconocer ese límite no fue un fracaso. Fue una decisión estratégica.
Para que Nightfall Dominion pudiera crecer, necesitaba una base más estable, algo que resolviera problemas comunes y permitiera concentrarse en lo importante: diseño, mundo, experiencia.
Ese momento marcó el cierre de una etapa.
Por qué este paso fue necesario
Construir un motor propio permitió entender exactamente qué se estaba delegando cuando, más adelante, se adoptó un engine existente. No fue una elección ciega. Fue una decisión informada.
Este post existe para dejar claro algo: no todo lo que se descarta fue un error. Algunas cosas existen solo para enseñarte qué no repetir.
Estado al final de esta etapa:
- Prototipo funcional, pero frágil.
- Sistemas entendidos, no optimizados.
- Decisión tomada: buscar una base más sólida.
En el próximo post hablaremos de ese punto de inflexión: adoptar un engine existente en Unity, lo que resolvió, lo que no, y cómo se adaptó a la visión de Nightfall Dominion.
El proceso continúa.