Estructuración del proyecto final integrado

Estructuración del proyecto final integrado

Bienvenidos al inicio del Módulo 11. A lo largo de los diez módulos previos has construido, pieza por pieza, los engranajes esenciales de un videojuego de plataformas 2D: la física de movimiento horizontal y vertical, la respuesta de colisiones por píxel o mediante tilemaps, la inteligencia artificial de patrulla de los enemigos, los sistemas de recolección y vida, el HUD dibujado en la capa gráfica, la emisión de audio, las partículas y la transición entre niveles. Sin embargo, al desarrollar proyectos progresivos es natural que los recursos, nombres de variables y scripts queden dispersos, redundantes o ligeramente desalineados entre módulos.

En la industria profesional del desarrollo de videojuegos, antes de iniciar la fase de ensamblaje general (donde se unen los niveles definitivos, la narrativa, los menús de inicio y las condiciones de victoria y derrota), se realiza una etapa obligatoria de consolidación técnica o «refactorización y estructuración». Esta sesión tiene como meta revisar minuciosamente el árbol de recursos (Asset Browser), unificar las nomenclaturas, alinear los orígenes de sprites y máscaras de colisión, y crear una arquitectura de scripts y objetos administradores que garantice que el videojuego funcione de manera predecible, escalable y libre de errores de memoria.

1. Auditoría del Asset Browser y convención de nomenclaturas

GameMaker permite organizar el Asset Browser mediante carpetas y etiquetas de color personalizadas. Un error habitual entre principiantes es dejar decenas de sprites, objetos y sonidos flotando en la raíz del explorador o dentro de carpetas predeterminadas genéricas. Cuando el proyecto supera los cincuenta recursos, encontrar el archivo correcto ralentiza el flujo de trabajo y facilita que se invoquen recursos duplicados u obsoletos.

La primera regla de la ingeniería limpia en GameMaker consiste en aplicar un sistema estricto de prefijos normalizados. Un prefijo identifica inequívocamente la naturaleza del recurso en el código GML, evitando colisiones de identificadores (por ejemplo, tener un sprite y un objeto llamados exactamente igual, lo cual corrompe la compilación).

Más allá de los prefijos, es fundamental estructurar las carpetas por dominios funcionales en lugar de agrupar todo en una sola carpeta masiva de «Objetos» o «Sprites». La siguiente jerarquía modular es el estándar recomendado para nuestro juego de plataformas:

── [00_Core]
    ├── Scripts (scr_game_init, scr_utilities, scr_player_actions)
    ├── Fonts (fnt_hud, fnt_menu_title, fnt_menu_buttons)
    └── Managers (obj_game_manager, obj_camera, obj_audio_manager)
── [01_Characters]
    ├── Player
    │   ├── Sprites (spr_player_idle, spr_player_run, spr_player_jump, etc.)
    │   └── Objects (obj_player)
    └── Enemies
        ├── Sprites (spr_slime_walk, spr_slime_turn, spr_slime_dead)
        └── Objects (obj_enemy_parent, obj_slime_patrol)
── [02_World_Environment]
    ├── Collisions (spr_solid_wall, obj_solid_wall, obj_platform_semisolid)
    ├── Hazards (spr_spikes, obj_spikes, obj_hazard_water)
    ├── Interactables (spr_checkpoint, obj_checkpoint, spr_door, obj_door)
    ├── Collectibles (spr_coin, obj_coin, spr_gem, obj_gem)
    └── TileSets & Backgrounds (ts_dungeon, bg_sky, bg_mountains)
── [03_Interface]
    ├── HUD (spr_hud_heart, spr_hud_coin_icon, obj_hud)
    └── Menus (spr_button_frame, obj_main_menu, obj_pause_screen)
── [04_Audio]
    ├── SFX (snd_player_jump, snd_player_hurt, snd_coin_pickup)
    └── Music (snd_music_level_01, snd_music_title_screen)
── [05_Particles]
    └── ps_dust_particles, ps_hit_sparkles
── [06_Rooms]
    ├── Screens (rm_menu_main, rm_victory, rm_gameover)
    └── Levels (rm_level_01, rm_level_02)

2. Estandarización de orígenes de sprites y máscaras de colisión

Uno de los problemas más comunes al integrar recursos creados en momentos distintos es la inconsistencia en los puntos de origen (`xorigin`, `yorigin`) y en las dimensiones de las cajas de colisión (`bbox`). En un juego de plataformas, una ligera discrepancia de un píxel en el origen puede provocar que el personaje quede enterrado en el suelo al cambiar de animación de `spr_player_idle` a `spr_player_run`.

Para evitar estos comportamientos anómalos, adoptaremos las siguientes directrices obligatorias antes de programar la lógica integrada:

💡 Regla de oro para el Player: Asigna una máscara de colisión única e invariable mediante la propiedad «Collision Mask» en el editor del objeto `obj_player`. Utiliza un sprite específico como `spr_player_mask` o mantén la máscara fijada permanentemente a `spr_player_idle`. Si dejas la máscara en «Same as sprite», cada frame de una animación compleja cambiará las dimensiones de colisión, produciendo atascos en techos y paredes.

3. Normalización de capas (Layers) en las salas

Cuando el motor ejecuta una sala (Room), el orden de dibujo y la evaluación de profundidad dependen estrictamente de las capas creadas. Si en `rm_level_01` la capa de colisiones se llama «Collisions» y en `rm_level_02` se llama «Capas_Colision», cualquier script que busque colisiones dinámicas por nombre de capa fallará de forma catastrófica.

Alinearemos todas las salas del proyecto a una estructura universal de capas, ordenadas de mayor a menor profundidad (de abajo hacia arriba en el editor de capas):

[Profundidad Menor - Frente visual]
- GUI_Layer               (Capa no visible en Room editor, gobernada por evento Draw GUI)
- Instances_UI            (Capa de instancias para menús interactivos en salas estáticas)
- Instances_Effects       (Partículas, chispas, explosiones, polvo de salto)
- Instances_Entities      (Jugador, enemigos, proyectiles, coleccionables interactivos)
- Instances_Environment   (Puertas, palancas, cofres, plataformas móviles)
- Collisions              (Instancias invisibles de obj_solid_wall o tilemaps de colisión sólida)
- Tiles_Foreground        (Detalles visuales que tapan al jugador, ej: hojas de árboles, barandillas)
- Tiles_Main              (Suelo y paredes visibles del nivel)
- Background_Front        (Capas de paralaje cercano)
- Background_Back         (Capa de fondo infinito o cielo lejano)
[Profundidad Mayor - Fondo absoluto]

4. Centralización de constantes, estados y enums globales

Hasta este momento del curso, muchas variables globales o valores fijos (como la aceleración gravitacional o los estados del jugador) se inicializaban en el evento Create del jugador o directamente como números «mágicos» dispersos en el código. Esto dificulta el calibrado del juego. Si deseas cambiar la gravedad o comprobar en qué estado global se encuentra la partida, debes buscar en múltiples eventos.

En GameMaker moderno, la práctica profesional estándar es definir los enums, macros y funciones de inicialización dentro de un script de GML que se ejecuta automáticamente antes de que cargue la primera sala del juego. Crearemos un script llamado `scr_game_init`.

/// @file scr_game_init.gml
/// @description Define los enumeradores y macros fundamentales para todo el videojuego.

// 1. MACROS GLOBALES (Valores inmutables de configuración)
#macro GRAVITY_FORCE        0.45
#macro TERMINAL_VELOCITY    9.0
#macro TILE_SIZE            16
#macro GAME_VERSION         "1.0.0"
#macro DEV_MODE             false

// 2. ENUMERADORES DE ESTADO (Máquinas de estado finitas)
// Estados del jugador
enum PLAYER_STATE {
    IDLE,
    RUNNING,
    JUMPING,
    FALLING,
    HURT,
    DEAD
}

// Estados del bucle principal del juego
enum GAME_STATE {
    BOOT,
    MAIN_MENU,
    PLAYING,
    PAUSED,
    LEVEL_TRANSITION,
    GAME_OVER,
    VICTORY
}

// Estados de comportamiento para enemigos terrestres
enum ENEMY_STATE {
    PATROL,
    ALERT,
    ATTACK,
    HURT,
    DEAD
}

// Tipos de coleccionables
enum COLLECTIBLE_TYPE {
    COIN,
    GEM,
    EXTRA_LIFE,
    HEALTH_HEART
}

Al declarar estos elementos en el ámbito de un script fuera de cualquier función envolvente, GameMaker los compila en el inicio del programa. De este modo, en cualquier objeto o evento puedes escribir `if (state == PLAYER_STATE.RUNNING)` sin peligro de que la palabra clave no esté inicializada.