2 min read

Chronicle of Embers: The Next Bigger Shape

A spoiler-light teaser for Chronicle of Embers and why a save-aware RPG-style game changes the way MBOP Arcade has to think.

Chronicle of EmbersJRPGRoadmap

Chronicle of Embers is the arcade growing up a little.

Dungeon Dash proves a fast action loop. Rift Relay proves a puzzle loop and a cleaner repo boundary. Chronicle of Embers points toward something larger: an RPG-style game where saving matters, progression matters, and the player expects the world to remember what happened.

That shift changes the work.

Why saving changes everything

In a short-run arcade game, the run can end and the player can start over. State is temporary. The game cares about score, survival, and maybe a few unlocks later.

In an RPG-style game, state becomes the game:

  • Where is the player?
  • Which conversations happened?
  • What did the player collect?
  • Which battles were won?
  • What should the continue button restore?

Those questions force better architecture earlier. A casual save blob can work for a tiny prototype, but it becomes painful if the game grows. Chronicle of Embers needs a save-aware foundation even while the first playable slice stays small.

The IP line

The inspiration is classic console RPG structure: top-down exploration, clear interactions, simple battles, and a sense of adventure built from readable constraints.

The implementation has to stay original. No borrowed names, maps, enemies, art, text, or protected franchise language. The right target is “classic-inspired,” not imitation.

Why this belongs in the blog

This is exactly the kind of project where the build notes matter. A larger game will involve decisions about save schema, content files, combat shape, map data, party growth, UI, and repo boundaries. Those decisions are useful to document because they become reusable patterns.

Chronicle of Embers also shows why MBOP is more than a pile of games. It is a way of building with memory: repo memory, design memory, operator memory, and eventually player memory too.

For now, this post is only a marker. Another Smith is actively working the feature buildout lane, so the blog should not touch that repo. The correct move is to explain the direction here, then let the game implementation continue in its own lane.