Archive for 'Blog'

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 ...

Status effects are a major part of Last Dream II, so we’ve spent a lot of time making that system more robust.

Blind, Poison, Berserk, Sleep, Paralysis, Confusion, Silence, Morph, Mini, Disease, Zombie, Stone, Doom, Frozen, attribute changes, elemental changes, and equipment-granted states all need to behave consistently.

The refactor separates the data describing a state from the logic that applies, removes, refreshes, and scores it. This helps both battle mechanics and auto-battle AI understand states more accurately.

It also lets us support ...

A lot of recent work has gone into refactoring menus.

Item menus, equipment menus, shop menus, synthesis menus, skill menus, auto-battle menus, and NPC interaction menus all need to feel smooth. They also need to work with modern game data instead of relying on older global systems.

We’ve been rebuilding these menus around clearer controller, view-model, and interactor patterns. In practical terms, that means menus are easier to update, easier to test, and less likely to break when we change underlying game ...

Equipment has become one of the deeper systems in Last Dream II, so we spent a lot of time rebuilding how it works behind the scenes.

Equipment is now handled as individual instances rather than just simple item IDs. That matters because equipment can support things like sockets, gemstones, state bonuses, set bonuses, and future customization.

We also refactored the logic that determines what equipment a character can use, what bonuses it provides, and how those bonuses affect derived stats. This makes ...

Another major area of work has been the save/load system.

Older versions of the game relied too much on broad, flexible serialization. That made it convenient early in development, but risky as the game grew. We’ve moved toward a stricter save architecture where persistent game state is explicitly saved and loaded.

That means actor progress, party data, inventory, map position, playtime, treasure state, renown, and other long-term progress now live in clearer data structures.

The benefit is reliability. Save files are one of ...

This week we’re showing another mystery boss!

For this boss battler, the goal was to communicate arrogance and magical power. He doesn’t use a traditional weapon; instead, his presence comes from his stance, expression, and glowing magical energy.

We received versions with and without flames, which gives us flexibility depending on how we want to present him in battle. The fiery version has a much more dramatic boss feel, while the no-flame version can be useful for an earlier form.