Journal

Deep Dive: Chasing a Ghost — Debugging a Random “Freeze” Bug

Posted by:

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

Continue Reading →

Rebuilding the Equipment Menu UI

Posted by:

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

Continue Reading →

Lessons from Clair Obscur: Expedition 33 as We Develop Last Dream II

Posted by:

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

Continue Reading →

When Systems Work… But Don’t Feel Good

Posted by:

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

Continue Reading →

Why So Many Systems Are Data-Driven

Posted by:

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

Continue Reading →

Improving Rewards After Battle

Posted by:

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

Continue Reading →

Reworking Items and Inventory

Posted by:

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

Continue Reading →

Dungeon Art — Dragon Statues

Posted by:

Dungeon Art — Dragon Statues

This week’s focus is dungeon decoration: dragon statues.

These come in multiple sizes, directions, damage states, and coverings like moss and snow.

These variations help make dungeons feel aged, abandoned, or environment-specific depending on where they appear.

Continue Reading →

Boss Showcase — The Fates and Hecate

Posted by:

Boss Showcase — The Fates and Hecate

This week we’re highlighting the Fates and Hecate.

The Fates were designed with a unique visual concept — partially obscured forms with a “void” beneath their robes, giving them an otherworldly presence.

Hecate builds on that idea, with additional elements like energy orbs and hidden arms that can emerge during battle.

These designs help differentiate major encounters from standard enemies and give boss fights a stronger identity.

Continue Reading →

Making Auto-Battle Smarter

Posted by:

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.

Continue Reading →
Page 1 of 28 12345...»