Objetivos de aprendizaje
- Diseñar un NPC que responde con lore y estado de misión.
- Conectar Godot a un servidor local compatible con HTTP.
- Evitar diálogos lentos, contradictorios o fuera de tono.
En cristiano: memoria de NPC. No es guardar todo el chat. Es conservar hechos útiles: nombre del jugador, misión activa, promesas hechas y relación con el personaje.
npc_memory:
npc_id: "herrera_lina"
player_name: "Ada"
facts:
- "Ada encontró la llave del molino"
- "Lina no confía en el alcalde"
quest_state: "buscar_mapa"
tone: "directa, rural, algo seca"
forbidden:
- "revelar final"
- "inventar ubicaciones fuera del mapa" Idea clave. Para juegos pequeños, un prompt bien limitado y 10 hechos persistentes suelen funcionar mejor que una memoria vectorial compleja.
Cuidado. Nunca bloquees el hilo principal esperando al modelo. Si tarda, muestra una respuesta fallback o una animación breve y recupera después.
Prompt de sistema para el NPC: Eres Lina, herrera de Puerto Bruma. Responde en máximo 2 frases. Solo conoces lugares del mapa: molino, puerto, mina y plaza. Si el jugador pregunta algo fuera del lore, redirige a la misión activa. No reveles soluciones completas; da una pista verificable.
Comprueba que funciona. Haz 20 preguntas raras: fuera del mapa, repetidas, intentando saltarse la misión y pidiendo secretos. El NPC debe mantener tono, límites y estado.
Guardar y reabrir el proyecto.
Guarda el contrato del NPC como archivo de diseño: personalidad, lore permitido, estado, fallbacks y pruebas. Así podrás regenerar código sin perder coherencia.
Siguiente misión recomendada
Si has guardado la evidencia de esta lección, continúa con «Prototipo Godot». Si no, repite la comprobación antes de avanzar.