Un solo motor de Quaternity, dos ramas de uso y una prioridad absoluta: resolver bien la foto de mate.

Principio estructural

El motor es unico. Academia y Juego no son dos sistemas distintos, sino dos formas de usar el mismo nucleo de reglas con capas de control y presentacion diferentes.

Arquitectura modular

Movimiento, validacion, jaque, mate, absorcion, zombi, turnos y debug deben evolucionar por separado. Cada modulo recibe estado y devuelve resultado sin contaminar el resto.

Rama Academia

• 1. Posiciones predefinidas y secuencias esperadas.
• 2. Validacion guiada y feedback inmediato.
• 3. Pistas, overlays y soluciones.
• 4. Flujo controlado y modo debug activo.
• 5. Objetivo: validar conceptos, no simular una partida completa.

Rama Juego

• 1. Partida completa desde posicion inicial.
• 2. Validacion total de reglas.
• 3. Turnos estrictos y resolucion abierta.
• 4. Sin ayudas ni restricciones pedagogicas.
• 5. Objetivo: simulacion real de Quaternity en condiciones competitivas.

Estado

• 1. Tablero completo.
• 2. Turno actual e indice de ciclo.
• 3. Ejercitos activos.
• 4. Estado de cada rey: `active`, `removed`, `zombie`.
• 5. Historial de movimientos y absorciones.

Modelo de pieza

• 1. `owner_army`.
• 2. `origin_army`.
• 3. `piece_type`.
• 4. `position`.
• 5. `move_profile` y direccion en peones.
• 6. `state`: `active`, `absorbed`, `zombie`.

Separaciones obligatorias

• 1. Amenaza.
• 2. Legalidad de movimiento.
• 3. Estado de jaque.
• 4. Estado de mate.
• 5. Defensa real.
• 6. Defensa virtual.

Orden de resolucion

1. 1. Aplicar movimiento.
2. 2. Resolver promocion.
3. 3. Evaluar jaques.
4. 4. Evaluar mates.
5. 5. Determinar ganador del mate.
6. 6. Aplicar absorcion.
7. 7. Actualizar estados.
8. 8. Validar estado final.
9. 9. Pasar turno.

Prioridades de reglas

1. 1. El mate valido tiene prioridad sobre el autojaque.
2. 2. Capturar al rey sigue siendo ilegal.
3. 3. El mate se resuelve en el instante en que aparece.
4. 4. La absorcion forma parte del mismo evento.
5. 5. No se esperan respuestas del jugador derrotado.

Rey zombi

• 1. Aparece por abandono, tiempo o no presentacion.
• 2. El ejercito zombi no amenaza activamente.
• 3. El mate al zombi se evalua con defensa virtual.
• 4. La defensa zombi no es defensa real.
• 5. El rey activo puede colocarse adyacente al rey zombi y completar el mate si no quedan casillas de escape no atacadas.

En este caso especial, la casilla del rey activo se evalua solo contra amenazas reales de ejercitos activos. La defensa virtual de piezas zombis sobre esa casilla se ignora.

Absorcion y peones

• 1. Tras el mate, las piezas cambian de `owner_army`.
• 2. Se conserva `origin_army`.
• 3. Los peones mantienen direccion original.
• 4. El color visual puede no coincidir con el origen funcional del peon.
• 5. La promocion absorbida sigue siendo inmediata y normal.

Multiples efectos en una jugada

• 1. Una jugada puede dar jaque a un jugador y mate a otro.
• 2. Puede producir mate indirecto o por configuracion.
• 3. Puede generar mates en cascada tras la absorcion.
• 4. Todos los mates de esa jugada deben resolverse de forma determinista.

Pasa y tablas

• 1. `pasa` existe si no hay jugada legal y no hay mate.
• 2. Con mas de dos jugadores, el jugador sigue en la partida.
• 3. Con dos jugadores, `pasa` equivale a tablas por rey ahogado.
• 4. El motor debe soportar acuerdo, triple repeticion, 50 movimientos e imposibilidad.

API interna recomendada

• 1. `buildGameState()`
• 2. `generateAttackMap()`
• 3. `generateLegalMovesForArmy()`
• 4. `applyMove()`
• 5. `isKingInCheck()`
• 6. `isCheckmatePosition()`
• 7. `resolveMate()`
• 8. `setZombieArmy()`
• 9. `evaluateZombieMate()`
• 10. `getDrawState()` y `canPassTurn()`

Capa de debug

• 1. Registro de movimientos.
• 2. Registro de jaques.
• 3. Registro de mates.
• 4. Registro de absorciones.
• 5. Registro de conflictos de reglas.
• 6. Soporte para correccion incremental sin romper el nucleo.