Estructura - GameObjects en escenas
La siguiente estructura define un estándar común para todas las escenas del proyecto, con el objetivo de:
- Separar claramente sistemas, UX, UI, gameplay y contenido visual.
- Facilitar mantenimiento, escalabilidad y QA.
- Reducir dependencias cruzadas y deuda técnica.
- Permitir que cualquier miembro del equipo entienda una escena en minutos.
Cada escena debe organizarse siguiendo esta estructura:.
_SYSTEMS
_PLAYER
_UX
_MachineManager
_Interaction
_Guidance
_Feedback
_LocomotionUX
_UI
_GAMEPLAY
ENVIRONMENT
_AUDIO
_VFX
_DEBUG
Reglas:
- Todo lo que decide, calcula o coordina → va en _SYSTEMS, _GAMEPLAY o _UX.
- Todo lo que se ve → va en ENVIRONMENT, _UI o _VFX.
- Si por alguna razón, dentro de la escena existen categorías vacías, tienen que eliminarse.
_AUDIO: Centraliza el audio exclusivo de la escena.
Incluye (por ejemplo)
- Voice overs
- SFX locales
- Música ambiental específica
¿Por qué existe?
- Evita mezclar audio global con audio contextual
- Facilita mutear, reemplazar o testear audio por escena
_GAMEPLAY: Lógica jugable específica de la escena.
Incluye (por ejemplo)
- Reglas particulares
- Estados temporales
- Triggers propios de la escena
¿Por qué existe?
- No toda la lógica pertenece a sistemas globales
- Aísla comportamiento local sin contaminar otros flujos
_SYSTEMS: Sistemas técnicos transversales utilizados por la escena.
Incluye (por ejemplo)
- Máquinas de estado
- Managers locales
- Servicios técnicos
¿Por qué existe?
- Diferencia sistemas del resto de contenido
- Facilita reutilización y pruebas aisladas
_PLAYER: Configuración y comportamiento del jugador dentro de la escena.
Incluye (por ejemplo)
- Módulos/Componentes relacionados al Player o cámara
- Setup de locomotion
¿Por qué existe?
- El jugador puede comportarse distinto según la escena
- Evita lógica condicional dispersa
_UX: Gestión de la experiencia del usuario en la escena.
Incluye
- Flujos
- Guías
- Feedback
- Enseñanza de interacciones
¿Por qué existe?
- UX no es solo UI
- La experiencia es un sistema en sí misma
- Mejorar la comunicación con el área de Diseño por medio de la nomenclatura y estructura de los elementos que construyen la UX dentro de la escena.
_MachineManager: Controla el flujo secuencial.
- Qué paso sigue
- Cuándo avanza
- Condiciones de éxito o error
_Interaction: Define qué interacciones están permitidas y cómo se enseñan.
- Agarrar
- Presionar
- Señalar
- Activar objetos
_Guidance: Guía activamente al usuario.
- Flechas
- Highlights
- Señales visuales
_Feedback: Comunica al usuario qué pasó y si lo hizo bien o mal.
- Visual
- Auditivo
- Háptico
_LocomotionUX: Gestiona la enseñanza y adaptación de locomotion.
- Teleport
- Smooth locomotion
- Rotaciones
_UI: Interfaz gráfica tradicional de la escena.
Incluye (por ejemplo)
- Canvas
- Botones
- Textos
- HUDs
¿Por qué existe?
- Separación clara entre experiencia (UX) y representación visual (UI)
- Permite iterar UI sin afectar lógica
_VFX: Efectos visuales de apoyo de la escena.
Incluye (por ejemplo)
- Partículas
- Transiciones
- Efectos de refuerzo visual
¿Por qué existe?
- Mejora legibilidad y feedback sin añadir lógica
ENVIRONMENT: Contenido visual y espacial de la escena.
Incluye (por ejemplo)
- Geometría
- Props
- Iluminación
- Decoración
¿Por qué no usa “_” como prefijo?
- No es sistema ni lógica
- Es contenido visual puro
_DEBUG: Herramientas exclusivas para desarrollo y QA.
Incluye (por ejemplo)
- Gizmos
- Controles de skip
- Visualización de estados
- Componentes para testing
NOTA: Esta sección junto con todo su contenido debe borrarse de la escena al finalizar el proyecto.
En relación a lo anterior, sigue la nomenclatura definida por el área: