Megadev multiplayer

Start with the user's player count, joining/leaving rules, camera behavior and death/respawn policy. Reuse the game's existing input, clock, renderer and resource owners. Local multiplayer is application logic, not a Megadev multiplayer API. Two 68000s do not imply one CPU per player, and extra RAM does not increase VDP sprite or scanline limits.

Keep identity separate from input

Read players and input for stable socket-to-player claims, first-sample baselining, disconnect grace, deliberate leave and shared menu actions. Poll once per display interval through the existing input owner. Never add a second BIOS or direct reader to obtain another player's buttons.

megadev-input owns pad/mouse and Team Player/EA protocols. The standalone Lab includes that project-owned reader for reproducibility; its eight socket positions are a Lab convention, not an SDK player enumeration. A mouse does not become a pad because its buttons share mask bits. Adapter support needs device qualification, not just a fixture or enum.

Choose camera and recovery policies together

Use camera and respawns to decide who participates in framing, what stops separation, and where players reappear. Keep world state and collision authoritative even when sprites are culled. A shared camera cannot show unlimited separation; choose a tether, regroup, split view or other policy explicitly rather than hiding one player accidentally.

Keep one player's death, cooldown and reconnect separate from other players' state. Bound spawn searches and provide a fallback. Integrate these actions with pause and scene transitions; do not restart the whole room or discard a live Sub job merely because one player leaves.

Integrate and prove

Co-op Lab demonstrates four keepers lighting a garden, late joining, a shared camera, white stun-recharge bars and independent returns. Its setting, art, music, controls, movement speeds and game rules are illustrative. Adapt techniques to the user's design, not the Lab's design to their game.