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: