Structuring the Final Integrated Project

Structuring the Final Integrated Project

Welcome to the start of Module 11. Across the previous ten modules, you have built the core mechanics of a 2D platformer piece by piece: horizontal and vertical movement physics, pixel-perfect or tilemap-based collision handling, enemy patrol AI, collectible and health systems, GUI-layer HUD rendering, audio playback, particle effects, and room transitions. However, when developing a project progressively across multiple milestones, assets, variable names, and scripts naturally end up scattered, redundant, or slightly misaligned.

In professional game development, before starting final assembly—where polished levels, narrative sequences, menus, and win/loss conditions come together—teams undergo a mandatory consolidation phase known as technical refactoring and structuring. The goal of this session is to thoroughly audit the Asset Browser, unify naming conventions, align sprite origins and collision masks, and build a clean architecture of scripts and manager objects that ensures your game runs predictably, scales easily, and remains free of memory leaks.

1. Asset Browser Audit and Naming Conventions

GameMaker allows you to organize the Asset Browser using custom folders and color tags. A common mistake among beginners is leaving dozens of sprites, objects, and audio files floating in the root directory or inside generic default folders. Once a project exceeds fifty assets, hunting for the right file slows down your workflow and increases the risk of referencing duplicate or obsolete assets.

The first rule of clean project engineering in GameMaker is enforcing a strict prefix convention. A prefix clearly identifies the asset type in GML code, preventing identifier collisions—such as having a sprite and an object share the exact same name, which breaks compilation.

Beyond prefixes, grouping assets by functional domain is far more effective than throwing everything into massive, monolithic 'Objects' or 'Sprites' folders. The following modular hierarchy is the recommended standard for our platformer:

── [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. Standardizing Sprite Origins and Collision Masks

One of the most persistent bugs when combining assets made across different sessions is origin point (`xorigin`, `yorigin`) and bounding box (`bbox`) mismatches. In a platformer, an origin offset of just a single pixel can cause the player character to sink into the floor or get stuck when switching from `spr_player_idle` to `spr_player_run`.

To prevent these issues, adhere strictly to the following origin and collision standards across all game assets:

💡 Golden Rule for the Player: Assign a single, immutable collision mask using the 'Collision Mask' property in the `obj_player` object inspector. Pick a dedicated invisible sprite like `spr_player_mask`, or lock the mask permanently to `spr_player_idle`. If you leave it set to 'Same as sprite', every frame of an action animation can alter the bounding box dimensions, causing the character to snag on ceilings and walls.

3. Room Layer Normalization

When the engine loads a room, draw order and depth sorting depend directly on defined layers. If your collision layer is named 'Collisions' in `rm_level_01` but named 'Solid_Collisions' in `rm_level_02`, any script looking up tilemap collisions by layer name will fail silently or crash the game.

Standardize all rooms in your project to use a single, universal layer hierarchy, ordered from foreground to background (top to bottom in the Room Layer Editor):

[Lowest Depth - Visual Foreground]
- GUI_Layer               (Virtual layer governed by the Draw GUI event; not drawn in Room editor)
- Instances_UI            (Instance layer for interactive menus in static screens)
- Instances_Effects       (Particles, hit sparks, explosions, jump dust)
- Instances_Entities      (Player, enemies, projectiles, interactive collectibles)
- Instances_Environment   (Doors, levers, chests, moving platforms)
- Collisions              (Invisible obj_solid_wall instances or solid collision tilemaps)
- Tiles_Foreground        (Visual decorative tiles drawn in front of entities, e.g., foliage)
- Tiles_Main              (Primary walkable ground and walls)
- Background_Front        (Near-field parallax scrolling layers)
- Background_Back         (Distant sky or infinite backdrop layer)
[Highest Depth - Furthest Background]

4. Centralizing Global Constants, States, and Enums

Earlier in your learning, you may have initialized global variables or physical constants (such as gravity or state flags) inside the player's Create event, or hardcoded 'magic numbers' directly into step events. This makes fine-tuning gameplay frustrating: tweaking jump arc or checking game state requires hunting through multiple objects and events.

In modern GameMaker, professional practice defines global enums, macros, and initialization routines inside a GML script file that executes automatically before the first room loads. We will implement this setup in a script named `scr_game_init`.

/// @file scr_game_init.gml
/// @description Defines fundamental enums and macros for the entire game.

// 1. GLOBAL MACROS (Immutable configuration values)
#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. STATE ENUMS (Finite State Machines)
// Player movement and life states
enum PLAYER_STATE {
    IDLE,
    RUNNING,
    JUMPING,
    FALLING,
    HURT,
    DEAD
}

// Core game loop states
enum GAME_STATE {
    BOOT,
    MAIN_MENU,
    PLAYING,
    PAUSED,
    LEVEL_TRANSITION,
    GAME_OVER,
    VICTORY
}

// Ground enemy behavior states
enum ENEMY_STATE {
    PATROL,
    ALERT,
    ATTACK,
    HURT,
    DEAD
}

// Collectible item categories
enum COLLECTIBLE_TYPE {
    COIN,
    GEM,
    EXTRA_LIFE,
    HEALTH_HEART
}

By placing these definitions at the root scope of a script outside of any function declaration, GameMaker compiles them at startup. As a result, you can reference `if (state == PLAYER_STATE.RUNNING)` anywhere in your codebase without worrying whether the identifier has been initialized.