megadev-planning

Megadev planning

Turn the user's game idea into a small, testable plan. Keep their setting, art, audio, mechanics and controls. Teaching examples illustrate hardware decisions; they are not game designs to copy.

Start with what must work

Inspect the project before proposing a new architecture. Identify its target regions, current renderer/audio services, resident code, module loader and evidence from previous tests. Ask about unknown player-facing requirements only when they change feasibility. Use provisional estimates for the rest and label them.

Choose the smallest milestone that proves the main risk: for example, loading the next room without interrupting input or audio. A planning task does not require a new ROM, Docker installation or emulator configuration unless that proof is part of the request.

Make the constraints visible

Read hardware budgets for sourced capacities and the distinction between shared base-console limits and Mega CD additions. Treat physical ceilings, framework reservations, project allowances and measured usage as different things.

Plan these together:

• Main/Sub responsibilities and communication. A second CPU is not a transparent second thread for the Main frame loop.
• Resident code/data, replaceable modules and temporary buffers. Include C startup, stacks, BIOS space, packed input and decoded output at their peak overlap.
• Word RAM mode and owner during each phase. Keep code and callbacks reachable while memory changes hands.
• VDP tables, patterns, palettes, crowded scanlines and upload time. Extra RAM does not increase VRAM or sprite limits.
• Audio residency and disc access. Decide what happens to CD-DA while reading data, and protect active PCM sample data from refill/replace operations.
• Late/failed loads and save-media failures, when relevant. A plan needs a fallback, not an assumed perfect drive.

Use the workflow to choose trade-offs and define proof tasks. Build/API implementation belongs with megadev-project or the relevant system work; do not import SGDK APIs, mapper assumptions or XGM drivers.

Produce an editable plan

Copy the useful parts of game-plan.md into the project. Explain the decision and its uncertainty in plain language. Avoid making the user tune every theoretical limit before there is a measured reason.

For arithmetic, adapt budget-example.json and run:

python3 scripts/budget_check.py /path/to/budget.json

Read the budget format before editing its phase/ownership model. The helper checks only declared allocations and demands; PASS does not certify a layout, performance, a handshake or physical-console behavior. Its optional load calculation uses explicit assumptions and always says so.

Close with the next executable proof, a pass criterion, and what still needs an emulator or real hardware. Inspect the selected Megadev source before promising an unfamiliar API; the reference baseline is evidence, not a substitute for the installed version.