How mirondorin/dq-rl works
1. Project shape
- This is a Godot 2D game client (scene/script-driven), packaged as GD_Client.exe/.pck and a demo build in demo/.
- The repo is mostly content + gameplay code, not a general application backend. There is no visible server/service layer in the tree.
2. Runtime entry and session flow
- The main user flow appears to start in scenes/Menu.tscn, move through scenes/lobby.tscn, then into scenes/MainScene.tscn where actual gameplay runs.
- Supporting launch assets like keybinds.ini and open_2_clients.bat suggest the build supports configurable input and possibly multi-instance testing.
3. World composition
- The game world is assembled from level scenes (scenes/levels/level0.tscn through level6.tscn) plus reusable environment scenes like parallax backgrounds and world boundaries.
- MainScene.tscn is the likely orchestration layer that places level geometry, spawn points, doors, HUD, and combat entities into one playable session.
4. Progression and room transitions
- Door and transition logic is split into dedicated scene/script pairs:
- BossDoor.tscn / scripts/BossDoor.gd
- NewLevelDoor.tscn / scripts/NewLevelDoor.gd
- DoorBase.gd
- These act as progression boundaries between rooms/levels and likely gate movement based on combat or level state.
5. Player subsystem
- The player is isolated as PlayableCharacter.tscn with logic in scripts/PlayableCharacter.gd.
- Input and action handling are likely driven by key bindings plus the HUD/UI layer, with the character interacting with weapons, pickups, and level transitions rather than owning the entire game flow.
6. Combat architecture
- Combat uses a clear inheritance hierarchy:
- Entity.gd and PhysicsEntity.gd for shared actor behavior
- scripts/Weapons/Weapon_base.gd and scripts/mobs/Mob_base.gd for weapon/enemy common logic
- Concrete weapon scenes/scripts include Hammer, WeaponProjectile, WeaponBomb, and HomingProjectile variants, each with separate projectile/bullet scenes.
7. Enemy and boss layer
- Regular enemies and bosses are separated into reusable mob scenes under scenes/Mobs/ with matching scripts under scripts/mobs/.
- Bosses include BoDBoss and GolemBoss; smaller enemy/projectile behaviors are split into MobProjectile and MobHomingProjectile.
- This suggests a pattern where enemy AI, attack patterns, and death behavior are encapsulated per mob type, while shared movement/health logic lives in the base mob script.
8. Spawner-driven encounter setup
- DynamicSpawner.tscn, EnemySpawner.tscn, and their scripts indicate that enemy placement is runtime-driven, not fully hardcoded into levels.
- This is a key architectural boundary: level scenes define the environment, while spawners inject encounters and scale difficulty during play.
9. Pickups and progression rewards
- Item rewards are handled by dedicated pickup scenes/scripts:
- HealthPickup
- MaxHealthPickup
- DamageBoost
- ItemPickup.gd
- These are separate from combat entities, which keeps reward logic distinct from enemy/player logic and makes level drops easy to reuse.
10. UI/HUD layer
- HUD.tscn and scripts/HUD.gd form the player-facing state display and likely health/cooldown feedback.
- Cooldown.tscn and KeyButton.gd suggest modular UI elements for action timers and control hints/remapping.
11. Data, art, audio, and rendering support
- The game is heavily data-driven through Godot resources: tilesets (tilesets/Terrain.tres), materials (materials/white.tres), shaders, fonts, and many imported sounds.
- Large asset packs under assets/ provide tiles, character animations, cave backgrounds, HUD art, and sprite effects; these are referenced by scenes rather than embedded in code.
12. Editor-time extension
- addons/tool_button/ is an editor plugin, so the project includes custom Godot editor tooling.
- That tooling is separate from runtime gameplay and likely exists to speed up scene/content authoring.
13. Content organization
- The repository uses a strong scene/script pairing convention: gameplay objects are authored as .tscn scenes with matching .gd scripts in parallel folders.
- This makes the architecture easy to diagram as reusable runtime modules connected through scene instancing and shared base classes.
14. Likely high-level diagram boundaries
- A useful architecture diagram would show:
- Menu/Lobby flow → Main gameplay scene
- Main scene orchestrating levels, spawners, doors, HUD
- Player and mobs/bosses interacting through weapons/projectiles/pickups
- Assets/resources feeding all runtime scenes
- Editor addon/tooling as a separate non-runtime boundary
Main entry points: MainScene.tscn Main Scene · PlayableCharacter.tscn Player · Terrain.tres Assets & Resources · WeaponProjectile.tscn Projectiles
Components 20
Runtime flow
Menu to lobby to main gameplay and supporting session systems.
- Menu · Entry screen and initial navigation.
scenes/Menu.tscn - Lobby · Interim setup and session staging.
scenes/lobby.tscn - Main Scene · Orchestrates a playable run and assembles the session.
scenes/MainScene.tscn - Game State · Global session state shared across scenes.
scripts/Gamestate.gd - Settings · Global configuration and input-related settings.
scripts/GlobalSettings.gd
Combat entities
Player, enemies, weapons, projectiles, and pickups.
- Player · Controllable character and input-driven actions.
scenes/PlayableCharacter.tscn - Entity Base · Shared actor behavior for movable living entities.
scripts/Entity.gd - Physics Base · Physics-enabled common behavior for actors.
scripts/PhysicsEntity.gd - Mob Base · Shared enemy logic for health, movement, and death.
scripts/mobs/Mob_base.gd - Bosses · Major encounters with dedicated behaviors and patterns.
scenes/Mobs/BoDBoss.tscn - Projectiles · Weapon and enemy projectile variants.
scenes/Weapons/WeaponProjectile.tscn - Weapons · Player weapon implementations and attack variants.
scenes/Weapons/Weapon.tscn - Pickups · Health and stat rewards collected during play.
scenes/items/HealthPickup.tscn
World content
Levels, doors, HUD, and reusable environment scenes.
- Levels · Reusable level maps and room layouts.
scenes/levels/level0.tscn - Doors · Progression gates between rooms and levels.
scenes/NewLevelDoor.tscn - Spawners · Runtime enemy injection and encounter pacing.
scenes/EnemySpawner.tscn - HUD · Player-facing state display and cooldown feedback.
scenes/HUD.tscn - Environment · Backgrounds, boundaries, and other reusable world pieces.
scenes/other/ParallaxBackground.tscn
Tooling and assets
Editor extension and shared resources that support the runtime.
- Editor Addon · Godot editor tooling for faster content authoring.
addons/tool_button/TB_Plugin.gd - Assets & Resources · Tiles, fonts, shaders, sounds, and imported art assets.
tilesets/Terrain.tres
Connections 23
- Menu → Lobby: start · Menu leads into lobby/setup.
- Lobby → Main Scene: enter run · Lobby transitions into gameplay.
- Main Scene → Levels: instance · Main scene composes the active level layout.
- Main Scene → Doors: place gates · Main scene wires progression boundaries.
- Main Scene → Spawners: spawn encounters · Main scene activates runtime enemy spawning.
- Main Scene → HUD: attach UI · Main scene mounts the player HUD.
- Main Scene → Player: spawn player · Main scene instantiates the controllable character.
- Main Scene → Environment: use scenery · Main scene includes background and boundary scenes.
- Player → Entity Base: inherits · Player builds on shared entity behavior.
- Entity Base → Physics Base: extends · Entity logic sits on physics-enabled base behavior.
- Bosses → Mob Base: inherits · Bosses reuse shared enemy base logic.
- Projectiles → Weapons: used by · Projectile scenes support weapon attacks.
- Weapons → Projectiles: emit · Weapons create projectiles or bullets.
- Mob Base → Projectiles: attack with · Enemy behaviors can drive projectile patterns.
- Pickups → Player: affect · Pickups modify player health or stats.
- Doors → Game State: check state · Doors likely gate progression using shared game state.
- Spawners → Game State: read progress · Spawner logic can scale encounters from shared state.
- HUD → Game State: display state · HUD reflects run state and player status.
- Settings → Player: bind input · Global settings support player controls.
- Assets & Resources → Levels: feed content · Resources provide tiles, art, audio, and materials for scenes.
- Assets & Resources → Weapons: feed visuals · Weapon scenes rely on shared art and sound resources.
- Assets & Resources → HUD: feed ui · HUD uses shared fonts, icons, and materials.
- Editor Addon → Main Scene: editor aid · Editor plugin supports authoring and inspection.