Files
zfxaction26_1/CODE.md
2026-04-21 18:21:39 +02:00

625 lines
21 KiB
Markdown

# Side-Scrolling Shooter Implementation Plan
This document describes the implementation order for the game jam vertical slice and the supporting tools needed to test each feature quickly while building. `DESIGN.md` remains the system design source. This file is the coding plan for turning that design into a playable Godot 4 .NET game with fast iteration loops.
The guiding rule is: every feature should be reachable in seconds from a test scene, debug shortcut, or timeline jump. A one-month jam cannot afford long manual setup before testing a weapon, cluster, boss phase, pickup, difficulty setting, or mission transition.
## Working Principles
- Build one thin playable path first, then widen systems.
- Keep gameplay rules in plain C# classes where possible.
- Keep Godot node scripts focused on scene wiring, input, visuals, audio, and signals.
- Make definitions data-driven before adding many content variants.
- Add debug controls with the feature, not later.
- Make every new system testable in isolation and inside the real mission loop.
- Prefer deterministic test data and seeded randomness.
- Commit after each small, working slice.
## Target Vertical Slice
The first complete slice should contain:
- A bootable Godot .NET project.
- A menu with start, controls, and difficulty selection.
- A shop where the player chooses one special weapon.
- One mission with intro, gameplay, boss intro, boss fight, boss destruction, outro, and highscore/end state.
- One fixed camera path with speed changes.
- One repeating background layer and one repeating foreground layer.
- One interactive layer with enemy spawns and boss content.
- One hero with movement, shield charges, retries, points, level, primary weapon slots, secondary weapon, special weapon ammo, and squadron mates.
- One primary weapon, one secondary weapon, and one special weapon.
- Two normal enemy types: one serial behavior and one parallel movement/firing behavior.
- One enemy cluster with completion reward.
- One point collectible and one squadron mate collectible.
- One boss placeholder with phases and destruction sequence.
- Debug tools that can jump directly to the mission, cluster, weapon range, boss, and end states.
## Folder Layout
Use this layout unless the project already establishes a better local convention:
- `scenes/bootstrap/` for startup and root scene.
- `scenes/menu/` for menu, controls, difficulty selection, and highscore screens.
- `scenes/shop/` for pre-mission special weapon selection.
- `scenes/mission/` for the mission runner and test mission scene.
- `scenes/level/` for parallax, camera path, and interactive layer scenes.
- `scenes/hero/` for hero and squadron mate scenes.
- `scenes/enemies/` for enemy and boss scenes.
- `scenes/weapons/` for projectile, beam, explosion, and special weapon scenes.
- `scenes/collectibles/` for pickup scenes.
- `scenes/debug/` for test harness scenes and debug UI.
- `scripts/game/` for run state, scene flow, and services.
- `scripts/content/` for definition classes and sample data.
- `scripts/level/` for camera path, parallax, timeline, and mission runner code.
- `scripts/hero/` for hero controller, inventory, level, shields, retries, and squadron mates.
- `scripts/weapons/` for weapon runtime, projectile runtime, targeting, and collision rules.
- `scripts/enemies/` for enemy actor, behavior tracks, clusters, and boss phases.
- `scripts/collectibles/` for pickup runtime and pickup application rules.
- `scripts/debug/` for debug overlay, shortcuts, spawners, and test harnesses.
- `tests/` for C# rule tests and any Godot scene smoke tests.
## Slice 1: Project Shell
Create the Godot .NET project shell, root scene, and buildable solution before gameplay code.
Implement:
- `project.godot`.
- A root scene that can load menu, shop, mission, debug scenes, and end screens.
- Basic input actions for movement, primary fire, secondary fire, special fire, pause, debug overlay, and quick restart.
- A tiny smoke scene that displays the hero placeholder and exits cleanly in headless mode.
- A build command path using `.\godot --headless --path . --build-solutions`.
Testing and iteration support:
- Add a `DebugBootMode` setting that can start directly in menu, mission, weapon range, cluster sandbox, boss sandbox, or end-state sandbox.
- Add one command-line or exported setting for deterministic seed.
- Add a visible build/version label in debug mode.
Acceptance:
- Godot opens the project.
- The C# solution builds.
- The root scene can load at least one playable scene and one debug scene.
## Slice 2: Core Data Definitions
Implement the definition layer before content grows. Definitions should be small plain C# types or Godot resources, whichever is faster to edit and safer to serialize.
Implement:
- `MissionDefinition`.
- `DifficultyDefinition`.
- `CameraPathDefinition`.
- `LevelLayerDefinition`.
- `EnemyTypeDefinition`.
- `EnemyBehaviorDefinition`.
- `EnemyClusterDefinition`.
- `CollectibleDefinition`.
- `WeaponDefinition`.
- `SpecialWeaponDefinition`.
- `SquadronMateTypeDefinition`.
- Sample definitions for the first mission.
Testing and iteration support:
- Add a content registry that exposes definitions by stable id.
- Add a debug content browser that lists loaded missions, enemies, weapons, collectibles, difficulties, clusters, and boss phases.
- Add validation methods that report missing ids, invalid timings, invalid multipliers, empty weapon slots, and broken mission references.
Acceptance:
- The test mission loads from definitions.
- Invalid sample data produces clear validation errors before gameplay starts.
## Slice 3: Debug Foundation
Build shared debug tools early so every later feature can plug into them.
Implement:
- Toggleable debug overlay.
- Pause, resume, frame-step, and time-scale controls.
- Reload current scene.
- Restart current mission.
- Switch difficulty in test contexts.
- Set deterministic seed.
- Spawn actor by definition id.
- Jump to mission timeline marker.
- Toggle collision shapes and gameplay bounds.
- Toggle invulnerability.
- Toggle infinite special ammo.
- Toggle no enemy fire.
Testing and iteration support:
- Debug shortcuts should work with keyboard and clickable debug UI.
- Every debug command should be callable from C# so tests and future automation can use the same hooks.
- Debug overlay should show current scene, mission time, camera progress, difficulty, hero state, enemy count, projectile count, cluster id, boss phase, and random seed.
Acceptance:
- A developer can enter a test scene, pause time, spawn a target, fire, reset, and repeat without returning to the editor.
## Slice 4: Hero Runtime
Implement the hero as the first real gameplay actor.
Implement:
- Camera-relative movement bounds.
- Movement input.
- Shield charges.
- Retry count.
- Damage and death rules.
- Points and level-up thresholds.
- Primary weapon slots and current slot selection.
- Secondary weapon slot.
- Special weapon slot and ammo.
- Mission-persistent inventory state.
- Death state that clears collectibles and squadron mates.
Testing and iteration support:
- Add a hero sandbox scene with bounds visible.
- Add debug controls for damage, heal, kill, add points, set level, add shield, remove shield, set retries, and clear inventory.
- Add a quick toggle for invulnerability.
- Add a small text panel showing all hero state changes.
Acceptance:
- The hero can move inside bounds.
- Damage, shields, retries, death, rebirth, points, and level-up can be exercised without enemies.
## Slice 5: Weapon Test Range
Implement projectile infrastructure and the first weapon set in a dedicated range before wiring the full mission.
Implement:
- Projectile actor.
- Projectile ownership.
- Projectile lifetime.
- Projectile collision categories.
- Primary fire loop.
- Secondary fire loop.
- Special fire loop.
- Basic ballistic projectile.
- Basic forward secondary projectile.
- One special weapon projectile.
- Dummy enemy target.
- Dummy enemy projectile.
Testing and iteration support:
- Create `WeaponRange` scene with hero, dummy targets, enemy projectile emitters, and clear reset zones.
- Add debug controls to switch primary weapon, secondary weapon, special weapon, hero level, squadron count, and ammo.
- Add spawn buttons for stationary target, moving target, enemy projectile stream, and dense projectile wall.
- Add damage numbers or hit counters in debug mode.
- Add projectile count and collision count to overlay.
Acceptance:
- The player can test each weapon behavior within seconds.
- Projectile consumption rules can be verified in the range before enemies exist.
## Slice 6: Collectibles
Implement pickups after hero inventory and before enemy drops.
Implement:
- Collectible actor.
- Pickup collision.
- Pickup application service.
- Points pickup.
- Primary weapon pickup rule.
- Secondary weapon pickup rule.
- Shield charge pickup.
- Special ammo pickup.
- Squadron mate pickup rule.
- Clear screen pickup hook.
Testing and iteration support:
- Add pickup injector controls in the hero sandbox and mission debug overlay.
- Add a collectible test lane where pickups drift toward the hero.
- Add one-button spawn for every collectible type.
- Show before/after inventory state when a pickup is collected.
Acceptance:
- Every pickup type can be spawned and collected without enemy setup.
- Inventory state updates are visible immediately.
## Slice 7: Squadron Mates
Implement squadron mates once hero firing and pickups exist.
Implement:
- Mate spawning and despawning.
- Maximum mate count.
- Type switching.
- Hug formation.
- Orbit formation.
- Line formation.
- V formation.
- Follow formation.
- Mate primary and secondary firing.
- Enemy projectile consumption by mates.
Testing and iteration support:
- Extend `WeaponRange` with mate controls.
- Add controls for mate count, mate type, spacing, orbit speed, and follow target.
- Add projectile wall emitters to test consumption.
- Add formation ghost markers in debug mode.
Acceptance:
- All formations can be switched live.
- Mate projectile consumption and firing can be tested without a mission.
## Slice 8: Enemy Behavior System
Implement enemies and behavior tracks after weapons can damage targets.
Implement:
- Enemy actor with composed sprite parts.
- Health and damage handling.
- Score value.
- Drop table hook.
- Serial behavior track runner.
- Parallel behavior track runner.
- Movement path event.
- Orientation path event.
- Wait event.
- Fire projectile event.
- Enable/disable hitbox event.
- Spawn child event.
- VFX/SFX hook.
Testing and iteration support:
- Create `EnemySandbox` scene.
- Add dropdown or shortcuts to spawn enemy by type id.
- Add controls to restart behavior, scrub behavior time, slow time, and freeze movement while firing continues.
- Draw behavior path, current target point, fire mounts, hitboxes, and hurtboxes.
- Show behavior track names and active event names in overlay.
Acceptance:
- One enemy can run a serial movement sequence.
- One enemy can move and fire in parallel.
- Both can be killed by hero weapons in the sandbox.
## Slice 9: Enemy Clusters
Implement cluster scheduling once individual enemies work.
Implement:
- Cluster runtime state.
- Spawn schedule.
- Spawn anchors relative to screen, camera, world path, or marker.
- Cluster membership tracking.
- Destroyed, escaped, and resolved states.
- Completion reward.
- Difficulty-aware spawn interval multiplier.
Testing and iteration support:
- Create `ClusterSandbox` scene.
- Add cluster replay button.
- Add jump to cluster by id.
- Add one-button kill all, escape all, and complete all.
- Add timeline scrub and time-scale controls.
- Show cluster state, remaining enemies, escaped enemies, next spawn time, and reward status.
Acceptance:
- A cluster can be played repeatedly without restarting the full mission.
- Reward behavior can be verified for destroyed and escaped enemies.
## Slice 10: Level Runner
Implement the real mission stage after hero, weapons, enemies, clusters, and pickups can be tested alone.
Implement:
- Mission timeline.
- Fixed camera path.
- Speed curve.
- Camera-relative hero bounds.
- Background parallax group.
- Foreground parallax group.
- Interactive layer.
- Layer repetition.
- Layer transition hook.
- Spawn markers.
- Mission timeline markers.
- Music cue hooks.
Testing and iteration support:
- Add `TestMission` with short timeline sections: intro, normal cluster, transition, second cluster, boss marker, outro marker.
- Add jump controls for every timeline marker.
- Add camera speed override and freeze camera.
- Draw camera path, current progress, spawn markers, layer bounds, and hero bounds.
- Add a marker list UI for quick jumps.
Acceptance:
- The test mission can be played normally or jumped to any section.
- Parallax, camera speed, enemy spawns, and hero bounds remain coherent after jumps.
## Slice 11: Mission Flow
Wire the playable loop after the mission stage works in isolation.
Implement:
- Logo placeholder.
- Skippable intro choreography.
- Menu.
- Controls screen.
- Difficulty selection.
- Shop.
- Mission intro.
- Fade to gameplay.
- Boss intro transition.
- Mission outro.
- Rebirth retry state.
- Game over state.
- Normal victory state.
- Secret victory hook.
Testing and iteration support:
- Add debug boot modes for every flow state.
- Add skip choreography shortcut.
- Add force result shortcuts: retry, game over, normal victory, secret victory.
- Add a flow state overlay showing current state and allowed transitions.
- Add quick start with selected difficulty and selected special weapon.
Acceptance:
- The full route from menu to mission to end state works.
- Every choreographed or transitional state can be skipped or booted directly for testing.
## Slice 12: Boss Slice
Implement boss behavior after mission flow can reach the boss marker.
Implement:
- Boss actor based on enemy behavior runtime.
- Boss composed parts.
- Boss phase controller.
- Phase health or shared health.
- Boss projectile pattern hook.
- Boss intro.
- Boss destruction VFX hook.
- Boss music cue hook.
- Boss reward and mission completion trigger.
Testing and iteration support:
- Create `BossSandbox` scene.
- Add phase jump controls.
- Add damage boss, kill part, kill phase, and kill boss buttons.
- Add boss attack pattern selector.
- Add invulnerable boss toggle for pattern testing.
- Show boss health, part health, active phase, active pattern, and next phase trigger.
Acceptance:
- Boss phases can be tested without replaying the mission.
- The real mission can jump directly to boss intro and continue through victory.
## Slice 13: Difficulty
Implement difficulty after baseline systems exist, then apply it consistently.
Implement:
- Difficulty selection before run start.
- Active difficulty stored in run state.
- Difficulty applied to hero starting shields and retries.
- Difficulty applied to enemy health.
- Difficulty applied to enemy projectile speed.
- Difficulty applied to enemy fire cadence.
- Difficulty applied to cluster spawn intervals.
- Difficulty applied to boss health and phase timing.
- Difficulty applied to collectible drop rates.
- Difficulty applied to special weapon ammo.
- Difficulty applied to score.
- Optional mission overrides by difficulty.
Testing and iteration support:
- Add difficulty switcher to all sandbox scenes.
- Show active modifiers in debug overlay.
- Add compare mode that restarts the same cluster or boss phase under another difficulty with the same seed.
- Add validation that every difficulty has visible menu copy and all required multipliers.
Acceptance:
- A developer can replay the same cluster, enemy, weapon range, or boss phase on each difficulty quickly.
- The menu clearly communicates the active difficulty.
## Slice 14: Highscore And Run End
Implement end states once scoring and difficulty are stable.
Implement:
- Score accumulation.
- Score multiplier from difficulty.
- Highscore entry.
- Stored score table.
- Mission reached.
- Difficulty in score record.
- Victory type.
- Retry and game over flow.
Testing and iteration support:
- Add debug buttons to add score, clear local highscores, force highscore entry, and force each victory type.
- Add highscore sandbox with seeded sample scores.
- Show score event log in debug overlay.
Acceptance:
- Scores are recorded with difficulty and mission reached.
- Retry, game over, normal victory, and secret victory can each be reached directly and through gameplay.
## Slice 15: Content Expansion Pass
After the vertical slice works, expand content only where the systems are already easy to test.
Implement:
- More primary weapon variants.
- More secondary weapon variants.
- Remaining special weapons.
- More enemy behavior events if needed.
- More clusters.
- More layer transition styles.
- More boss attacks.
- More collectible visuals.
- More mission definitions.
Testing and iteration support:
- Every new weapon must be added to `WeaponRange`.
- Every new enemy must be added to `EnemySandbox`.
- Every new cluster must be added to `ClusterSandbox`.
- Every new boss attack must be reachable in `BossSandbox`.
- Every new mission section must get a timeline marker.
Acceptance:
- New content can be tested from a sandbox before being placed in the mission.
## Automated Tests
Use automated tests for pure rules and brittle integration points. Do not rely on automation for every visual or feel decision during the jam.
Implement C# tests for:
- Definition validation.
- Difficulty modifier application.
- Hero shield, retry, death, and rebirth rules.
- Point thresholds and level-up.
- Primary weapon pickup replacement rules.
- Secondary weapon replacement rules.
- Special ammo pickup rules.
- Squadron mate type and count rules.
- Cluster destroyed, escaped, and completed states.
- Score multiplier application.
- Highscore sorting.
Implement scene smoke tests when practical:
- Root scene loads.
- Menu loads.
- Shop confirms selection.
- Test mission loads.
- Weapon range loads.
- Enemy sandbox loads.
- Cluster sandbox loads.
- Boss sandbox loads.
The fast local loop should be:
1. Run the smallest relevant C# rule tests.
2. Run the relevant sandbox scene.
3. Use debug controls to test edge cases.
4. Run full build before commit.
## Manual Debug Recipes
Each feature should have a short repeatable manual recipe in this file or a later `DEBUG.md`.
Examples:
- Weapon collision: boot `WeaponRange`, spawn projectile wall, set primary to projectile-consuming shot, hold primary fire, watch consumed count.
- Cluster reward: boot `ClusterSandbox`, select cluster id, replay, kill all enemies, verify reward; replay, let one escape, verify no reward.
- Boss phase: boot `BossSandbox`, jump to phase 2, enable invulnerable hero, run pattern for 30 seconds, then kill phase.
- Mission transition: boot `TestMission`, jump to layer transition marker, freeze camera, step frames, verify parallax swap.
- Difficulty compare: boot `ClusterSandbox`, select Normal, replay; switch Hard with same seed, replay; compare spawn timing and projectile speed.
## Debug Controls To Keep Through The Jam
Keep these controls available in non-release builds:
- Toggle debug overlay.
- Reload scene.
- Restart run.
- Pause.
- Frame step.
- Time scale 0.25x, 0.5x, 1x, 2x, 4x.
- Toggle invulnerability.
- Toggle infinite special ammo.
- Toggle no enemy fire.
- Add points.
- Damage hero.
- Kill hero.
- Rebirth.
- Spawn collectible by id.
- Spawn enemy by id.
- Spawn enemy projectile stream.
- Replay cluster.
- Jump to mission marker.
- Jump to boss phase.
- Kill boss phase.
- Force mission victory.
- Force game over.
Remove or hide them only for release exports.
## Commit Cadence
Each commit should leave the project buildable and should include one small useful increment. Good commit boundaries:
- Project shell builds.
- Debug overlay boots.
- Definitions validate.
- Hero sandbox works.
- Weapon range works.
- Collectibles work.
- Squadron mates work.
- Enemy sandbox works.
- Cluster sandbox works.
- Test mission works.
- Mission flow works.
- Boss sandbox works.
- Difficulty works.
- Highscore works.
Before each commit:
1. Run relevant rule tests.
2. Run relevant scene manually or through a smoke test.
3. Run `.\godot --headless --path . --build-solutions`.
4. Run `jb cleanupcode --build=False` for touched C# files.
5. Update documentation for changed behavior.
## Priority Rules During The Jam
If time gets tight:
- Keep the full mission loop working.
- Keep one polished weapon better than many half-working weapons.
- Keep debug jumps and sandboxes working.
- Prefer data tweaks over new systems.
- Cut optional special weapons before cutting boss, shop, difficulty, or retry flow.
- Cut secret victory implementation before cutting normal victory and highscore.
- Cut additional enemy types before cutting cluster replay tooling.
- Cut visual polish only after preserving readable collisions and feedback.
The goal is a complete, testable side-scrolling shooter foundation that can be themed quickly when the jam topic is known.