Framework Roadmap

p

This roadmap tracks reusable systems that should accelerate future games built with RapidGameFramework. Game-specific sprint logs and playtest feedback belong under Game Examples and Testing And Playtest Notes.

See Framework Modularity Audit for the current extraction audit covering recent game work that may become reusable framework code.

See Performance And Engine Refactor Plan for the dedicated optimization/refactor sprint track covering profiling, memory, render caches, UI pooling, entity systems, data loading, and mobile/browser hardening. That broad track is now closed for the current release cycle; see Release Sprint Plan for active work.

Current Foundation

• Shared menus, scene routing, settings, input remaps, theme persistence, text-size presets, pause overlays, achievements, save slots, and build profiles.
• Data-driven event/resource systems for decisions, encounter decks, resource meters, and choice effects.
• Card, pack, shop, inventory, economy, modifier, collection, and battle systems for card and collection games.
• Arcade helpers for match flow, powerups, paddle/ball physics, AI profiles, result screens, controller prompts, and touch controls.
• Platformer helpers for character motion, level loading, hazards, pickups, enemies, exits, and level-select progress.
• Tactical/grid helpers for alchemy reactions, codex state, spell loadouts, deck rotation, targeting, grid combat, adventure definitions, and procedural battlefield generation.
• Sprite/theme/audio systems for game-specific sprite maps, cached sprite rendering, theme JSON, palette editing, music manifests, and sound effects.
• Editor foundations for level JSON, sprite mapping, theme editing, and content validation.

Near-Term Framework Priorities

1. Follow Release Sprint Plan as the active sprint plan.
2. Keep build profiles stable for all_demos, arcade_pong, and emoji_card_collector; continue tightening per-game asset inclusion.
3. Continue targeted engine work only when it supports Arcade Pong Release Feedback, Emoji Card Collector First Release Plan, or a measured profiler/playtest finding.
4. Finish polishing shared modal/dialog sizing so achievements, results, settings, and confirmation screens behave consistently across games.
5. Expand gameSettingsPanel so game tuning definitions can be rendered from JSON without custom scene UI.
6. Continue generalizing controller prompts, menu focus, shoulder-tab navigation, scroll control, and on-screen-control hiding through the input system.
7. Keep sprite maps game-local while sprite loading, caching, transformation, mirroring, greyscale, animation slicing, and fallback generation remain framework features.
8. Add fixture saves before any future save-shape migration and keep migration smoke tests green.

Data And Content Tooling

• dataValidationManager: expand reusable JSON validation for levels, menus, themes, build profiles, sprite maps, achievements, adventures, and game settings.
• levelEditorManager: continue growing the shared level editor toward large tile maps, void/non-playable space, layers, object palettes, triggers, collision previews, and controller-first editing.
• Godot RGF Level Tools plugin: keep the native editor bridge focused on faster level authoring without replacing JSON. Next planned editor tasks are drag painting, eraser mode, rectangle/stamp brushes, layer controls, collision/validation overlays, and a playtest-current-level action.
• spriteManager and Sprite Mapper: keep assignment JSON external and game-local while framework code handles loading direct PNGs, sheet cells, animation ranges, transforms, cache warming, and missing-required manifests.
• spriteRenderManager/future render effects: add a data-driven shader/effect layer for sprite animation polish, such as glow, trail, palette pulse, dissolve, hit flash, and low-power fallbacks.
• themeManager/settingsManager: continue standardizing colors, font roles, text sizes, backgrounds, button styles, and live theme refresh across menus and games.
• buildProfileManager: validate package-specific start scenes, include roots, exclude roots, export presets, artifact paths, and future signing/icon metadata.

Gameplay Framework Targets

• actionEffectManager: normalize costs, cooldowns, targets, and effect resolution for spells, powerups, card actions, items, and platformer abilities.
• runManager: own active-run lifecycle, objectives, collected rewards, completion/failure/abandon/retry, summaries, and stat events.
• entityManager: store actors, enemies, projectiles, pickups, hazards, interactables, and game pieces as save-friendly dictionaries with stable ids.
• entityRenderer: render entities from sprite maps with pooling, health bars, status indicators, and theme-aware fallbacks.
• aiController: share difficulty/profile logic across arcade opponents, tactical enemies, platformer walkers, bosses, and future board/RPG agents.
• interactionTriggerManager: handle exits, doors, switches, traps, scripted events, environmental reactions, and objective gates.
• unlockManager: centralize progression gates for modes, levels, adventures, cards, items, achievements, tutorials, and features.
• tutorialManager: keep first-run checklists, contextual prompts, next-step hints, and completion state data-driven.

Genre Expansion Targets

• Arcade games: richer arena renderers, projectile helpers, powerup effect definitions, AI profiles, scoreboards, replays, and local stat summaries.
• Platformers and metroidvanias: scene builders, checkpoints, camera bounds, moving platforms, one-way platforms, ability gates, hazards, secrets, and larger editor-authored maps.
• Tactical RPGs and roguelikes: adventure chains, biome definitions, encounter tables, rewards, objectives, deck/loadout systems, and reusable grid AI.
• Board games: turn phases, dice pools, board spaces, legal-move rules, scoring, ownership, and deterministic saveable game state.
• RPGs: party state, equipment, quests, dialogue, combat rules, elemental interactions, and status effects.

Done Means

A framework feature is considered reusable when it:

• Lives under scripts/systems/ or shared editor tooling.
• Accepts game data paths/options rather than hardcoding a specific game.
• Saves and restores dictionary state where needed.
• Has at least one current game integration.
• Has smoke-test coverage for the manager behavior or data validation.
• Is documented in Reusable Systems API or the relevant schema/example page.