Dirección · 7 de 7
Terminar una experiencia pequeña de punta a punta antes de ampliar — y registrar cada cambio con su impacto en el plazo.
El prototipo 3D nació el 23/09/2026 con un objetivo escrito: entregar una demostración jugable para Windows en dos fines de semana (26–27/09 y 03–04/10), usando Godot, modelos producidos con Tripo y animaciones humanas, con una meta interna de conclusión el 04/10 y el envío al Tripothon S1 el 05/10. El orden de prioridad que definió el producto fue velocidad de desarrollo, luego calidad gráfica, luego capacidad de expansión técnica; la referencia visual es My Time at Evershine — dirección artística, no un compromiso de reproducir su escala ni su acabado.
Dos decisiones cambiaron el rumbo después de eso. El 29/09, el autor decidió que el 3D pasa a ser el juego completo, que el 2D pasa a ser la referencia de reglas y que la migración es la prioridad: el plan se convirtió en 32 issues en dos hitos, Jam 04/10 y Pós-jam. El 01/10, decidió mantener los juegos 2D y 3D en repositorios independientes, con el proyecto de Godot en la raíz y sistemas locales. El tablero es la fuente de los criterios de aceptación; la issue es la unidad de trabajo, y el documento es su porqué.
Decisiones de proyecto
Terminar una experiencia pequeña de punta a punta antes de ampliar — y registrar cada cambio con su impacto en el plazo.
El prototipo 3D nació el 23/09/2026 con un objetivo escrito: entregar una demostración jugable para Windows en dos fines de semana (26–27/09 y 03–04/10), usando Godot, modelos producidos con Tripo y animaciones humanas, con una meta interna de conclusión el 04/10 y el envío al Tripothon S1 el 05/10. El orden de prioridad que definió el producto fue velocidad de desarrollo, luego calidad gráfica, luego capacidad de expansión técnica; la referencia visual es My Time at Evershine — dirección artística, no un compromiso de reproducir su escala ni su acabado.
Dos decisiones cambiaron el rumbo después de eso. El 29/09, el autor decidió que el 3D pasa a ser el juego completo, que el 2D pasa a ser la referencia de reglas y que la migración es la prioridad: el plan se convirtió en 32 issues en dos hitos, Jam 04/10 y Pós-jam. El 01/10, decidió mantener los juegos 2D y 3D en repositorios independientes, con el proyecto de Godot en la raíz y sistemas locales. El tablero es la fuente de los criterios de aceptación; la issue es la unidad de trabajo, y el documento es su porqué.
9 principios
Lo que no se negocia
Pequeño y completo antes que grande
Terminar una experiencia de punta a punta antes de ampliar el número de sistemas, personajes o escenarios. La visión completa de gameplay (siembra, cría de animales, recolección, minería, pesca, crafting, economía, combate, quests, amistad, historia) no se confunde con el conjunto comprometido para cuatro días de producción. Una funcionalidad nueva debe reemplazar un esfuerzo equivalente o quedar fuera del compromiso de la jam.
Mantener Godot; Windows; un jugador; tercera persona
Godot Standard y GDScript, sin migrar a Unity ni a Unreal; Forward+ como primera opción, sujeto a pruebas en la computadora de destino. Windows como plataforma, Steam como destino posterior sin integración obligatoria; navegador, móvil y consolas fuera del alcance; sin multijugador ni arquitectura de red; cámara en tercera persona con SpringArm3D.
Tripo para prácticamente todos los modelos, sin Blender
Personajes, casas, objetos, equipamiento y vegetación vienen de Tripo; no depender de Blender, de retopología ni de modelado manual para completar la entrega. La primera prueba obligatoria fue un personaje completo funcionando en una build fuera del editor: un prototipo de 65 huesos (23/09) y la casa de Carro Quebrado (24/09) validaron el pipeline antes de la producción en volumen. El rig terminó saliendo del propio Tripo (Auto Rig humanoide con esqueleto Mixamo), y no de Mixamo.
29/09: el 3D pasa a ser el juego completo
El 2D pasa a ser la referencia de reglas, la migración es la prioridad y la jam entra con lo que esté en pie. Lo que el 3D ya tiene se queda. Tres puntos del documento original quedaron fuera del hito de la jam y pasaron a Pós-jam: la conversación por LLM con memoria y la siembra; el guardado ligado a las ranuras terminó saliendo ese mismo 29/09. Si alguno tiene que volver, la decisión es del autor, y el hito de la issue cambia con ella.
01/10: repositorios independientes
El 3D está en la raíz de acentauric/myths-valley-3d, en la rama main; el 2D sigue su propia línea en acentauric/myths-valley. Ningún comando de desarrollo o de prueba exige el checkout del otro; no hay sincronizador de reglas, datos ni audio. Los cuatro archivos compartidos que se bifurcaron (el hacha como ítem equipable) esperan una decisión del autor: promover la regla al 2D o declarar la bifurcación.
Dos estilos visuales, y después uno solo
Hasta la Build 10, AJUSTES → Escenario y tiempo elegía cómo se construía todo el valle: Tripo (línea maestra) o Procedural (prueba inicial), nunca mezclados, para decidir la línea maestra mirando los dos en el mismo lugar. Lo procedural no recibió arte nuevo ni se quitó en un cambio incidental: su retiro fue una tarea aparte, con controles, y ocurrió el 10/10/2026, en la Build 11. Hoy el valle es solo Tripo.
El corte de la jam: lo que entra y lo que queda para después
Entran las misiones en las anclas que existen, la mochila, el aliento en el HUD, la tabla de teclas de las pantallas nuevas, el primer lote de Tripo de ítems de mano y la traducción. No entran la Fase 2.5 (extender la región es dibujo de KML e importación), los bichos (piden rig y clips) ni los interiores (piden habitaciones, que son un sistema y no una pieza). Una pantalla nueva a cuatro días de un envío es la manera de perder un envío. La regla del corte: nada entra en la demo sin control.
Todo se traduce, y la traducción es del autor
pt-BR, inglés y español en todo texto para el jugador, no solo en el menú — una decisión tomada antes de la Fase 3 para que el primer paso de misión ya naciera con _en y _es. El costo es que el contenido se triplica; la ganancia es que el valle deja de tener un techo de público. La migración entrega la estructura y el control; el texto traducido es de Ramon.
El 2D es referencia, no dueño
El valle tiene un mecanismo propio de misiones (CadernoDoVale, una sola línea de progreso, sin checklist) por decisión del autor: una misión nueva aquí puede tener un patrón, un formato y un orden distintos. Las obras salieron con su efecto en el cuerpo antes del arte ("efecto ahora, arte después"). El almanaque es la colección (L), la red de talentos está en la K, el pueblo en la P, la mochila en la I y el panel en la J: las mismas teclas que enseña el tutorial del 2D.
8 reglas
En la práctica, en el día a día
- Registrar todo cambio de rumbo en el documento de decisiones con su impacto en el plazo; una funcionalidad nueva reemplaza un esfuerzo equivalente o queda fuera del compromiso.
- Mientras haya una tarea abierta en el hito Jam 04/10, esa tarea tiene prioridad; Pós-jam sigue las dependencias descritas en cada issue.
- Cuando una rebanada cierra una issue, la fase correspondiente se tacha en el plan en el mismo commit: un tablero y un plan que no coinciden son dos planes.
- Cada lote de Tripo se aprueba antes de ejecutarse, con el costo que muestra la interfaz informado en la conversación antes de hacer clic; las issues 'modelos-3d' gastan créditos y exigen un costo aprobado.
- No tratar el documento de decisiones como el reglamento del Tripothon: el plazo, el huso horario, el formato, la duración del video, las categorías y las reglas para proyectos anteriores se verifican en el formulario vigente antes de enviar.
- Identificar con claridad lo que ya existía en la base 2D y lo que se produjo para el prototipo; no afirmar elegibilidad sin verificar las reglas aplicables.
- La entrega es una build de Windows empaquetada en ZIP con todos los archivos necesarios, un commit o tag identificable, instrucciones de ejecución y la relación de assets y créditos.
- La licencia de redistribución de cada modelo (incluidos los prototipos de prueba y los modelos de Tripo tras una eventual cancelación del plan) se confirma antes de publicar.
Dónde aparece
- La primera prueba local (23/09/2026)
Proyecto de Godot independiente, prototipo humanoide con 65 huesos (FBX sin clips, luego GLB con clips exportados desde Tripo), controlador de 1,78 m con carrera, colisión y cámara; Forward+ iniciado en la GTX 1660 Ti with Max-Q Design. - La primera casa integrada (24/09/2026)
El flujo semiautomático Tripo Studio → GLB → Godot, validado con la casa de Carro Quebrado: 65 créditos, tarea fef21312-…, 1.915.732 → 273.548 triángulos. - El tablero (29/09/2026)
32 issues con la etiqueta 3d, divididas en Jam 04/10 y Pós-jam, con etiquetas de área: sistemas, interface, conteudo, mapa, modelos-3d y qualidade. - La separación (01/10/2026)
El proyecto se abre en la raíz, con sistemas locales y pruebas sin checkout del 2D; modelos y WAV en Git LFS; las pruebas de apertura y de controles cuentan los fallos y se falsearon a propósito para comprobar que reprueban por código de salida. - La identificación de la build
"v0.1.0-dev · Build #6" (28/09/2026), hito histórico de esta derivación; la distribución actual es la Build 12 (v0.12.0) para Windows; el 2D está en 0.2.0-dev y Build 14.
De dónde viene
Los documentos de esta área
- Decisiones del prototipo 3D — qué se decidió y cuándo
- Historial del desarrollo — las etapas antes del repositorio propio
- Del 2D al 3D — por qué los dos juegos siguen separados
- Plan del 3D — el rumbo del juego y las próximas etapas
- Composición autoral — cómo se edita el valle en Godot
- Assets con Tripo — el flujo oficial de los modelos 3D
- El valle vivo — día y noche, habitantes y sonido del valle
- Changelog del 3D — qué cambió en cada build
- Versión del juego — el número que sella cada build