Modelo de Datos

Modelo de Datos

Entidades principales

• USER — jugador registrado, identificado por UID de Firebase Auth
• GAME — partida entre dos jugadores, incluye estado y turno actual
• GAME_META — metadatos de cierre (ganador, motivo, timestamps)
• MOVE — movimiento individual dentro de una partida

---

USER

Campos:

• uid (PK) — UID de Firebase Auth
• email — correo del jugador
• displayName — nombre visible en UI

---

GAME

Campos:

• gameId (PK) — ID único de la partida
• player1Uid (FK → USER) — UID del creador
• player2Uid (FK → USER) — UID del segundo jugador
• status — WAITING · EN_CURSO · FINALIZADA · ABANDONADA
• currentTurn — UID del jugador con turno activo
• createdAt — timestamp de creación (servidor)

---

GAME_META

Campos:

• gameId (PK, FK → GAME)
• winner — UID del ganador, o null si empate/abandono
• endReason — VICTORIA · ABANDONO · TIEMPO
• startedAt — inicio efectivo de la partida
• endedAt — fin de la partida

---

MOVE

Campos:

• moveId (PK) — UUID generado en cliente
• gameId (FK → GAME)
• playerUid (FK → USER)
• clientNonce — nonce único por intento (dedupe de reintentos)
• clientTs — timestamp local del cliente
• from / to — celdas origen y destino (ej. "e2", "e4")
• piece — pieza movida (ej. "P", "R", "Q")
• state — PENDING · CONFIRMED · REJECTED (solo cliente, no se persiste en RTDB)

---

Notas de diseño

• Dedupe por clientNonce: las reglas RTDB rechazan writes con un nonce ya existente en la partida.
• Optimistic update: el cliente aplica el movimiento con state = PENDING; si el servidor devuelve 403, se hace rollback.
• Write atómico: PATCH multi-path actualiza moves/<moveId> y currentTurn en una sola petición.
• GAME_META se anida bajo games/<gameId>/meta para que un único listener reciba el cierre de partida.