Princess Maker 2 case study: original rules, a new iPad experience

Investigation: identify where the original can be adapted

REA stands for Reverse Engineer Anything. It connects reverse-engineering tools so an AI agent can investigate executable files and application structure. Native-program analysis can use tools such as Ghidra or Hopper to examine functions and call relationships; JavaScript and Electron analysis can follow modules and data flows. Findings are recorded with evidence that can inform later implementation.

Reverse engineering has a long history. What changes is how its tasks connect. AI agents can participate in a process that previously required someone to interpret an analysis tool's output and carry that explanation into another development environment. A single workflow can trace a function, explain it, implement a change and test it. This connection builds on existing tools and accumulated open-source work.

The Princess Maker 2 project left specific records of that investigation. Early materials include Ghidra-based analysis of a 16-bit DOS executable, functions and cross-references. Later records trace how visual resources are selected and copied. Public PC-98 source code was also consulted, but it was not treated as identical to the Korean DOS version. Executable behavior had to be compared with the reference source.

That analysis helped identify where changes could be made. To attach a new image at the right moment, the implementation must know which image a particular game state selects. REA's contribution was evidence about the original behavior on which implementation and testing could rely; producing the finished iOS app required the subsequent development work.

Implementation: retain execution, connect new visuals and controls

This app did not rewrite every rule of the original game. DOSBox Pure handled the original game's execution, input, saves and audio, while an iOS frontend built with C++ and SDL connected touch controls and the new display. It preserved the original execution while adapting the device interface and visual presentation.

That choice clarified the development goal. Existing rules and save structures could be retained, concentrating work on the visuals and controls the user wanted to change. Combining an original runtime with a new interface is one route to using older software on new devices. Analysis tools help determine which parts to preserve and which to replace.

The visual update used artwork made with image-generation tools, processed into transparent PNGs and mapped to original resources. Backgrounds and information panels needed consistency, while characters had to change with age, lessons, jobs and locations. If the new image did not match the image selected by the original game, an attractive individual screen could still be followed by an inconsistent scene or broken movement. The user identified these mismatches, and the scene mappings were revised.

The comparison below keeps the original housework sequence while changing the backgrounds, characters and information panels. Some small equipment and status icons retain their original appearance; this was not a replacement of every image in the game.

Outcome: continue a saved game on the actual iPad mini

The project's endpoint is significant. Codex carried the analysis into artwork production and processing, scene mapping, code changes, tests, iOS building and signing, and installation on the iPad. The workflow brought together analysis tools, image-generation tools, compilers and device-management tools. Its output was an app that could run again on the actual device.

Installation included backing up existing saves and comparing hashes for 67 game and runtime files before and after the update. The final report recorded 54 desktop execution-flow checks and nine iOS simulator checks passing. On the physical iPad, the app launched, resumed the saved game and displayed the updated home screen. These results apply to that version and those checks; they do not establish exhaustive coverage of every branch or device.

The process involved repeated revisions and checks. Artwork consistency was revisited, and checks interrupted by insufficient storage were resumed. A person supplied the goals and aesthetic judgment, evaluated the results and provided the necessary device connection and access. Saying that Codex performed the end-to-end work means that it carried the technical execution from analysis through installation under those conditions. Human judgment and existing software remained part of the process.

That distinction makes the change more tangible. The user could focus more on describing the desired result and unacceptable errors, instead of learning every technical specialty to perform each stage personally. As AI takes on more execution, translating human requirements into testable conditions becomes increasingly valuable.

Remaining scope: consistent scenes and continuity of saves

One improved screen did not guarantee quality across every scene. The recurring task was to match the action selected by the original game to the new artwork. Backgrounds, characters and information panels had to describe the same state, while progress in old saves had to continue. Launching an app and establishing reliability over long play sessions remain different milestones.

The comparison GIFs use actual desktop verification captures. The home-screen GIF alternates still captures from the same saved state; the housework GIF sequences actual execution frames. No intermediate movement was synthesized. The physical iPad result is distinguished through the device capture above and the installation and verification records.

This personal project does not confer permission to redistribute original game files or third-party artwork and code. Keeping the original execution, newly written interface code, new artwork and outside materials distinct is also part of the development outcome.

Lessons: define what needs rebuilding first

My first lesson is that achieving a desired experience does not require rebuilding everything. Preserving the rules and save structure while changing the screen and input narrowed the task. REA supplied evidence about where to intervene; Codex Work connected that evidence to production, checking and installation.

For the next project, I would again identify what must remain, what should change and which checks must pass on the actual device. The user describes the desired outcome and unacceptable errors; the agent carries implementation and repeated checks forward. That shift in roles matters more than a single demonstration.

Software companies can also be assessed through this lens. Alongside the speed of implementing similar features, continuity with old files, dependable updates and recovery become important. The separate case studies below examine REA’s function reconstruction and ArtCraft’s open editing tools in more detail.