Saltar al contenido
D&D Labs
InicioOneshotsPJsCantar de PullasPartidas

El equipo · 7 LLMs locales

Los agentes de Murray's Lab

Detrás de cada oneshot D&D 5e publicado en Murray's Lab no hay un solo modelo escupiendo un módulo: hay una mesa de siete agentes que discute, vota, corrige y firma. Cada uno tiene su rol, su modelo de IA local, su sitio en el pipeline y su voz.

La mesa que decide

Los tres agentes de la mesa votan por mayoría en cada fase de creación. Sus votos pesan lo mismo: 1-de-3 gana, empate (1-1-1) abre ronda extra.

El cierre

Cuando la mesa cierra todas las fases, entra Marga. Lee el módulo entero y devuelve correcciones hasta que algo cuadra. No vota en mesa; firma al final.

El equipo post-mesa

Tras la firma de Marga, tres roles técnicos transforman el material narrativo en un módulo publicable: prosa pulida, JSON estructurado e ilustraciones.

Cómo fabrican un oneshot — paso a paso

Once fases. La mesa va por delante; Marga cierra; el equipo post-mesa pule, estructura e ilustra; el último paso despliega el módulo en la web.

  1. 01

    Premisa

    Iris Vela · Damián Tachón · Rubén Veinte

    Iris propone 3 premisas. Damián y Rubén las pinchan en busca de clichés, plot holes o ideas que ya hicimos. Los 3 votan; gana mayoría.

    Sale de aquí: Premisa cerrada con título, nivel, tono, 4 PJs en una línea, gancho y conflicto.

  2. 02

    Outline

    Iris Vela · Damián Tachón · Rubén Veinte

    Iris escribe el esqueleto del módulo en 3-6 capítulos (cabeceras parseables). Cada capítulo lleva arco, lugar principal, objetivo narrativo y número estimado de escenas. Debate y voto.

    Sale de aquí: Outline aprobado con N capítulos definidos.

  3. 03

    Reparto

    Iris Vela · Damián Tachón · Rubén Veinte

    Iris escribe el reparto: 4 PJs pregenerados con ficha completa de jugador (apariencia, rasgos, ideal, vínculo, defecto, manías, historia), NPCs, enemigos y lugares. Lint automático de nombres impide conflictos PJ↔NPC↔víctima.

    Sale de aquí: cast.md con todos los personajes y lugares.

  4. 04

    Escenas por capítulo

    Iris Vela · Damián Tachón · Rubén Veinte

    Para cada capítulo del outline, la mesa pacta cuántas escenas tiene (3-10) y qué pasa en cada una: lugar, presentes, situación inicial, ACCIÓN DEL JUGADOR concreta, posibles resultados y cambio de estado al final. La escena que no cambia nada, se descarta.

    Sale de aquí: chapter-NN/outline.md con el plan de escenas por capítulo.

  5. 05

    Prosa escena a escena

    Iris Vela · Damián Tachón · Rubén Veinte

    Iris escribe la prosa de cada escena individualmente (~250 palabras). La mesa critica con reglas anti-prosa-IA (no metáforas anidadas, no sinestesias gratuitas, no "no era X sino Y" ornamental, no efectos mágicos sin nombrar) y vota antes de pasar a la siguiente.

    Sale de aquí: chapter-NN/scene-MM.md por cada escena aprobada.

  6. 06

    Briefs

    Iris Vela

    Iris consolida dm_brief (resumen del DM, secretos, final canónico, outcomes éxito/fracaso/parcial/epílogo) + player_brief (3-6 frases sin spoilers, para leer al grupo) + prompt de portada en inglés para Lucía Trazo.

    Sale de aquí: dm_brief.md · player_brief.md · cover_prompt.txt

  7. 07

    Revisión final

    Marga Veto

    Marga lee el módulo entero (premisa + outline + reparto + escenas + briefs) y devuelve una lista de defectos con cita literal: ambigüedades, plot holes, conflictos de nombres, falta de agencia del jugador, prosa-IA superviviente, mecánica D&D dudosa, repetición con módulos pasados. Loop iterativo: la mesa corrige y Marga relee. Hasta que firma.

    Sale de aquí: final_review.md con las rondas de correcciones y veredicto.

  8. 08

    Corrección ortotipográfica

    Sebas Tilde

    Sebas hace un pase silencioso: tildes, faltas, concordancias y nombres propios inconsistentes contra el reparto. No reescribe. Si rompiera la estructura, fallback automático al material de la mesa.

    Sale de aquí: scenes/*.md actualizados en sitio.

  9. 09

    Maquetación

    Pablo Folio

    Pablo Folio convierte todo el material narrativo en un JSON D&D 5e estructurado: metadatos, dm_brief con outcomes, player_brief, chapters[].scenes[] jerárquico con prosa por escena, characters con ficha completa, npcs con stats básicos, enemies con stat-block SRD, locations, image_prompts en inglés.

    Sale de aquí: module.json final + image_prompts listos para Flux.

  10. 10

    Ilustración

    Lucía Trazo

    Lucía Trazo lee image_prompts y genera todas las imágenes (cover, 4 PJs, NPCs, enemigos, 1 imagen por capítulo, lugares) con Flux schnell sobre ComfyUI. Estilo Wayne Reynolds D&D 5e PHB unificado. Mientras Flux trabaja, Ollama se descarga para no competir por VRAM.

    Sale de aquí: images/*.png — entre 15 y 20 imágenes por módulo.

  11. 11

    Publicación

    Publicador

    publish_module.py anuncia el módulo en el canal de Telegram (cover + briefs + capítulos) y auto_deploy.py copia el JSON+imágenes al repo de murrayslab, regenera el índice, hace commit y dispara el rebuild en el VPS. Pipeline 100% automático GMK (local) → main → VPS.

    Sale de aquí: Módulo online en murrayslab.com/dndlabs/oneshots/<slug>/.

El pipeline completo de un módulo tarda entre 1 y 3 horas en local del Lab (sin GPU dedicada para Ollama, GPU para Flux schnell). Todo el debate se publica en directo en el canal de Telegram.

Por qué siete y no uno

Un solo modelo escribiendo un módulo entero produce prosa-IA: metáforas anidadas, descripciones sin información útil, conceptos sobrenaturales sin nombrar, personajes que filosofan en vez de jugar y finales sin agencia del jugador. Lo intentamos en módulos previos y se notaba en mesa: se leía como literatura pero no se podía jugar.

La mesa de tres con voto resuelve dos cosas: cada modelo tira hacia su oficio (Iris pluma, Damián filo, Rubén mecánica) y ninguno cierra una decisión sin contraste. Marga al final filtra lo que se les coló a los tres. Sebas corrige sin reescribir. Pablo Folio estructura sin inventar. Lucía Trazo da el acabado visual. Cada uno con su modelo y temperatura calibrada para su tarea.