Entry 001 / 27 September 2026

Building the foundations of a Days remaster

We are building a faithful reconstruction of Kingdom Hearts 358/2 Days using Kingdom Hearts III as the runtime foundation. The goal is Days gameplay, missions, panels and progression with a modern presentation. This is an independent fan project in early development, with no announced release date.

Establishing the in-game interface

A cooked diagnostic widget has now loaded, appeared and been removed inside KH3 at its native title screen. That establishes a route for authored UI to reach the game. The partial Days menu is also progressing: separate artwork and logo layers are prepared locally, and the menu navigation core passes 10 offline tests.

This is not yet the complete in-game Days menu. Artwork rendering, input ownership and real New Game/Load destinations still need integration and runtime verification.

Using the original as a laboratory

We replay recorded inputs from controlled states in the original game and capture what happens. A title and Mission Mode suite has passed 26 reference comparisons. Movement and jump experiments also reproduce sampled behavior, including different arcs for short and held jump input.

Some memory fields are useful candidates for future telemetry, but their units and ownership are not fully established. These observations are research results, not a claim that matching player physics already runs in the remake.

What a faithful 1:1 remake means to us

Our target is a 1:1 reconstruction of the original game's underlying rules, content and progression, with modern presentation. The original DS game is the specification: KH3 supplies the runtime foundation, but its combat and progression rules are not automatically the rules for Days. This standard governs implementation and acceptance testing throughout development.

We are building a reference record of movement, jumping, targeting, ground and aerial combos, magic, Limit Breaks, damage, hit reactions and status effects. Important actions need measured startup, contact and recovery timings, including frame counts where practical. When behavior is uncertain, the plan is to reproduce it in the original before implementing it.

The panel system deserves the same care: grid dimensions, placement and rotation, linked panels, multipliers, inventory restrictions, unlocks and resulting statistics. The scope also includes equipment, experience, shops, synthesis, rewards and challenge systems. These defining mechanics must survive the move to a modern presentation.

For every mission, the intended record covers room order, objectives, enemy spawns and conditions, treasure, scripted events, mission gauge behavior, optional tasks, completion rules and rewards. Enemy and boss research covers attack patterns, ranges, cooldowns, resistances, reactions and phase changes. Room topology, traversal boundaries and landmark placement will be checked against reference captures rather than memory.

Measure, reproduce, compare

The comparison workflow starts from a known state in the original, replays a recorded input sequence and captures the result. The equivalent scenario then runs in the remake. We compare movement, attack and hit timing, HP and damage, enemy states and objective progress. Screenshots and video complement numerical measurements; higher-resolution rendering should not obscure a gameplay discrepancy.

The reference tooling already supports repeatable menu and movement experiments. Extending that into paired original-versus-remake tests across gameplay systems is still ahead. Each comparison needs recorded expectations, tolerances and a clear pass or fail. Where randomness matters, controlled development seeds will help make failures reproducible.

Code existing or compiling is not enough. Our completion standard is to build a feature, exercise it in-game, compare it with the reference, correct differences and check that earlier behavior still works. Research, implementation, successful builds, runtime testing and reference verification are tracked as separate milestones.

The full journey, not isolated demonstrations

Before expanding production across the campaign, one representative mission must work from entry through combat, objectives, rewards, saving and restarting. Final verification must then begin with a clean save and reach the end of progression, including tutorials, panel and equipment unlocks, shops, bosses, world transitions and saves that survive a restart. Crashes, softlocks and incorrect unlocks count as failures even when an individual encounter looks right.

Any intentional departure from the original will be documented with its reason and gameplay impact. The remake will use a KH3-style camera and modern camera controls. Reproducing the DS camera's hardware limitations is not a fidelity goal. Camera testing will focus on visibility, targeting, collision and readable encounters within Days' rooms. Other presentation upgrades and the proposed placement of the collection's movie scenes will be documented without silently changing Days' balance or identity. Research into those movie scenes includes their story placement and the feasibility of rebuilding scenes with compatible KH3 assets and animation.

Foundations before content counts

The reusable mission core passes 13 synthetic tests. Recovered mission records help organize research; they do not represent playable missions. We still need native gameplay adapters and a complete end-to-end mission.

Earlier bounded experiments reached controllable Roxas and an authored test map. Startup failures in later trials mean a reliable production entry route remains an active engineering problem.

Protecting the ordinary game

The intended Days launcher will start the player's owned KH3 installation and provide its own menu and state. Base KH3 and Re Mind must remain playable. Temporary deployment rollback and save/config inventories are already part of testing, but full save isolation and coexistence are not yet proven.

Next production milestone

The immediate priorities are reliable menu entry, input ownership, save routing and gameplay initialization. After that, the aim is one representative mission that can be completed, saved, restarted and compared against the original before expanding content.

Future work includes the full panel system and research into integrating the collection's Days movie scenes at the correct story points. Asset work follows a reuse-first process; original game assets, ROMs, saves and keys are not distributed in project materials.

This log will report evidence, failures and remaining uncertainty alongside each milestone.