Proyecto M
ARPG / dungeon crawler de acción en tiempo real, desarrollado en solitario en Unity. El foco está en dos cosas: que el combate responda bien y que el jugador pueda construir su estilo de juego combinando habilidades, pasivas, especialización y equipamiento.
Es un proyecto a largo plazo. Antes de añadir contenido, el objetivo es tener una base de sistemas sólida y bien documentada — una arquitectura que permita escalar sin reescribir. Todo el trabajo actual va en esa dirección.
El sistema de tags define qué es una habilidad y qué modificadores pueden afectarla. Eso hace que una build de arco con flechas que generan cadenas de rayo sea posible no porque esté hardcodeada, sino porque la arquitectura lo permite de forma natural. La elección de arma no dicta el estilo de juego — las especializaciones, los Myths y el equipo sí.
Los Myths son items que definen el núcleo de una build — se vinculan a una leyenda del pasado y dan capacidades que ningún otro sistema da. Pero el coste nace del mismo sitio que la ventaja: no es un penalty de balance numérico, es coherencia interna. Un personaje poderoso domina los términos de su historia; lo que lo hace excepcional también lo define.
Los ailments no son "daño con sabor". Chill ralentiza y puede acumularse hasta Freeze; el siguiente impacto desencadena Shatter. Shock habilita cadenas de rayo que consumen la carga. Bleed ignora la armadura. Cada elemento tiene una fantasía de juego distinta que cambia cómo juegas, no solo qué número aparece en pantalla.
La parte que más iteraciones ha requerido no es el combate en sí — es conseguir que el personaje se sienta bien de controlar. Hay una brecha enorme entre "el personaje se mueve" y "tengo un control del personaje completo".
Trabajé muchas iteraciones en el MovementController:
curvas de aceleración y deceleración, suavizado de rotación,
velocidad de giro diferenciada según el estado (locomotion vs
durante una acción), avoidance con enemigos, y una
cola de inputs con ventana de expiración para que
el juego responda a la intención del jugador sin que se sienta que
los inputs se pierden o se acumulan.
El criterio fue simple pero difícil de alcanzar: moverse durante 30–60 segundos solo por moverse tiene que sentirse bien. Los cambios de dirección no pueden sentirse pesados ni resbaladizos.
El estilo de cámara isométrica añade una capa extra de dificultad: con una perspectiva cenital fija, cualquier imprecisión en el movimiento se percibe de inmediato. No hay un ángulo de cámara que lo disimule — el personaje tiene que sentirse preciso y responsivo por sí solo, lo que eleva el listón de cada una de las iteraciones anteriores.
Cuando el jugador pulsa una habilidad durante el recovery de otra, el input no se pierde — se encola con una ventana de expiración. Si la condición se cumple antes de que expire, la acción se ejecuta. Esto elimina la frustración de "pulsé el botón y no pasó nada" sin romper el ritmo del combate. Todo esto ocurre en fracciones de segundo.
Core independientes de quién los usa.
Features contiene la implementación por actor —
Player, Enemy. Un DamageInfo
es el mismo venga del jugador o de un enemigo. Esto permite
cambiar o ampliar actores sin tocar la lógica del juego.
AbilityDefinition — un
ScriptableObject que define timing (cast, active, recovery), tipo
de hitbox, canal de daño, costes y qué puede cancelar qué. La
lógica de ejecución (AbilityExecutor) es genérica.
Añadir o iterar una habilidad es cuestión de configurar un asset,
no de escribir código nuevo.
Click-to-move con aceleración/deceleración, rotación hacia cursor diferenciada por estado, avoidance con enemigos y cola de inputs con expiración.
DamageInfo → resolución por canal (weapon/skill) → elementos → críticos → DamageResult. WeaponHitbox con HashSet para evitar impactos múltiples por frame.
AbilityDefinition (SO) → AbilityInstance (runtime) → AbilityExecutor (fases cast/active/recovery). Tags por bitflags, hitboxes por tipo, cancelaciones configurables.
StatsController con AttributeBlock, modificadores por tipo (flat/percent), recursos con regeneración. Base para escalar con equipo y especializaciones.
Estados Locomotion, Dash, Attack y Death. Transiciones controladas, integración con input queue y sistema de cancelaciones por estado.
Idle, Chase, Attack, Hit y Death. EnemyController comparte la misma infraestructura de combate y habilidades que el jugador.
Object pooling, event system desacoplado (GameEvents), audio, scene management, hit feedback (freeze frame, screen shake) y utilities.
HUD con vida, recursos y slots de habilidades. Stack de diálogos modales (error/confirmación) con pausa de tiempo y bloqueo de input por capas.
Motor de modificadores flat/additive/more con duración, stacks y fuente rastreable. Tags por bitflags definen qué es cada habilidad y qué modificadores pueden afectarla — son el mecanismo que hace posibles builds cruzadas (arco elemental, mago físico, etc.).
6 ailments con identidad táctica propia — Ignite (stacks), Chill→Freeze→Shatter, Shock→Chain, Bleed (ignora armor), Radiant Mark y Dread. Chance y potency modulados por Affinities con retornos decrecientes.
3 specs equipables simultáneamente, cada una con árbol propio de activas, pasivas y keystones. Definen el "cómo juegas" sin forzar arquetipos de arma — arco elemental, mago de control, build de ruptura física.
Un slot especial que vincula al jugador con una leyenda del pasado. Árbol de pasivos propio, ventaja que define la build y coste que nace del mismo origen. Respec vía Echoes (Ecos) obtenidos en contenido.
Dungeons handcrafted con múltiples rutas y decisiones de gestión. Modificadores por run que alternan el reto. Diseñado modular — nuevos afijos, Myths y modificadores sin reescribir el núcleo.
Algunos sistemas están documentados en detalle con código y razonamiento: