El juego de cartas que hacemos entre dos

Mi hijo tiene cinco años y una forma bastante eficiente de dirigir un producto: me dice qué quiere jugar. Quiere abrir sobres, juntar cartas, armar un mazo, pelear contra alguien y volver a probar cuando algo no sale. No hace falta escribir un PRD para entenderlo.

Yo tomo esas ideas y las convierto en encargos para OpenCode. El agente lee el proyecto, propone cambios, escribe código y prueba lo que hizo. Detrás usa MiniMax M3; para arte y búsqueda de referencias tenemos también la CLI mmx. El loop es corto: una idea, una implementación, una pantalla para tocar y una conversación nueva sobre qué falta.

El resultado se llama Fragmentos del Nexo: un juego táctico de cartas 1v1 hecho para teléfono. No es una demo de tres pantallas ni un generador de imágenes sueltas. Tiene colección, tienda, créditos, sobres, sorteos, editor de mazos y una batalla que se puede jugar de principio a fin.

De una idea a una pantalla

La parte más interesante no es pedirle a un modelo que "haga un juego". Eso devuelve una maqueta y se termina rápido. El trabajo real es sostener el contexto para que cada cambio caiga donde corresponde.

Cuando aparece una idea nueva, la traduzco a algo que OpenCode pueda verificar dentro del repo: una vista nueva, una regla de cartas, un ajuste del flujo de compra o una pieza de la batalla. El agente no tiene que adivinar qué es Fragmentos: tiene el monorepo, las reglas del motor, las convenciones de UI y los tests como contexto.

Eso permite avanzar sin convertir cada pedido en una reescritura. Si alguien quiere una biblioteca de cartas, no alcanza con dibujar un grid lindo. Hay que decidir de dónde viene el contenido, cómo se muestra una carta, qué pasa al elegirla y cómo vuelve a aparecer dentro de un mazo o de una partida.

Una colección para tocar

La colección es el centro del juego. Ahí viven las cartas que ya existen, los líderes, los mazos disponibles y el material que se puede usar para construir algo nuevo. La tarjeta no es una imagen pegada arriba de un botón: se renderiza siempre con las mismas superficies compartidas para que una carta se vea igual en la colección, en la tienda y en batalla.

La captura muestra uno de esos puntos de entrada: un clan, su líder y las acciones que siguen. Desde ahí se puede ir a batalla, tienda, colección o editor. El juego tiene que ser navegable antes de ser explicable; a los cinco años la paciencia para una arquitectura elegante pero invisible es limitada.

Sobres, créditos y sorteos

Una carta tiene más gracia cuando aparece como parte de un sistema. Por eso Fragmentos tiene créditos para comprar sobres, una tienda con packs destacados y sorteos periódicos de cartas. No es una economía de verdad ni pretende serlo: es la forma de que conseguir una carta, abrir un sobre y elegir qué guardar sean acciones distintas dentro del juego.

El contenido de un pack se integra al mismo sistema que usa la colección. Una carta obtenida no queda aislada en una pantalla de apertura: puede terminar en un mazo y después en el campo de batalla. Esa continuidad es lo que vuelve al pack parte del juego y no una animación de premio.

Mazo y batalla

El editor de mazos es donde la colección se convierte en estrategia. Elegís cartas, armás una combinación y la llevás a batalla. La interfaz de combate tiene turnos, unidades, ataques, habilidades y un estado que se actualiza con cada acción. El motor es determinista: con la misma semilla y la misma secuencia de acciones puede reproducir una partida. Eso sirve para que una regla se pueda probar y corregir sin depender de "a mí me pasó una vez".

El motor, el contenido y la interfaz son piezas distintas porque cambian a ritmos distintos. Las reglas puras viven en el dominio y el motor; las cartas se registran como ContentSlice; la web consume esos contratos. Esa separación no está para impresionar a nadie: está para poder agregar una carta o ajustar un efecto sin romper la tienda, el mazo o una partida que ya existe.

Packs que nacen de un prompt

En el mismo proyecto agregamos skills para producir contenido. Una sirve para diseñar cartas, líderes, mazos y packs; otra usa mmx para generar ilustraciones o buscar referencias en internet. El resultado no entra al juego de cualquier manera.

El flujo valida los slugs y el manifiesto del pack, normaliza las ilustraciones al formato que espera el juego y conserva los metadatos necesarios para saber de dónde salió cada asset. Cuando se usan referencias externas, una etapa de visión revisa que sean apropiadas, que no tengan texto, logos ni marcas de agua y que sirvan para una carta. Después el contenido pasa por las validaciones del proyecto antes de ser consumible.

Eso cambia la escala de la conversación. En vez de construir cada carta a mano desde cero, puedo abrir OpenCode y decir: "hagamos un pack de dinosaurios", "quiero una colección de Digimon" o "armemos cartas inspiradas en Pokémon, Star Wars o Boku no Hero". El modelo propone el material, las skills lo convierten en assets y definiciones utilizables, y el sistema decide qué entra.

No se trata de apretar un botón y mirar cómo aparece un juego terminado. Se trata de poder seguir una afición nueva sin empezar un proyecto nuevo. Una colección temática puede nacer de un prompt, pero termina siendo parte del mismo juego: tiene sobres, cartas, mazos, reglas y batallas.

La herramienta no reemplaza la conversación

OpenCode en producción es la pieza que hace viable este ritmo. El agente puede leer el proyecto completo, tocar los archivos correctos, correr validaciones y devolver una implementación que después se puede probar en el teléfono. MiniMax M3 acelera la producción; mmx acelera el trabajo de contenido e imágenes.

Pero el producto no lo decide el modelo. Lo decide la conversación que viene antes: qué quiere jugar mi hijo hoy, qué parte todavía no se entiende y qué vale la pena convertir en una regla permanente. Fragmentos es el lugar donde esas respuestas dejan de ser una idea y se vuelven cartas para tocar, abrir y jugar.