sgdk-rpg

SGDK RPG

Build the game's rules as ordinary C, then connect them to SGDK's display, input, audio and storage services. SGDK has no built-in party, battle or item API. Preserve the project's architecture and chosen combat design.

Start with the rules that matter

Establish party size, battle participants, targeting, action costs, turn/time policy, progression and what defeat restores. Turn-based, active-time and action RPGs need different clocks and interruption rules; do not turn one Lab's model into a requirement for every RPG. Match the project's setting, artwork, music and pacing. The example's coastal fantasy is illustrative.

Choose one complete loop to prove: prepare a party, enter an encounter, commit an action, resolve its effects, apply the outcome once, then resume exploration. Keep those rules independent of rendering where useful. Do not introduce a universal game framework to demonstrate a small combat system.

Use the relevant reference

• Party and combat: immutable definitions,

derived stats, inventory transactions, targeting, turn order, status duration, seeded randomness, rewards and defeat recovery.

• SGDK integration: region-aware presentation,

readable targeting, palette/VRAM/DMA budgets, sound ownership and checkpoints.

• Adventure Lab: a standalone three-keeper RPG

with exploration, equipment, consumables, three encounters and a boss.

Other installed skills are optional: sgdk-ui for shared menu/text foundations, sgdk-dialogue for conversations, sgdk-levels for streamed exploration, sgdk-ai for roaming enemies, sgdk-save for storage formats, and sgdk-performance for measured bottlenecks. The Lab builds on its own.

Keep the important contracts visible

• Keep definitions in ROM and mutable party/battle state bounded in RAM. Choose

capacities for this game's content and report exhaustion; a console budget does not mandate a particular party size, level cap or battle formation.

• Derive equipment stats from base definitions and equipped IDs. Avoid repeatedly

adding/removing bonuses from already-modified values.

• Validate the actor, target, item stock and MP before changing state or RNG.

A rejected action must not consume resources or take a turn.

• Specify when order is sampled, which dead/removed participants are skipped,

and when status durations decrease. Distinguish turns from display frames.

• Separate committing an action from presenting its result. Message pacing,

target markers and animation must not apply damage or rewards again.

• Save semantic IDs and explicit bytes, not pointers, C struct images, sprite

handles or transient battle effects. Validate a complete record before replacing the current campaign.

Use ewrogers/sgdk:latest, pulled before validation. Verify unfamiliar APIs in its actual headers and source; the references were checked with SGDK 2.11 and GCC 16.2.0. Treat the Lab's functions as game code, not SGDK API names.

Prove the loop

Test missing MP/stock, invalid and fallen targets, healing caps, revival, equipment changes, status expiry, skipped turns, deterministic ties/RNG, zero-survivor defeat and exactly-once rewards. Check cancellation and message acknowledgment without replaying an action. Exercise corrupt/interrupted checkpoint recovery separately from battle rules.

Compile the actual adapters/resources in release and debug. Execute portable rules on host and base M68000 when possible. Then playtest complete encounters: targets should be distinct, attack messages readable, UI unobscured, and audio and pause consistent. Host tests or ROM compilation cannot establish frame-time headroom, VDP timing, SRAM retention or artistic quality on physical hardware.