Journal

You may have noticed us mentioning “data-driven” systems quite a bit.

At a high level, this means that game content — such as items, states, equipment, and other systems — is defined in structured data rather than being hardcoded directly into the logic.

This approach has several important benefits:

• It makes balancing much easier, since values can be adjusted without rewriting code

• It reduces the likelihood of bugs caused by inconsistent logic

• It allows systems to scale more easily as the game grows

• It creates a ...

We’ve also spent time refactoring how rewards are calculated and presented after battle.

In the past, reward handling was more loosely structured, which made it harder to cleanly display things like “before vs after” values or animate gains in a consistent way. As part of the refactor, we introduced clearer data structures to track original values and gained values separately.

That means gold, experience, and item drops are now handled in a way that makes it easy to:

• Show exactly what changed after ...

Items have been rebuilt to be fully data-driven.

In earlier versions of the game, item behavior was often tied directly to code in ways that made it difficult to extend or safely modify. That worked early on, but as the number of items grew — including consumables, equipment, gemstones, quest items, and more — it became increasingly difficult to manage edge cases and keep behavior consistent across menus and battle.

We’ve refactored items so each one has a clear definition and validation ...

Auto-battle is something many players rely on, especially for grinding or replaying content.

We’ve been refactoring the system so decisions are based on actual expected outcomes rather than simple rules.

That means:

• Evaluating buffs and debuffs based on real impact

• Considering probabilities of states applying

• Choosing skills based on context instead of fixed priority

The goal isn’t to make auto-battle perfect — it’s to make it feel intelligent and consistent.

One question we expect (and completely understand) is: why did the refactor take so long?

The short answer is scope.

Over time, Last Dream II grew into a large system with many interconnected parts — battle logic, targeting, states, menus, inventory, equipment, saves, maps, and more. Many of these systems worked, but they were tightly coupled. That made even small changes risky.

Instead of patching over issues, we chose to rebuild the foundation so systems are more isolated and predictable.

That meant rewriting large ...

Treasure has also gone through a major refactor.

The older treasure system relied on a mix of global state and map-specific logic. That worked for a while, but it became hard to manage as the game added more treasure types, randomized rewards, mimic chests, blue chests, gold chests, dungeon phases, revisits, and roguelite-style progression.

The new treasure system tracks chest state more explicitly. Treasure can now be initialized deterministically, saved properly, restored when returning to maps, and resolved through cleaner reward logic.

We ...