Archive for 'Blog'

This update focused on a wide range of gameplay polish across menus, battles, treasure chests, camping points, and interaction systems.

A lot of this work was about making sure the game responds correctly after player actions. For example, using an item from the Item Menu now properly refreshes item quantities, keeps the correct target selected, preserves scroll position when returning to the item list, and updates character HP displays at the right moment. These may seem like small details, but they ...

This week we spent time tracking down a particularly tricky bug that, at first glance, looked like a full game freeze.

About 25% of the time when launching a debug scene, the player would appear completely frozen. No movement, no animations, no menu input — nothing. Relaunching the game would often “fix” it, which made it feel like a race condition or initialization issue.

Those are some of the hardest bugs to track down.

The Initial Hypothesis

The first instinct was that input ...

This week focused on a full refactor of the Equipment Menu to align it with the game’s data-driven architecture.

The UI is now entirely ViewModel-driven, meaning all display data (current gear, candidates, stat changes, etc.) is prepared ahead of time instead of being pulled directly from game state. This keeps logic, rendering, and data cleanly separated.

We also replaced custom list widgets with a unified BetterItemList, simplifying the UI and making behavior consistent across menus. Attribute display was redesigned into a vertical ...

Like many RPG fans, our team has felt inspired by Clair Obscur: Expedition 33. For those who haven’t yet experienced it, Expedition 33 is a potent reminder that turn-based RPGs can be creatively ambitious, deeply emotional, and highly rewarding.

As we continue developing Last Dream II, we are thinking carefully about how to make each class choice, dungeon, encounter, skill synergy, and discovery feel satisfying.

Expedition 33 also reminded us how much presentation matters. We want Last Dream II to leave a lasting impression through memorable worlds, ...

One thing we’ve been focusing on recently is something that’s a bit harder to show than new art or big system rewrites: making the game feel right.

A lot of systems in Last Dream II technically worked even before the refactor. Battles resolved correctly, items did what they were supposed to do, menus functioned, and progression systems all behaved as designed.

But “working” and “feeling good” are not the same thing.

As we’ve been rebuilding systems, we’ve been paying closer attention to things ...

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