Split MainMenu into a generic WorldScene + Metal Slug's own scene - #26
Merged
Conversation
Resolves the "blocking design problem" from
docs/frame_engine_migration_plan.md: view/scene.MainMenu had
accumulated Metal-Slug-specific gameplay rules (hit detection,
auto-aimed shooting hardcoded to "projectile_prototype"/
"SpawnProjectile") inside what was meant to be the engine's one
generic, reusable scene type.
- view/scene/mainmenu.go -> view/scene/world_scene.go: WorldScene
keeps everything genuinely generic (script/physics/camera wiring,
the Prototype-clone spawnEntity mechanism, AABB helpers now exported
as AABB/AABBOverlap, PayloadFloat/NormalizeDir). No game-specific
logic remains.
- games/metalslug_demo/scene.go (new): this demo's own Scene, embedding
*scene.WorldScene and adding exactly the two rules that don't belong
in a general-purpose engine: spawnProjectile (auto-aim shooting) and
updateHitDetection (projectile damages enemy).
- Resolves the application/engine/engine.go FIXME as a side effect:
removed the package-level view/scene.Factories global (itself a
small "no globals" violation); engine.New now takes a
map[string]scene.SceneFactory supplied by the caller (main.go/
main_wasm.go), so scene registration is per-application, not
hardcoded engine-side.
- games/demo1 and games/metalslug_demo's config.yaml now register
distinct scene types ("world_scene" and "metalslug_scene"
respectively) instead of both pointing at the same "main_menu" type.
Verified with go build/go vet/gofmt, go test (+ -race) across the
touched packages, a WASM cross-compile check, and a live smoke run of
both games/demo1 and games/metalslug_demo (scene Setup + physics body
listing succeeds for both under the new scene types; the run stops at
the sandbox's known pre-existing ALSA/audio-device limitation before
reaching the interactive game loop, unrelated to this change).
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
Physically moves every package classified as "Move" in
docs/frame_engine_migration_plan.md's inventory into a single new
frameengine/ directory, mirroring that plan's proposed frame-engine
repo layout exactly (frameengine/application/{config,engine,game,data},
event, events, object, physics, ports, process, resource, script,
vec2, view/{ui,input,camera,scene}).
Nothing outside frameengine/ changes behavior -- this is a pure move
plus import-path rewrite (goengine/x -> goengine/frameengine/x) within
the same module. main.go, main_wasm.go, and games/metalslug_demo's
scene.go are updated to import from the new paths; games/, logic/,
and docs/ are untouched, since they're staying in this repo per the
plan's inventory.
Once frame-engine (github.com/diego3/frame-engine) is ready to receive
it, the actual repo split becomes: copy frameengine/*'s contents to
the new repo's root, `go mod init github.com/diego3/frame-engine`, and
strip the "frameengine/" segment from every import path -- no other
restructuring needed, since this directory's internal layout already
*is* the target repo's layout.
Stacked on #26 (the WorldScene/MainMenu split) -- that split had to
land first so this move carries the generic scene.WorldScene, not the
old game-logic-leaking MainMenu.
Verified: go build/go vet/gofmt clean on every touched file, go test
(+ -race, same pre-existing box2d-go checkptr failure as before,
unrelated) all passing, a WASM cross-compile check, and a live smoke
run of both games/demo1 and games/metalslug_demo (identical output to
pre-move).
…kage Consolidate the core engine into a frameengine/ package
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves the "blocking design problem" identified in
docs/frame_engine_migration_plan.md(PR #25):
view/scene.MainMenuwas meant to be the engine's one generic, reusable scene type,but over the Metal Slug demo's build-out it accumulated real gameplay rules — hit detection,
auto-aimed shooting hardcoded to
"projectile_prototype"/"SpawnProjectile"— that have nobusiness in a general-purpose engine. This had to be split before any repo extraction could
happen; this PR does that split now, inside this repo, before anything moves.
What changed
view/scene/mainmenu.go→view/scene/world_scene.go:MainMenuis renamedWorldSceneand keeps only what's genuinely generic — script engine wiring, physics/camera setup, the
Prototype-clone
spawnEntitymechanism, projectile movement, and the AABB helpers (nowexported as
AABB/AABBOverlap, plusPayloadFloat/NormalizeDir) so a game's own scene canreuse them. No Metal-Slug-specific logic remains in this file.
games/metalslug_demo/scene.go(new): this demo's ownScene, embedding*scene.WorldSceneand adding exactly the two rules that don't belong in the engine:
spawnProjectile(auto-aimshooting from the controlled entity) and
updateHitDetection(projectile damages enemy).application/engine/engine.goFIXME as a side effect: removed thepackage-level
view/scene.Factoriesglobal (itself a small "no globals" violation perADR-006/CLAUDE.md) —
engine.Newnow takes amap[string]scene.SceneFactorysupplied by thecaller, so
main.go/main_wasm.goregister their own applications' scene types instead of theengine hardcoding them.
games/demo1andgames/metalslug_demonow register distinct scene types(
world_scene/metalslug_scene) instead of both pointing at the same"main_menu"type.Validation
go build ./...,go vet ./...,gofmt -l(clean on every file this PR touches — the onegofmtfinding,physics/types.go, is pre-existing drift onmain, unrelated to this change).go test ./...andgo test -raceacross the touched packages: all passing.GOOS=js GOARCH=wasm go build) sincemain_wasm.gochanged: passes.games/demo1andgames/metalslug_demo: both load their scene, buildphysics bodies, and print the expected body listing under their new scene types
(
world_scene/metalslug_scene) before hitting this sandbox's known, pre-existing ALSA/audiolimitation — same as every other run in this environment, unrelated to this change.
Generated by Claude Code