Saltar al contenido
Cargando página…
Myths' Valley

Dirección · 6 de 7

Regla separada de la presentación, nombre en lugar de coordenada, y nada entra sin control.

El juego 3D es un único proyecto de Godot 4.7.2 Standard, en GDScript y con el renderizador Forward+, que se abre en la raíz de su repositorio y funciona sin otro checkout. Los modelos GLB y el audio WAV usan Git LFS; los parámetros .import y .gd.uid versionados preservan la identidad de los recursos. Las reglas de juego que vinieron del 2D viven en scripts/compartilhado/ (inventario, aliento, vida, talentos, fe, cartas, colección, recetas, obras, venta, afinidad, guardado), sin citar un solo tipo 2D; los servicios del valle, en scripts/autoload/; las pantallas, en scripts/ui/.

La migración del 2D al 3D, medida archivo por archivo el 29/09/2026, mostró que casi todo se aprovecha, porque el 2D siempre guardó la regla en autoload y el dibujo en escena: de los 30 autoloads de lógica, 25 no citaban un tipo 2D. Lo que ata una regla al 2D casi nunca es el tipo, es la entrada (qué tecla la activa) — y eso se puede separar. La regla que manda sobre todo: el 3D no se reescribe. Migrar quiere decir agregar, nunca rehacer lo que ya está en pie.

10 principios

Lo que no se negocia

Un proyecto, un motor, LFS para lo que pesa

Godot 4.7.2 Standard, GDScript y Forward+ (con modo Compatibility para las GPU que no soporten el perfil); el project.godot de la raíz registra los 40 autoloads y abre inicio.tscn. No se cambia de motor ni se actualiza el motor en medio de la jam sin una necesidad comprobada. GLB, FBX históricos y WAV en Git LFS; cachés, builds, archivos en bruto y credenciales quedan fuera de Git; el juego no necesita claves para correr.

Regla separada de la presentación

Lo que hace la acción cruza; qué tecla la activa y qué pantallas bloquean la tecla quedan en el proyecto de cada juego. Así fue como la tecla de la mano salió de Inventario y pasó al controlador de entrada, y como las pantallas del 2D (CanvasLayer y Control) dibujan encima del 3D sin saber que es 3D. El texto para el jugador nace como dato (JSON), nunca como constante de GDScript, porque una constante no se traduce.

El 3D no se reescribe

Un asset 3D nunca se cambia por arte 2D (un sprite no reemplaza a un GLB; el arte del 2D solo entra en la interfaz, como ícono). Una mecánica que ya funciona en el 3D sigue siendo dueña de su ámbito: el reloj es Dia, quien narra es GuiaPedro, el HUD es prototype_hud, el mapa es mapa_jogo. Solo nace desde cero lo que el 3D no tiene. Si la rebanada borra, rehace o jubila lo que ya funciona, está mal y hay que recortarla de otra manera.

El nombre es el contrato; el ancla es la implementación

El autoload Lugares traduce un nombre de lugar en una posición — Vector2 en el 2D, Vector3 en el 3D — y quien lo llama no ve la diferencia. Un nombre que el valle todavía no tiene devuelve NENHUM y nada se rompe: la misión se abre sin brújula, el sistema funciona con el lugar ausente, y el día en que la región crezca el nombre empieza a resolverse sin tocar ninguna misión. Una anotación de tipo es un acoplamiento tan real como una llamada a función, y no aparece en una búsqueda por nombre.

Nada entra sin control

Cada rebanada agrega o ajusta una prueba de comportamiento en tests/ y demuestra que detecta el defecto (falsación). El runner tools/prototipo_3d/testar.ps1 ejecuta la batería con un perfil aislado por control, un tiempo límite y una verificación de errores de compilación: los errores de compilación y los bloqueos reprueban, y un código de salida cero por sí solo no demuestra que el juego abrió. Solo pueden cerrarse los PID que levantó el runner. El 02/10/2026 la batería tenía 51 controles aprobados.

Deuda declarada, no deuda olvidada

Lo que falta figura en listas con la razón escrita: FALTAM_NO_VALE en Lugares (la laguna), FALTAM_TRADUCAO en el control de idiomas, la cola del tejado en el 2D y las piezas Tripo todavía sin exportar en el catálogo. El control lee esas listas para exigir que no haya nombres mal escritos, y el sistema sigue funcionando con la pieza ausente: la misma elección del catálogo de assets.

Rendimiento medido en la computadora de referencia, no estimado

La GeForce GTX 1660 Ti (Max-Q) es la referencia. Mediciones que cambiaron decisiones: texturas sin compresión a 2,49 GB de VRAM → 0,74 GB con VRAM Compressed; el bosque en una MultiMesh por especie que nunca salía del cuadro → bloques de 40 unidades con LOD por distancia (17,33 M → 5,65 M de triángulos en la vista lejana); el armado del valle de ~29 s a ~5 s al cambiar la medición de cada punto contra todos los segmentos por cuadrículas de celdas, con un resultado idéntico bit a bit.

Datos en res://, guardado en user://, una sola fuente para la versión

Los datos se leen de res://data/ y el guardado usa user:// en su propio directorio MythsValleyPrototype3D, separado del 2D. Su formato es el Variant de Godot (que guarda Vector3 con naturalidad), con escritura atómica y migración escalonada; un campo público nuevo entra en O_QUE_GUARDAR o en FORA_DO_SAVE con el motivo escrito, y el control verifica ambas listas. La versión y la build se declaran una sola vez, en data/historico_3d.json, y tanto el pie del menú como el sello del guardado leen de ahí.

Secretos fuera del repositorio; generación solo a pedido

Las credenciales quedan en archivos locales que lee tools/comum/chaves.ps1 y en el perfil local de Tripo; ninguna clave entra en el repositorio, en el ejecutable ni en la build. Generar arte y audio consume créditos y solo ocurre con una solicitud explícita, y cada asset conserva su procedencia y sus créditos. Para la conversación por LLM prevista, la clave del proveedor queda como secreto en un servicio, nunca en el cliente, y un secreto escondido en el juego no es autenticación.

Tres reservas y una interacción enfocada

El vigor sostiene el esfuerzo, la carrera y el salto; el aliento sostiene el nado; la vida recibe el daño. E actúa sobre un objetivo por vez, delante del cuerpo; las conversaciones y avisos pausan el reloj. La Build 9 redujo la carga, la sombra, el bosque y el trabajo de física, y el minimapa pasó a usar una foto estática.

9 reglas

En la práctica, en el día a día

  • Antes de implementar, leer la issue y el control del tema y revisar el código actual: issues antiguas pueden describir como ausente algo que ya se incorporó.
  • Cada rebanada: implementar, agregar o ajustar la verificación de comportamiento, demostrar que detecta el defecto, ejecutar la batería con perfil aislado, registrarla en CHANGELOG_3D y citar la issue en el cuerpo del commit. El trabajo nuevo va en feature/<nome>, con PR a main.
  • Batería: .\tools\prototipo_3d\testar.ps1 (o -Teste salvamento). La batería se ejecuta headless; las capturas y las pruebas que dependen del mouse (smoke_opening, mapa_fluxo, smoke_test) usan el renderizador normal.
  • git lfs pull antes de la primera importación: la verificación previa reprueba los modelos o WAV que todavía sean punteros LFS.
  • Exportación a Windows con export_presets.cfg hacia build/windows/ (crear la carpeta antes), con las plantillas de la misma versión de Godot.
  • Teclas en código, no en el Input Map: teclas_movimento.gd (WASD, flechas o ambos) y atalhos.gd (letras reasignables con intercambio; W, A, S y D reservadas), guardadas en user://controles.cfg.
  • Una regla compartida es una copia que un control verifica byte a byte; la lista de archivos bifurcados (catalogo, inventario, equipamento, mochila, al 01/10/2026) espera la decisión del autor antes de cualquier sincronización.
  • Las posiciones y las decisiones visuales no quedan como Vector3 dentro de world_builder: el generador lee la composición guardada.
  • Depuración: JOGAR_3D.cmd -Lugar igreja empieza en un lugar del valle; -Compatibility cambia el renderizador; -Godot CAMINHO.exe apunta a otro ejecutable.

Dónde aparece

  • El tamaño del código
    Los scripts del juego, las pruebas y las herramientas están en sus propias carpetas. Los recuentos de archivos y líneas, autoloads, escenas, shaders y datos JSON se miden en la instantánea de Git registrada en las estadísticas; la página del proyecto muestra las cifras actuales de código, pruebas y datos.
  • El Salvamento que cruzó sin adaptación
    Parecía el más enredado y cruzó sin cambiar una sola línea, porque usa get_node_or_null en todas partes y se degrada por sí solo donde un sistema no existe; únicamente Versao tuvo que nacer en local, leyendo de historico_3d.json.
  • CadernoDoVale y CadeiaDeMissoes
    El mecanismo propio de misiones del valle: una entrada de progreso por misión y cadenas vinculadas a los vecinos, que leen sus archivos de datos. Las metas incluyen materiales, entregas, conversaciones, eventos, recuentos, obras, visitas y ofrendas; los controles de prueba verifican la cadena y los recursos necesarios para completarla.
  • El control del minimapa
    El objetivo de la misión apuntaba a quien acababa de hablar, no a lo que el jugador había fijado en el panel — y duró porque el minimapa nunca había tenido un control. Ahora lo tiene, con siete preguntas.
  • El sobrevuelo del menú
    Planificado offline contra los triángulos reales del valle, grabado en data/sobrevoo_menu.json y verificado cuadro por cuadro por tests/sobrevoo_livre.gd; si las anclas o la escala cambian, el menú avisa y vuelve a la elipse antigua.

De dónde viene

Los documentos de esta área

Las orientaciones de arriba resumen estos documentos de dirección del juego.
  • Arquitectura — escenas, autoloads y catálogos del juego
  • Visión del juego — qué es el juego y qué reúne
  • Validación — cómo se verifica el proyecto después de importarlo
  • Plan del 3D — el rumbo del juego y las próximas etapas
  • Presentación del juego — el resumen de Myths' Valley 3D
  • Historial del desarrollo — las etapas antes del repositorio propio
  • Decisiones del prototipo 3D — qué se decidió y cuándo
  • El valle vivo — día y noche, habitantes y sonido del valle
  • Changelog del 3D — qué cambió en cada build
  • Lugares — el nombre de cada lugar y dónde está
  • Versión del juego — el número que sella cada build
  • Atajos de teclado — las teclas que el jugador puede cambiar