Journal

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.

One of the largest refactors over the past several months has been the battle system.

The original battle system worked, but after years of adding mechanics, it had become difficult to safely extend. Counters, action timing, targeting, animations, victory rewards, auto-battle behavior, state effects, and post-action logic were all heavily intertwined.

We’ve been rebuilding that foundation so each part has a clearer responsibility.

For example, turn flow is now handled by a dedicated battle turn controller, action execution is more isolated, targeting is ...