Legend of the Green Dragon: What rc.1 Revealed

On November 13, I published the first release candidate of Legend of the Green Dragon: Resurrection. The tests were green, the ZIP was on GitHub, and then my first real-server installation exposed a problem the test suite had missed.

I Changed What Resurrection Was Supposed to Be

When I wrote about Resurrection in September, the rule was to preserve the original gameplay while modernizing the code underneath it. That was still the direction when the modernization pull request merged on October 23.

On October 30, I changed the rule.

I still wanted to preserve Legend of the Green Dragon 1.1.2 DragonPrime Edition. The original 417-file source remains protected under its historical tag, and the Resurrection work stays separate from that record. I wasn't going to rewrite history or pretend I created a game that belonged to the people who built it long before I touched the repository.

But I no longer wanted the modern version chained to every old decision. I wanted Resurrection to become my version of the game. That meant I could change the interface, presentation, text, or gameplay when there was a reason to do it, provided the change was deliberate, documented, and tested. It did not mean tearing the game apart just because I could.

I Wanted a Game I Would Actually Want to Open

I liked the old Legend of the Green Dragon. I played it years ago, and there is a reason I kept a copy of the source. But liking what a game used to be doesn't mean I wanted to keep looking at the same old skins on a phone in 2026.

I approved one dark fantasy interface to replace the eighteen old skins. The game gained location scenes, race portraits, stat and item icons, clearer character information, health and experience bars, and a combat screen that makes the fighters and their actions easier to follow. Claude produced the original SVG artwork from the direction we established. I reviewed the batches before they went into the project.

That work wasn't just throwing artwork onto a text game. The interface had to respect how the game actually moves a player through its world. A phone needed usable navigation instead of a desktop layout squeezed down until the links were too small to hit. The mobile tab bar ended up using anchors within the current page instead of a shortcut back to the village, because a shortcut like that could interfere with a fight or another required game step.

We also changed the way battles were presented, adjusted colors and spacing, rebuilt forms and tables, and made room for the information a player needs without drowning the page in decoration. The art included portraits for creatures, training masters, and the Green Dragon. It was a lot of work for a game whose original appeal was mostly words on a screen.

I wanted the game to stay recognizable, but I didn't want it trapped in the original interface. Replacing the old skins was a deliberate decision, not something the modernization work forced me to do.

The Risky Parts Had to Be Designed Before They Were Built

The project started in ChatGPT, and I later moved the coding work to Claude. One Claude session handled planning and review while another made changes and ran the tests. When I installed the release candidate on my VPS, I used ChatGPT again on the server side. I defined the requirements, reviewed the results, and sent work back when it didn't meet the standard.

Two decisions show why that process mattered.

The first was installation. I wanted somebody without command-line access to be able to install and upgrade the game from a hosting panel. That sounds like a convenience feature until you think about what it does. A web-accessible setup page can initialize a database and create an administrator account. If the wrong person can use it, you have a serious problem.

I required a design and a threat model before the implementation. The browser installer needed a one-time token file created by someone with access to the server's files. It had to refuse ordinary insecure HTTP, and it had to stop offering installation once the game was already installed and current. That was a product feature and a security boundary at the same time. It couldn't be treated as just another form.

The second decision was account recovery. At first, I was willing to leave forgotten-password recovery as a known gap for the release candidate. Then I reconsidered. If someone is going to host a game with actual player accounts, making an administrator manually reset every forgotten password is a bad long-term answer.

The design raised questions I needed to settle: which email addresses could receive recovery links, whether administrator accounts should be eligible, what could happen before a new account confirmed its address, and how the links would expire. I answered the questions and had the work broken into separate, tested parts. Recovery and verification now depend on the host actually proving that account mail works. If account mail is off, the limitation is still there and the administrator remains the fallback.

That decision added three more build tasks before rc.1. I would rather do the work before a release than leave hosts to deal with a problem I already knew was there.

Passing Every Test Wasn't the Finish Line

I set a hard verification standard for this work. The modern-core checks run across PHP 8.4 with MariaDB 11.4 and PHP 8.5 with MySQL 8.4, with fourteen automated jobs in the release-stage workflow. The historical baseline also has its own integrity check. I didn't accept a change because most of the jobs passed. The required checks had to pass.

When a new test was supposed to prove that a defect had been fixed, the useful pattern was to make it fail against the earlier code and pass after the correction. Otherwise it was too easy to end up with a test that looked reassuring but hadn't actually proved the behavior we cared about.

The tests caught problems in the tests themselves, too. One interface test used a PHP 8.5 feature and failed on PHP 8.4. The answer wasn't to ignore the older supported version. The test was corrected, and the project added a rule requiring local verification on both PHP versions when tests changed. A failed run stayed in the record instead of being erased from the story.

The same standard applied to the work players never see. Sessions, password handling, state-changing forms, old executable surfaces, internal file access, and security headers all needed actual rules and tests. Those details won't make anyone nostalgic for a forest fight, but they matter if the game is going to run on a server connected to the Internet.

None of that means the game has been independently security-audited. It hasn't. The first release candidate is explicitly a test build, not a declaration that opening a public server to strangers is risk-free. I don't want a green test suite turned into a claim it hasn't earned.

The First Real Install Exposed What the Tests Missed

On November 13, I authorized the cut of 1.0.0-rc.1. The version was pinned, the required checks passed, and the release was published on GitHub as a pre-release with a ZIP and its SHA-256 checksum. The coding session couldn't push the release tag from its environment, so the work produced a controlled GitHub Actions release workflow. I triggered that workflow myself.

The workflow checked the release, created the tag, built the package reproducibly, and verified that the download matched the expected file. On paper, that is the kind of release process I want. No quietly replacing a ZIP, no guessing which copy is the real one, and no announcing a release because a folder happens to exist.

Then I put the candidate on my own VPS and played it. The game reached the village. I could get into a forest fight. For the first time, this wasn't just a repository, a test environment, or another development report. I was using the game on a real server.

And the ZIP still had a problem.

The package did not include the modern installation instructions. The only README inside was the historical 1.1.2 file, with steps for the wrong installation method. The full host guide existed in the repository, but it hadn't traveled with the download. Other checks from that server-testing pass found game messages pointing to documentation paths that weren't shipped and a notice pointing to a third-party-license document that wasn't in the package.

The code tests had not caught that because the problem was the handoff to the person installing the software. Those are two different things. The server can run correctly while the downloadable package fails the operator who needs to set it up.

The corrections were made in later repository work: the next package layout separates the files to upload from the installation guide, release notes, licensing material, and sample server rules. Documentation links were corrected, and the package contents became part of the checks. The published rc.1 asset was not silently replaced with a different ZIP under the same release name.

I Had to Decide What This Project Was Actually Worth

There is another part of Resurrection that has nothing to do with PHP. I loved this game years ago. Bringing it forward has been enjoyable, but nostalgia doesn't make a project commercially valuable, and it doesn't create an audience that might not be there.

The original game carries a noncommercial license, Creative Commons Attribution-NonCommercial-ShareAlike 2.0, along with its own historical license terms. Resurrection is built on that source, so I cannot honestly treat this version as a commercial product that I own outright. The original authors and contributors retain their credits. That isn't a detail I get to wish away because I've put work into the modernization.

I knew the licensing position from the beginning. It landed differently once I could see a real release and play the game on my own server. I had to decide whether I wanted to keep spending time on a project that wasn't going to become a business.

I considered stopping. Then I made a different decision: finish it, but give finishing an actual definition.

The remaining plan is limited. Correct the problems found in the first server test, finish the known release issues, cut another candidate, test that candidate on a real server, and then decide whether 1.0.0 is ready. After the stable release, the plan is bug fixes, not an endless stream of new artwork, new systems, and new reasons to keep the project open.

There is a difference between following something through and letting it consume everything else I could be building. Resurrection deserves a proper finish. It doesn't need to become a permanent obligation just because I am capable of adding more to it.

What the First Release Candidate Proved

Resurrection wasn't finished when rc.1 passed its tests. The first installation proved that. But I knew what had gone wrong, and the next build had a specific problem to fix.

I still want to finish Resurrection 1.0.0. After that, I want to put this kind of effort into something I own outright. I can appreciate the old game and the people who made it without treating this project as something I have to keep expanding forever.

The tests matter. The release matters. But the part that finally counts is what happens when the work leaves the development environment and somebody tries to use it. This time, that somebody was me.

New Here?

Why I Build This Way