Aprender AI-DLC creando un juego, parte 8: incepción

Esta es la parte 8 de una serie sobre aprender AI-DLC creando un juego, World Rift Conflict, en Godot con un backend en AWS. La parte 7 convirtió una idea de una página en un alcance aprobado. Este artículo cubre la Incepción: nueve etapas que convierten ese alcance en algo con lo que se puede empezar a construir.

Partes hasta ahora:

• Parte 1: configuración
• Parte 2: prueba de concepto
• Parte 3: pruebas E2E automatizadas
• Parte 4: lo que hallaron las revisiones
• Parte 5: dentro de una etapa
• Parte 6: un bugfix
• Parte 7: ideación
• Parte 8: incepción (este artículo)

Resumen

1. Nueve etapas: Ingeniería Inversa, Descubrimiento de Prácticas, Análisis de Requisitos, Historias de Usuario, Bocetos Refinados, Diseño de Dominio, Generación de Unidades, Diseño de Contratos y Planificación de Entrega.
2. El resultado: 50 requisitos funcionales y 10 no funcionales, 31 historias, 10 pantallas, 13 componentes, 7 unidades de trabajo, 10 contratos y un plan de 6 Bolts, con el esqueleto funcional primero.
3. Seis revisiones dejaron 50 hallazgos. Aprobé cada etapa con sus hallazgos abiertos, y los mismos huecos volvían una y otra vez.
4. Un script detectó un conteo erróneo que yo ya había dado: 31 historias, no 29.
5. La comprobación final pasó: cada requisito se traza a una historia, un componente y una unidad.

Escanear el código otra vez

La Ingeniería Inversa volvió a escanear todo el proyecto, porque la base de conocimiento del código estaba desactualizada. Encontró 44 componentes y siete huecos entre el código de hoy y el juego. La única pantalla es el inicio de sesión. El backend solo hace inicio de sesión. El plugin de Amplify para Godot envía sus actualizaciones en vivo como peticiones web normales, así que no puede llevar partidas en vivo.

Ese último dato importa después. Es la primera restricción técnica dura del diseño.

Prácticas para un juego de verdad

El Descubrimiento de Prácticas ya se había hecho, para el trabajo de pruebas. Esta vez se repitió tomando las prácticas afirmadas como base y preguntó solo lo que el juego cambia. Doce preguntas lo resolvieron.

• El esqueleto funcional, una porción mínima que funciona de punta a punta y se construye primero para probar que las piezas encajan, es una partida contra países manejados por la computadora en la versión web, más el resultado del jugador guardado en el backend.
• Las pruebas de extremo a extremo pondrán a varios jugadores en una partida.
• Web y Linux pasan cada requisito. Windows y macOS tienen una prueba rápida.
• Seis reglas de producto de la Ideación pasaron a ser reglas permanentes del proyecto, como nada de pagar para ganar y nunca guardar números de tarjeta.

De los requisitos a 31 historias

El Análisis de Requisitos hizo diez preguntas. Una respuesta cambió el alcance aprobado: 15 rondas de 60 segundos dan una partida de unos 15 a 20 minutos, no de 20 a 30. AI-DLC lo escribió como algo que reemplaza el alcance y no tocó el documento aprobado.

La revisión dijo que los requisitos no estaban listos. Tratados, comercio y conflictos no tenían reglas, el emparejamiento no estaba definido y la prueba de equilibrio era demasiado pequeña para detectar nada. Aprobé igual. Luego las Historias de Usuario ofrecieron resolver los huecos importantes, y cinco preguntas cortas los cerraron.

• Una propuesta se responde dentro de la ronda, y no responder cuenta como rechazo.
• El equilibrio se comprueba con 200 partidas simuladas.
• El emparejamiento espera 30 segundos y luego completa la partida con países de la computadora.
• Si ninguna fuente de datos económicos sirve, se usan datos de desastres o del clima.
• Los nombres visibles tienen de 3 a 16 caracteres y el correo nunca se muestra.

El diseño en cuatro pasos

• Bocetos Refinados: diez pantallas, un esquema oscuro en el que cada color de país va con un símbolo y un nombre, una ventana mínima de 1024 x 600, y una respuesta nueva: inglés y español.
• Diseño de Dominio: 13 componentes en torno a un núcleo de reglas puro, compartido por el esqueleto y el juego en vivo. Un anfitrión autoritativo es dueño de cada partida en vivo, como recomienda la guía de multijugador de Godot.
• Generación de Unidades: siete unidades de trabajo, cortadas como porciones de funcionalidad, con el esqueleto como único punto de partida.
• Diseño de Contratos: diez contratos escritos como operaciones y mensajes, porque dejé el transporte para etapas posteriores.

Seis Bolts

Un Bolt es una pasada de construcción sobre una parte del trabajo que termina en algo que funciona. El orden pone contenido y equilibrio justo después del esqueleto, porque lo que más me preocupa es si los países al azar dan un juego justo. Las herramientas del dueño van antes del juego en vivo, porque el juego en vivo es el mayor coste.

Bolt	Unidades	Prueba
B1	partida esqueleto	el núcleo de reglas juega una partida completa y un resultado llega al backend
B2	contenido y equilibrio	los países al azar pueden dar una partida justa
B3	cuentas y perfil	jugadores reales pueden entrar y salir dentro de las reglas de datos
B4	herramientas del dueño	el dueño puede controlar el coste y ver si los jugadores vuelven
B5	juego en vivo y datos	el juego en vivo funciona en el navegador y en escritorio por menos de $50
B6	versiones de escritorio	el mismo juego funciona como descarga

Lo que encontraron las revisiones

Seis revisiones consultivas dejaron 50 hallazgos. Consultiva significa que la revisión informa mi decisión pero no puede bloquearla. Aprobé cada etapa con sus hallazgos abiertos. Fue una decisión para seguir avanzando, y tuvo un coste: los mismos huecos volvían etapa tras etapa.

• El esqueleto: la revisión de historias encontró que su conjunto no encajaba. Luego la de dominio encontró que nada en el diseño guardaba el resultado de una partida local.
• El juego en vivo: las revisiones de unidades y de contratos encontraron sus enlaces que faltaban hacia los datos y las herramientas del dueño.
• La identidad: ningún componente comprobaba quién entra a una partida en vivo, hasta que apareció un token de acceso en los contratos.

Algunos hallazgos los cerraron etapas posteriores, como ahora pide una regla del proyecto. Otros siguen abiertos al empezar la construcción.

Pequeñas cosas que salieron mal

• Di 29 historias y 80 criterios en una aprobación. Al construir el catálogo de componentes con un script, salieron 31 y 78. Ahora los conteos los hace un script, nunca a mano.
• Copié un documento al registro con cp. La revisión se negó a empezar porque el archivo "no tenía una escritura registrada". Guardarlo otra vez con la herramienta de archivos lo arregló.
• Un subagente se detuvo por el límite de gasto mensual de la cuenta. Después de decir "continue", se retomó el mismo agente y terminó su trabajo guardado.

Lo que sigue

La Construcción: el Diseño Funcional del esqueleto funcional y luego el primer código.