Then the tools available to me changed.

I had been following the news about AI-driven attempts to recreate familiar creative applications. Projects such as ArtCraft’s PhotoCraft and VectorCraft made the possibility feel much more concrete. Here were people asking coding models to undertake substantial applications, rather than just generate a function or explain an error.

I was recovering from a medical procedure and was not spending much time at the computer. That old repository came back to mind. I looked at the network graph of forks and did not see the kind of active modernization I had hoped to find. Over the next few days, I wondered what would happen if I finally asked an AI to try.

I cloned my fork, opened it in Visual Studio Code, and started talking with Anthropic’s Claude Opus 5.5. I asked for a web application that could design games, read and save the original formats, play the old games, and export new ones for offline use. Preserving the original source became another explicit boundary as the work continued.

Over the following week, the project became Game-Maker: Sandbox Edition.

This was an AI-driven project with multiple sub-agents running in parallel. Claude and its agents did much of the implementation; I directed the work, supplied personal material, played the results, and kept asking for changes.

The story is that cycle: ask, build, play, investigate, and ask again, with several parts moving at once.

Three commitments guided the work: keep the original game formats and gameplay rules, let people take the engine and their files away, and credit the original authors and other contributors. The new features would make games easier to build, inspect, and share.

The new development starts on Tuesday, October 20, 2026. The weekday and time landmarks below use Eastern Daylight Time. Some mark my requests and others mark commits; several workstreams were moving at once. The story follows the merged version into the next Tuesday, then the pending voice-tour and EPUB work.

Tuesday at 2:19 a.m. The first request already had an exit door

My opening message was more specific than “put this old program on the web.” I wanted to design games and save them in the same format. I wanted to read original projects and run the games people had already compiled. I wanted a created game to become an offline web application that could be installed on a desktop.

I also named the tools: the Web Audio API, HTML canvas, Vite, TypeScript, and a GitHub action to publish the result. Those were practical choices for the application I wanted to try. The important condition was what happened to the game data after the browser had opened it.

That condition stayed with the project through all the changes that followed. A game should be able to come in from the old world and leave again. I was not asking to import its pictures into a new engine and call the resemblance a port.

The first visible reply was that Claude would explore the repository and its formats. Within minutes, its reports were about concrete things in the old collection: files cut off at 16,384 bytes, differences between versions of the game definition, the sizes of stored structures, and which file occupied each scene slot. It was beginning with the evidence available in the source and disks.

At 3:23 a.m., I asked the question in the terms that mattered to me: “can i save as the old game files so that anyone on dosbox can run them?”

Four minutes later, I asked for an export that included the executable under the proper name. The game could not leave as an unexplained pile of resources. A person receiving it needed the player as well.

At 3:35 a.m., I was looking at a shareware readme. That raised a different concern. Some of these games belonged to other authors, with registration instructions and conditions of their own. I asked how they would be made available without treating their presence on the CD as permission to repackage everything indiscriminately.

That conversation began well before the elaborate credits page. The difference between the program, its sample games, and somebody else’s shareware was already affecting the design.

Then, at 3:46 a.m., I described a desk.

There would be a container of 3½-inch disks to flip through. The PC would have a DOS interface. A CD beside the machine could launch Game-Maker. A mock BBS would let someone download shareware and read its notices. The visitor could swap between that nostalgic computer and the modern web editor. A paper catalog might sit alongside it.

The same message also reported bugs: Escape was leaving the inventory and then leaving the game, and tornadoes seemed to spin too quickly. I wondered whether timing intended for a 286 was being carried into a much faster environment. Much of the conversation was based on my memory of technology in the day such as the reason why PC’s had a turbo button.

That mixture became typical. I could be imagining a room while also pointing at a key event that survived one screen too many. The port needed both kinds of attention. One supplied a reason to explore; the other determined whether the game was usable once somebody got there.

The desk was therefore part of the project’s first morning, alongside compatibility and export. Its later detail grew considerably, but the basic idea was already there: make the old software accessible, and give people a way to experience the setting in which it had mattered to me.

One conversation with several agents working at once

The easiest way to misread this repository is to imagine me writing each part in the order the commits appear.

An agent in this setting is another working context that can examine material, use tools, and pursue an assigned part of a larger job. Several can run at once. Their results then have to fit back into the same application.

That made the scope possible. A game, a format reader, and a manual chapter are all substantial jobs, but they do not always need to be worked on one after another. Once enough of the shared foundation exists, different pieces can develop concurrently.

The overlap in the timestamps reflects that. It does not mean a completed magazine sprang into existence in the minute between two other commits. It means part of one workstream was ready to land while other workstreams were continuing.

The parallel work could continue while I stepped away. In one stretch, I went for a nap while agents worked on Virus Blaster’s expansion and Snowbound’s longer sled run. When I returned, the conversation had reports of new flight sections, a run about three times as long, revised maps, and updated manuals and walkthroughs. There was a new set of things for me to try.

The AI did much of the detailed work required to turn those requests into functioning software. It read the old source, wrote the TypeScript implementation, built generators for game data, created assets, added tests, and revised the result. That contribution belongs near the beginning of the story because it shaped the whole process.

That shared project also needed coordination. One agent’s rewrite of the Level Maps data had put back an outdated entry for In The Year 2000!; the coordinating agent reported restoring it. Separate assignments could still meet in the same file. The repository’s instructions, checks, and source maps helped keep track of what each part was supposed to change.

The reports were a handoff into another round of playtesting. I could approve one part, notice a problem in another, or ask for a technique from one game to be tried somewhere else. Each result made the next request more specific.

It was equally important to have ways to inspect progress beyond a confident response. Files could be read back. Generated disks could be rebuilt. Routes could run through the engine. Exports could be tried in DOS. A page of text could be opened and checked for fit.

Those checks gave the agents something concrete to work toward. They also gave me a better way to say what was wrong. “This does not work” becomes more useful when accompanied by the scene, the action, and the result.

The conversation repeatedly returned to what I could see and hear. A successful check was useful, but so was noticing that a course map left something out or that a character’s voice did not suit them. Those observations gave the next agent a problem to investigate.

Keeping the work moving without losing the thread

“Commit small, commit often” became one of my recurring instructions. Sometimes it arrived with a count of unstaged files: 44, 28, 37. Those messages were an attempt to keep an unusually fast-moving project understandable while several parts of it changed.

A conversation can move from a music editor to a dog animation to a file-format problem in a few minutes. The repository needs smaller, more durable records of what actually changed. I wanted work committed as it reached a sensible stopping point, rather than accumulating in one large, difficult-to-explain pile.

We also used files for the conversation around the work. There was a to-do list, a questions file, and a place to move completed items. When I had other things to do, I could tell the agent to keep going, write down questions, and use reasonable defaults until I returned.

That arrangement needed maintenance too. On the first night, I said the questions file felt flooded and I could no longer tell which questions remained. A place to write things down only helps if someone can still find the current state in it.

By Friday afternoon I was also thinking about interruptions from the model’s usage limit. I asked that agents leave instructions that would make their jobs easy to restart at 7 PM while I was at a meeting that would start at the same time. The work needed to survive the end of a particular run, even when the application itself had no natural stopping point.

There were more ordinary interruptions. On the first evening I told the agent to stop refreshing the browser after every change because I could not do anything. With React, a shadow DOM would update only the parts of a page that changed, but this was much simpler to reduce the overhead of dependencies. Later, I repeatedly announced when I had stopped the development server or was about to start it again.

Those exchanges sound mundane beside the scale of the result, but they describe what collaboration actually felt like. The agent was working in an environment I was also using. A change that refreshed the page could interrupt the very play session that would tell us what needed changing.

The workflow became a series of handoffs: a list of things for the agent to pursue while I was away, a report when I returned, and another round of playing and questions. Parallelism increased how much could happen during a handoff. Keeping the work legible determined how useful that progress was when I sat down again.

Giving the agents my own history to work with

I gave the agent permission to browse my entire blog, which contains almost 4,000 posts over a few decades. I pointed it toward a few useful pages, including my career experience, and let it explore from there.

That gave the project much more personal material than I could have supplied in an opening prompt. The blog contains years of things I have made, researched, tried, and written about. The agent could draw connections among those projects and bring some of them into the games.

The access was a starting point for conversation. I still had to explain my history, clarify details, and correct interpretations. A written account can supply a fact without conveying everything I associate with it.

The result was that much of me and my projects found its way throughout the collection. The snow-shoveling story is the most direct connection to buying Game-Maker, but it is one thread among many. The dogs, the car, my work, and other projects gave the games a personal world to draw from.

A photograph still needed an explanation

I also supplied photos and asked for them to be interpreted so that they looked as though they belonged in the games. Pasting a modern photograph into every scene would not accomplish the same thing as using it to understand a character, a vehicle, or a place.

Reviewing the output quickly showed why the conversation had to continue. One CitiCar looked like a station wagon. Another had wheels facing the wrong way. Gwinn’s pink collar made her tongue look like a ball. Her name was missing its final “n”. In a scene involving a rubber chicken, the leash appeared to hang in the air.

These were concrete corrections to generated art. They also exposed how easily a recognizable subject can be reduced to a few loose associations: red car, corgi, clown, chicken. I wanted the details that made them these particular subjects.

The history needed correction as well. In the turbo button magazine interview, I clarified which school I had attended before my family moved and which one came afterward. The IBM PS/2 was my brother’s 286, purchased with Mom’s help; I often used it. The 486 with a CD-ROM drive came later as a high school graduation gift from my parents.

I described Fort Ashby’s one-room library, the ceramic shop, the volunteer fire department, model rockets at the fairgrounds, and friends who had computers. These details gave the agent a better understanding of the life around the snow-shoveling story.

There was also a boundary between background information and something that belonged in a game. When Snowbound explained that a courier walked to every door delivering mail, I corrected it: people had post-office boxes. More importantly, the line sounded strange because the information had been offered as context, not as a sentence the game needed to tell its player.

Personalization meant deciding what to leave out as well as what to include. The agent could gather material and make connections. I still had to recognize when the connection was wrong, awkward, or simply too literal.

Tuesday at 2:25 a.m. Getting the bytes right

At 2:25 a.m., the Vite and TypeScript scaffold and GitHub Pages setup established the browser project. A little-endian reader and writer, matching Borland’s 16-bit layouts, followed at 2:29 a.m. By 2:30 a.m., round-trip tests were checking the readers and writers against CD sample files.

Before a browser could play anything, it had to understand the disks.

Game-Maker stores a game across several kinds of files. A map describes a world, but the blocks it refers to come from somewhere else. Characters have their own data. Monsters have movement and behavior settings. Palettes determine what the pictures look like. The game definition ties the pieces together.

Reading enough of a file to put a picture on the screen would have been an encouraging demonstration. Writing those files back correctly was a stronger requirement. Early tests checked round trips against samples from the CD.

The work also reached beyond the most obvious game data. GIF images, FLI and FLC animations, Creative voice files, FM music, and recorded demonstrations all had to be understood. These formats carry much of a game’s personality: the title screen, the introduction, the sound of a pickup, the music playing behind a level.

A file format can hide a surprising amount of historical context. The size of a number depends on the compiler and machine it was written for. An array may include unused entries that still occupy space. A filename may be expected to behave case-insensitively. Modern code has to make those expectations explicit.

The palette is a particularly visible example. A stored pixel value identifies a color in a table. If the table is wrong, the geometry can be perfectly intact while every face, wall, and patch of sky looks wrong. Moving the picture into a modern image format too early could conceal the relationship the original game relies on.

Keeping the readers and writers close to the old layouts gives the rest of the project a common language. An editor, a generated game, a map booklet, and an export can all operate on the same underlying resources. That pays off repeatedly later in the week, when material that looks unrelated turns out to need exactly the same information.

Tuesday at 2:42 a.m. Turning those files into a running game

Understanding the files was only the beginning. The next problem was reproducing what happened when the original player used them.

The early history moves through the engine’s practical machinery: the character’s state, movement and collisions, touching blocks, monster behavior, births and deaths, and the transitions between scenes.

The display and timing support arrived alongside the engine work. A 320-by-200 Mode 13h canvas lands at 2:42 a.m., a case-insensitive file store at 2:43 a.m., and asynchronous keyboard waits and palette fades at 2:44 a.m. These supplied the screen, DOS-style filename handling, and transitions the player needed.

These are easy details to underestimate. A game can look approximately right while responding differently enough to break a jump, a doorway, or a sequence its author depended on.

Sandbox Edition is a port of the program into TypeScript. It does not run DOS or x86 machine code inside the browser. The desk’s computer is a simulation, while parts of the display and sound hardware are modeled to reproduce the experience.

It also meant making decisions about old quirks. When games depend on a particular behavior, cleaning it up can change the game. The source was useful precisely because it provided an answer more specific than “this seems like how it ought to work.”

By the time an embeddable player and browser storage appeared, the project had crossed its first major threshold: old data could become an interactive game in a modern browser.

The browser changes the mechanics of those jobs. An old program can wait for a key in a way that would make a web page stop responding. Audio has its own timing and startup requirements. The implementation needs to fit the browser while preserving the player’s experience of what happens next.

Music adds another layer. A recording can reproduce one performance, but the original files describe instruments and events that the sound system interprets. The port includes an OPL2 implementation and the sequencing work needed to turn those resources into FM sound. The PC speaker path has its own character and remains a meaningful choice.

A useful preservation question emerged from this work: what must stay the same for an existing game to keep being itself? Sometimes the answer is obvious, such as a collision rule. Sometimes it is a fade, a brief wait, or the order in which a screen and its colors arrive. Those small behaviors accumulate into the difference between recognizing a picture and recognizing a program.

Tuesday at 3:07 a.m. Making it a construction kit again

The editor home page lands at 3:07 a.m. Tuesday, followed at 3:11 a.m. by map painting, monsters, and link markers. The purpose was to make Game-Maker easier to build with while preserving the files and rules its games already used.

That distinction guided the whole project. The new features belong mainly to authoring, inspection, presentation, and distribution. A better map editor, a checker, or an AI assistant can help make a game without requiring a new kind of game file or new gameplay instructions that only this website understands.

I wanted to move between the original DOS Game-Maker tools and the modern web editor while working on the same game files. A map should remain a map, a character should remain a character, and the game definition should still connect those resources in the way the original software expects.

Inside Sandbox Edition, the recreated DOS designers and the contemporary editors work on the project’s underlying files. Switching interfaces changes how I edit them. It does not require rebuilding the game as a separate modern edition.

The same compatibility connects the browser to the actual original software. I can export the files, work with them in DOS Game-Maker, and bring them back. The original source remains the reference for what those resources mean.

That is why the modern editors cover maps, blocks, monsters, the player character, palettes, sounds, music, animations, and scene connections. They expose the existing construction kit more conveniently. Previews and link markers make relationships easier to see; browser storage makes it easier to keep experimenting.

Copying a supplied game is part of that learning process. Someone can inspect a working example, change a block, and play the result in a project of their own.

Editor conveniences that DOS does not understand can live separately in a companion record. The game’s original-format resources remain usable by the older tools. Project backups can carry the companion information so the modern editor can recover its extra context later.

Making an easier editor without inventing a different game

By Wednesday at 11:52 a.m., I had stated the boundary plainly: we could not change how the original Game-Maker ran its files or saved them, but a separate JSON file could hold additional information for the modern tools.

That left considerable room to improve the experience of building. On Friday morning I asked about painting paths and buildings by defining their corners and how their pieces fit together. A person should not have to reconstruct the same arrangement block by block whenever they wanted another stretch of road or another building.

The useful new feature was the authoring operation. Its output could still be an ordinary arrangement of the original blocks.

Small decisions about copying mattered too. I kept editing a supplied Sandbox game and accidentally creating another copy instead of returning to the one I already had. I asked for existing copies to be shown before a new one was created. Later, I asked to look inside supplied games without copying them immediately, and to offer a copy when an action would actually modify something.

Those requests came from using the editor rather than planning a feature list. The application knew the difference between a supplied game and a personal copy, but it still had to explain that distinction at the moment I needed it.

The same was true of navigation. I wanted Desk, DOS, and Web in a consistent place. Switching views should not make the controls jump from one side of the page to the other. Eventually I also asked for an explicit Games button because clicking the product name was not an obvious route back to the catalog.

These changes made the construction kit easier to approach without changing the language its games spoke.

Tuesday at 4:00 a.m. Turning Game-Maker itself into a game

The desk’s installed directory listing and help screens land at 4:00 a.m., followed by a floppy disk model at 4:02 a.m. This work was already running alongside the engine and editors.

As development continued, the space around the program became increasingly important.

There is a difference between clicking a game in a list and taking it off a shelf. There is a difference between instantly opening a download and watching a modem connection deliver it. Both get you to a game, but they tell different stories about how that game reached you.

The room grew around those differences.

The computer has a power button and a boot sequence. There are disks and boxes. A wall phone shares the modem’s line. The window changes with the time of day. The sound settings and computer controls are things you can encounter in the room.

The monitor has a subtle curve to its picture, like slightly bubbled CRT glass. It is easy to miss on a still screen. Once I start walking through a level, the scrolling scenery makes the curvature more noticeable: the picture seems to pass across the face of the tube. That small effect helps the desk feel like a computer I am playing through, with a physical screen in front of me.

The BBS work gave that setting somewhere to go.

A bulletin board was more than a file picker with slower transfer speeds. It had a SysOp, messages, regular callers, rules, and its own personality. The simulated boards developed file areas, bulletins, conversation, and a door game played a move per call.

The delays matter because they change the experience of discovery. You choose a file, wait for it, and pay attention to the place it came from.

The little inconveniences also need judgment. A modem speed setting can recreate the wait without forcing everyone to experience the slowest connection. The contemporary web interface provides a quicker route when someone wants to play or edit immediately. The desk is an experience a visitor can choose.

By Wednesday at 9:47 a.m., the history explicitly includes the shared-phone behavior: picking up the phone can drop a call, and leaving it off the hook prevents a new one. It is a small piece of simulation with a very direct explanation. Anyone who used a household modem will understand what just happened.

Wednesday morning The room acquired a family

The room’s details came from memory and invention together. It combined Fort Ashby and Pittsburgh rather than reconstructing one actual room at one exact date.

On Wednesday at 9:30 a.m., I asked for a note beneath the phone: Mom and Dad’s work numbers, Dad’s pager, Grandma, and the babysitter. It should tell a child not to call unless there was an emergency and not to answer the door for strangers.

That was the latchkey atmosphere I remembered. A phone number on a scrap of paper could say something about the household before anybody in a game delivered a line of dialogue.

The wording mattered. I changed an instruction to “punch in the house phone number.” I asked for a Mr. Yuk sticker and a red 911 sticker behind the handset. Then the phone became interactive: busy signals, an answering machine, unanswered calls, and numbers gathered from the notes and BBSes.

The agent had made Dad somebody in accounts payable. I corrected that detail because it did not fit the pager I was imagining. Dad should be in maintenance and often off site. A little piece of characterization had to support the object we had put on the desk.

When the babysitter was named Jenny, the number almost chose itself. The familiar song made it something a visitor might think to try. Later, when a revision weakened the joke, I pointed out that the number had been intentional.

Other objects arrived in the same conversational way. My sister had owned an oversized wristwatch wall clock. There was room for one beside the desk. A disk box needed the depth of rows of disks, a shadow between neighboring colors, and the raised lettering of an embossed label.

The generated room could approximate a floppy drive or a keyboard, but the first approximations did not always resemble the things I remembered. A keyboard looked like a grid drawn on a flat surface. The CD drive did not look like a tray. Its eject button belonged below it. The floppy disks needed the right holes and more convincing labels.

That kind of feedback was about recognition. These were objects people had handled. A slightly wrong arrangement of familiar parts could be more distracting than a wholly invented gadget.

The desk also connected its objects. Picking up the phone could spoil the modem call. A number on the note could produce a response. The clock and lighting changed the room. A game’s poster could take the place of another poster on the wall.

By Friday, I was explicitly asking for achievements for exploring that world as well as for making and playing games. Dialing a BBS, trying a utility, and watching a walkthrough could all become things a visitor had done.

That was the point where the framing idea grew into a game of its own. The computer was still the place to play, but the room around it had acquired actions, consequences, and a small history for the visitor to build.

The achievement system gave that exploration a sense of progress. It recognized things people made, played, and found, encouraging them to try more of the construction kit and its surroundings. Achievements could be viewed on the modern web page or through ACHIEVE.EXE on the desk’s computer.

The desk also had two score trophies, for best scores and total score, that advanced from plastic through bronze, silver, and gold. Progress became another object in the room, alongside the boxes and disks.

Together, the desk and achievements essentially turned Game-Maker itself into a game. The room supplied a setting to explore; the achievements supplied goals and recognition. Calling a BBS, discovering a feature, making something, and playing the games all became parts of that larger experience.

That gave the nostalgia something to do. A visitor could spend time inhabiting this version of a 1990s computer desk, learning how its pieces connected and finding reasons to come back. The construction kit was still there to make games with, but using and exploring it had become playful too.

Tuesday at 7:06 a.m. Building games to find the edges

The Sandbox library grew to include different kinds of experiments: adventures, driving, action, visual tricks, and games built around personal stories.

Snowbound: The $89 Shovel brings the project back to its beginning. It turns the winter I spent earning money for Game-Maker into a game made with Game-Maker. The player clears driveways, travels through a version of the neighborhood, and tries to get the money to the mall before the price changes.

The new games were built in code, generating actual Game-Maker data. That made it possible to rebuild them consistently and check the results. It also kept the work tied to the same formats the original program understood.

Claude and its agents wrote and built the new games: code, pictures, music, sound effects, and text, as the repository’s credits record. I supplied direction, personal material, playtesting, and continuing feedback. The recordings, photographs, and contributions of other tools have their own credits.

The generated game builders are a useful illustration of that division. I could ask for a particular scene or change in behavior, and the agents could revise the code that creates the disk. I could then play the result. The next request came from what I saw and heard, rather than from assuming a successful build had finished the design.

As the collection grew, each game supplied another kind of pressure. A scene with many moving actors tests something different from a carefully timed platform jump. An animated introduction exercises different code from a long map. A game with several connected locations asks whether the scene structure holds together.

The games acquired identities beyond their mechanics, too. Characters returned in different settings. The cast page gave those recurring sprites a place to meet the visitor. Box art and manuals made each title feel like a separate release rather than another engine test.

That balance became a recurring challenge. A demonstration should show what the tool can do, but a game needs its own reasons to continue. The later changes to level order, routes, timing, and version numbers show the games receiving attention as games. Their job was no longer satisfied by proving that the port could draw them.

Maximus was built to find the limits

I wanted more than a small demonstration that the port could load a map. I wanted the AI to build something substantial enough to encounter the limits in the original formats and player, document them, and make those limits part of the design.

By 7:39 a.m. Tuesday, a commit assembles the game’s hundred scenes. At 8:28 a.m., the history includes its LIMITS.TXT file and manual. The limits document explains which boundaries were reached, which were approached, and which were deliberately left alone.

The distinction is important. A hundred scenes was a design choice, not the engine’s absolute scene limit. The documented allocation permits 231 scene records; Maximus uses 100. Its subtitle also does not mean there are a hundred separate planets. The project eventually corrected its box copy to distinguish 88 worlds from the larger scene count, which includes charts and other parts of the game.

Other boundaries are reached directly. Its maps use the 100-by-100-block dimensions. A sector chart uses all 20 available links. The Maelstrom uses every one of the 200 placed-monster slots.

That last limit becomes a design consequence. With all those slots occupied, there is no room to create a shot. In the storm, the weapons jam. A resource constraint becomes something the player encounters inside the fiction.

The world design reflects other behaviors, too. The maps wrap, so a planet can behave like a little globe. The way scenes reload affects how collected star-shards are represented. Shared animation clocks affect what can blink, change, or restock independently.

These details turn Maximus into an explanation of the engine as well as a game. The limits are visible in the way its universe works.

Later in the week, the magazine gained a feature explaining that experiment. The story therefore made a round trip of its own: a request to test the engine became a generated game, the game exposed constraints, and the findings became something a reader could learn from.

Teddy’s adventures kept getting bigger

Teddy’s Little Big Adventure started with my corgi as the lead. I thought it would be funny to follow it with Teddy’s Little Bigger Adventure. The name was a sequel joke that practically suggested itself.

Then I thought about the shareware trilogies I remembered: a first game could introduce the world and encourage people to purchase the other installments. That familiar three-part structure gave the joke somewhere to go. Teddy’s Little Biggest Adventure became the grand finale.

The progression from Big to Bigger to Biggest gave Teddy a small series of his own and brought another piece of the period’s software culture into the collection.

The transcript gives the joke a useful timescale. Just after midnight Thursday, I proposed Little Bigger as a sequel while also asking for other kinds of games. On Friday at 10:30 p.m., I asked for Little Biggest as the finale, with more to do and opportunities to play as Doc Leo and Gwinn and drive THE CHEZ.

A grand title did not spare it from ordinary playtesting. On Saturday night I got outside in Teddy3, realized I needed the keys, and could not get back in. My message ended with “sigh”.

That moment belongs beside the trilogy joke. The names made a promise of expansion and adventure. The game still had to let somebody recover from a mistake without trapping them outside the place that held the necessary item.

A later technique would give Teddy another kind of expansion: a dream run with moving background bands. The series grew through those specific discoveries and corrections, rather than simply by making each sequel’s map larger.

Eggs and tin hearts connected the games

I also worked Easter eggs into the games. Finding enough of them in the Sandbox collection opens access to a secret game. The discoveries give players a reason to explore across the collection and connect games that otherwise have their own stories.

Tin hearts follow a similar idea across both the Sandbox and Bard of Bizarre games. They have a personal connection: I had my pacemaker replaced at the beginning of October, and I wanted to work that part of my life into the project.

I also wanted to leave a little hidden game about my grandmother, tucked inside another secret game. These connections let me put something personal into the collection and leave it for a player to come across.

Alongside the achievements and trophies, those discoveries gave the wider project another layer of play. Finishing an individual game could be one goal; exploring what connected the games could be another.

Wednesday at 11:07 p.m. Making the games watchable

A walkthrough is useful to someone who is stuck, but it also serves someone who is simply curious. Not everybody wants to begin by learning the controls and playing an entire game. Sometimes they want to see what the construction kit made possible.

The walkthrough player appears in the history at 11:07 p.m. Wednesday. It can play a whole game, change speed, jump between chapters, and export an MP4. It also prepares a YouTube title and description with chapter markers. On Thursday afternoon, those publishing controls move closer to the screen, making the intended workflow easier to follow.

I posted many of the games’ walkthroughs to YouTube, along with a tour of the software and a follow-up showing more features. Those videos give the project another entrance. Someone can encounter a game outside the site, watch part of it, and decide whether to play it or look inside its files.

A whole-game recording shows things that a trailer or screenshot cannot: how scenes connect, how the difficulty changes, how the music develops, and whether the ending delivers on the beginning. It also preserves a performance of a particular version.

That last detail matters as the games keep changing. A recording can accurately show an earlier release and still mislead a player following a newer one. The pending branch’s Library work therefore associates walkthrough videos with games and keeps a stale entry out of view until its replacement is identified.

The Library’s first video shelf lands at 10:16 p.m. Sunday, bringing the two site tours into the collection with descriptions, lengths, and locally stored thumbnail pictures. The YouTube player loads when the visitor chooses to play.

The videos themselves have already been published. The pending branch expands how the Library presents the individual game walkthroughs, putting them beside the relevant game and under Videos, with their descriptions and chapters.

This is another place where different forms of preservation complement each other. The original files preserve the material a game uses. A running port preserves interaction. A recording preserves a particular journey through it and gives people a low-effort way to discover it.

The bot had to learn how a person might play

The early demonstrations were not always good advertisements for the games. On Wednesday afternoon I listed examples: a hand that never selected a character, a character unable to clear a ledge, a route that seemed confused, and a demonstration that reached a boss but did not begin the fight.

That exposed a problem beyond recording a video. A demo needs to make a game understandable. Remaining on a selection screen or repeating an ineffective action can make a working game look broken.

By Thursday evening I was criticizing different details. The bots passed visible treasure and power-ups. In Quest for the Round Tuit, a bot would attack most of a boss, leave, return, and struggle to finish the remaining part.

Those were observations about believability. A person who sees reachable treasure is likely to collect it. An automated route that ignores it might technically reach the exit while showing a strangely unconvincing performance.

The walkthrough system gradually became a place where different questions met: can the route succeed, does it show the important parts, does it wait for a spoken sound to finish, and is the result worth watching?

It also created a route outward. I wanted the full game, beginning with its introduction, in an MP4 I could post to YouTube. I wanted the title, description, and chapter markers prepared beside it. On Wednesday night, the recording controls were still producing problems such as a zero-byte MP4; the request was considerably ahead of the finished workflow.

By the final Tuesday evening I was asking whether imported games could use the same system. I did not want a fixed set of recordings available only for our own titles. Someone should be able to import another game and attempt a walkthrough of it.

I also wanted the person’s own play to be usable alongside the bot’s. An automated player might complete some levels and fail others. A human could record the difficult part. The useful unit was a whole-game walkthrough assembled from performances that actually worked.

That last request was still being developed on the pending branch. It followed naturally from the earlier failures: once the system could show how a game was played, it should not require pretending that the bot was the best player for every scene.

Thursday at 1:21 p.m. Giving the BBS its own games

That decision made the boards useful. A visitor could discover an unfamiliar title, read its description, download it, and find out what somebody had uploaded.

It also created a design tension I kept returning to. The experience of finding a game on a BBS is worthwhile, but the game still needs to be discoverable by someone using the modern site.

The current version gives the Bizarre games their own tab on the home page. Their BBS identity remains part of the desk experience.

The first Bizarre catalog entry, for Third Goat from the Left, lands at 1:21 p.m. Thursday. Naming its uploader and The Sofa BBS gave the game a route into the collection and a place in its fictional software scene.

Adapting a song into a game also requires interpretation. A lyric can make a joke in a sentence. A game has to give the player something to do with that joke: navigate a room, react to a hazard, search for an object, or discover what changes after an action. The setting has to carry some of the humor before anyone explains it.

The music creates a similar translation problem. A recorded song includes a performance and a sound that an FM arrangement cannot simply inherit. Instruments, rhythms, and recognizable musical ideas have to fit the capabilities of the old-style sound system.

The original recordings and any included clips retain their own attribution and terms. The project’s credits distinguish those assets from the generated game material. Keeping that distinction visible is part of presenting the collection honestly.

These games also widened the project’s tone. A preservation project can become so concerned with demonstrating accuracy that it forgets how odd personal software could be. The BBS setting made room for that variety: a familiar construction kit, used by another fictional author, producing something decidedly different from the boxes on the Sandbox shelf.

A different collection needed its own direction

The Bizarre games did not begin as a request to manufacture another large catalog. I had particular songs and monologues that I wanted adapted, and I told the agent not to add extra games on its own.

Third Goat from the Left was an early example. The comic premise already existed in a song. I supplied the material and suggested some of the things that made goats funny: screaming, fainting, and behaving unpredictably. Later requests brought in a mustard seed, a camel, domestic absurdities, and other subjects from the recordings.

When the collection reached four games, it could have its own Bizarre category. That was an organizational decision as well as a visual one. These games had a recognizable source and tone, and I wanted a visitor to understand why they belonged together.

The Shakespear in Sweatpants monologues brought another personal setting. I described the Beehive in Oakland, Pittsburgh: the castle-like front, the theater beyond the counter with sofas, tables with lamps that reminded me of grandmas house, and the upstairs space where there could be a stage. The better-known South Side location was not the one I meant. I supplied reference photographs so that another plausible coffeehouse would not quietly replace the place in my memory. I had it transcribe all of my monologues and kept talking about things I remembered about the beehive. I could have mentioned climbing out the windows to sit on the roof to smoke with my friends, or a time I helped move some furniture into the large attic above the second floor that seemed like a scene out of flowers in the attic, or the spiral stair case in the front “tower”, but I didn’t have much substance to work with. The monologues and general theme of a coffee house movie theater with its classic yellow mugs would have to suffice.

That was part of directing these games, alongside the sillier requests. An agent adapting absurd material still needed to know which jokes suited me and which ones did not.

The source material also had a more complicated credit trail than “music by Lewis.” I explained how lyrics had been shaped with prompts, which tools had generated recordings or images, and which pictures were my own. As more games arrived, the credits needed a form that could distinguish their contributions without becoming unreadable.

I also made clear that people should be able to edit the Bizarre games. Their identity as a different collection did not put them outside the construction kit. A visitor could discover one through the BBS fiction and then examine how it worked in the editor.

That combination made the collection useful to the larger project. It widened the kinds of stories and sounds being attempted while keeping the same old resource formats underneath.

Thursday at 10:01 p.m. Letting the games leave the website

One game and its engine in one static page

A game can be downloaded as a single HTML file containing the browser play engine and the game’s files. The music support, styles, and runtime come with it.

Someone can save that page on their own computer and open it directly from the file system. They can also put the same file on another website. Playing it does not require my site to supply the engine or a server to run game code. The same file can be exported back into the Sandbox Edition of RDS Game-Maker running on another website as well.

That is a small and useful distribution object: one page a person can keep, copy, or host. It also gives an author a way to share a finished game without asking the recipient to learn the editor or recreate the development environment.

A web player beside an existing game collection

The separate collection player serves a different person: someone who already has folders of old Game-Maker games and wants to make them playable online.

They can put the web player beside those folders on a host that serves static files. An optional games.json lists the collection; links can also open an individual game. The player reads the game definition and follows its references to the maps, pictures, sounds, and other resources.

The host does not need a database or an application backend running Game-Maker. It serves the player and the existing files. The visitor’s browser does the playing.

This player needs a web server because it fetches neighboring files. That is different from the single-game export, which already has its resources inside the page and can open directly from disk.

The distinction preserves a useful choice. An author can package one game into one file. A collector can keep an existing folder collection and add a shared player instead of converting every game into its own package.

The web-player documentation describes both the layout and the optional catalog.

Connecting a library someone already has

There is also a route for an existing game-library website to send a game to Sandbox Edition.

A link can identify a hosted game where the browser is allowed to fetch it. Alternatively, the library’s page can pass the actual file data to the player through the browser’s messaging interface. That supports collections whose files are already available to their own page, including locally selected or generated data.

The visitor confirms the handoff. The game can then open to play or edit through the web interface, the desk, or the recreated DOS environment. The integration documentation includes the protocol and a working sender example.

These features let the project support other people’s collections without requiring those collections to become part of mine.

Windows, Mac, and Linux downloads add further options. Their shells wrap the browser-based player and game data for the relevant platform; they are not separate rewrites with different game rules.

All of these paths follow the same aim: preserve the old game data, make it accessible, and give the author or collector control over where it lives.

Friday at 10:12 a.m. Putting the paper back in the box

The manuals and printed material became a substantial project of their own.

A game box used to contain more than a way to install the game. There might be a manual, a map, a registration card, or something you would keep beside the keyboard. Magazines provided reviews, hints, advertisements, and glimpses of software you had never seen running.

The advanced guide’s first chapters land at 10:12 a.m. Friday. NO CARRIER takes its name at 10:58 a.m. On Saturday, TURBO BUTTON’s page model appears at 11:40 a.m., followed by its shelf presence and fuller interviews shortly after noon.

Those objects helped people learn what was available and what they might try next.

The Owner’s Guide was written for this edition; it is not a reproduction of RSD’s original manual. The Ultimate Owner’s Guide goes further into game design: making blocks behave, building counters and gates, working with monsters, connecting scenes, and learning tricks from the new games.

World maps and level maps turn the actual game data into something a player can study away from the running game. Manuals, hint books, stickers, and box paper give individual titles more of a physical identity.

NO CARRIER is the smaller zine associated with the desk’s tools and BBS world, with its own fictional editor. Later work gave it quarter-letter pages and a printable layout.

This is where the project’s preservation goal became most visible to me. Making a game available is one kind of access. Recreating some of the ways a kid might learn about it is another.

The print work also required practical revision. Text had to fit its page. Diagrams had to be readable. A booklet needed to make sense when printed, cut, and handled. Near the latest commits, even disk labels were being checked against the dimensions of a real floppy.

Each publication has a different job. A manual should help the reader operate something. An advanced guide should explain how to make better decisions with it. A zine can assume curiosity, invite experimentation, and sound as though it came from another part of the scene. A magazine needs variety and reasons to keep turning pages.

TURBO BUTTON uses reviews, strategy, interviews, mail, and advertisements to create that kind of browsing. Its design material can send a reader back to a game or an editor. Its ads can point to objects in the desk. The fiction and the functioning software keep meeting.

The books also became a place to explain discoveries from development. The DOS bugs became a magazine feature. The executable modifications became guide material. That relationship keeps the publications tied to what the software actually does. They are useful parts of the project as well as objects in its setting.

Saturday at 11:22 a.m. A magazine to get lost in

The magazine began with a fairly expansive request. It should cover the Sandbox and Bizarre games as well as the Gameware and shareware collection. It should have hints, BBS listings, reviews, full-page advertisements, and forms to send away for books and catalogs.

The big news was that Game-Maker’s source had been set free. There would be an interview with me about buying and using it, and another with Claude about the port and the new games. Character spotlights could introduce Teddy, Gwinn, Doc Leo, and THE CHEZ.

I also wanted advertisements for the things already sitting on the desk: its modem, speakers, and disk box. A reader could encounter an object as a product in an ad and then find it functioning in the room.

The point was the experience of browsing. Before the internet became part of everyday life, a magazine or catalog might be where I discovered that a game existed. The pages around the thing I wanted were part of that discovery. I could arrive looking for a hint and spend time reading something else entirely.

That required more than putting the site’s documentation into columns.

At first, the magazine leaned too heavily toward being an official companion to the project. Almost everything led back to the fork and its features. I brought back feedback asking for the unpredictable human clutter that made an independent magazine interesting: letters, disagreement, corrections, somebody’s elaborate theory about a secret.

A reviewer could prefer a small game to the flagship. A reader could misunderstand a control. A correction could make an earlier issue feel as though it had actually existed and had not been perfect either.

These were fictional voices in a new publication. Their purpose was to make the reading varied, not to impersonate a historical readership. The magazine openly mixed present-day subjects with its period design: browsers, an AI interview, and the 2014 source release all belonged to the project it was actually covering.

The reference material helped distinguish that premise from a generic idea of “retro.” I located the Game-Maker advertisement in Computer Gaming World issue 99 and supplied the issue as a layout reference. The PDF was large, so I suggested extracting text and smaller pictures rather than treating the entire file as an asset for the website.

Looking at those pages brought back details about how magazines allocated space. An article could continue elsewhere. Half a page might belong to an advertisement. An order form had a visual language of its own. A product name, price, and return address were things a reader would search for.

Even my remembered purchase had a loose end. Seeing a price change between issues made me realize I had only owned one of those magazines at the time. I had not known the price had changed. I reflected that the company had probably honored the form I sent. That remained a recollection and an inference, rather than something to turn into a new certainty about the sale.

The magazine was beginning to produce memories and questions as well as contain them.

The ads had to belong to the room

The advertisements became another round of practical direction.

A modem ad should show the modem on the desk. The disk-storage product should resemble the box a visitor could open, including its lock and key. A sound-card parody needed the brashness of the period’s sound-card advertising. The gamepad needed to recall the hardware I had used.

I supplied a Gravis advertisement as a style reference and remembered the pad’s removable stick. The fictional GRAVITAS controller then acquired its own jokes. When its shape looked like a peanut, I asked the agent to lean into that rather than ignore it.

The mug designs had their own problems. A screenshot pasted onto a mug was not the same as a designed graphic. I wanted circular backgrounds with characters and text allowed to extend beyond them, better use of the printable area, and layouts that made sense for the paper I actually used.

Even the rotating preview needed attention. At one angle the handle’s geometry produced strange triangles. Inside, the mug looked like parts meeting at a seam rather than one hollow object.

These requests might seem far from porting a DOS game engine. They were part of the same expanding experience, though: the magazine advertised the objects, the desk held them, the software let someone examine them, and makers with a sublimation printer or die cutter could create the actual products. A weak drawing in one place made the connection less convincing in the others.

Giving the magazine permission to dislike my game

The response recognized that panning a Sandbox game in its own magazine helped the publication feel less like advertising. That was exactly the direction I wanted. Personal affection for the story should not require every fictional reviewer to applaud the result.

A few minutes later I added that Snowbound had been our first game, so it made sense that it might be the weakest. We had learned things while making the others.

That exchange gave the publication something a promotional page would usually avoid: a reason to argue with the maker. It also gave development a useful next step. The criticism could remain in print while the game became better.

The magazine was no longer just explaining finished software. It was participating in the same conversation that was changing it.

Friday at 8:41 p.m. Teaching the editor to examine a game

As more games accumulated, the question changed from “does it run?” to “can someone finish it?”

At 8:41 p.m. Friday, the Level check introduces a headless player using the real engine and an explorer that tries different moves.

That choice is important. A map image cannot tell the whole story. Whether a character can reach a place depends on movement, collision, block behavior, and the rules operating around it.

The checker draws a heat map of where it managed to get. It can flag places that may trap a player and offer fixes. Its findings also appear in the relevant editors, bringing a problem closer to the setting that causes it.

Whole-game playtesting and recorded routes developed alongside it. A bot could work through a game, and a route could be replayed through the actual runtime.

These tools need an honest description of their limits. A bounded search can miss a solution. A successful bot run does not establish that a game is enjoyable or that a new player will understand it. A warning is something to investigate.

Even with those limits, the tools answer useful questions. Can the player reach this exit? What happens after that scene transition? Did a recent change remove the route that used to work?

The first Level check implementation marks a shift in the project. The port was beginning to use its understanding of the old engine to help people design new games more confidently.

There are several different questions inside the word “working.” A file can be structurally valid. A scene can load. The player can move. An exit can be reachable. The next scene can preserve the intended state. A complete route can reach the ending. Each answer gives some confidence, and none automatically supplies all the others.

The checker helps expose the gap between an author’s knowledge and a player’s situation. An author knows which block is important and where the route is supposed to go. A search through possible movement can reveal that the route depends on a jump that does not work, or that an apparently harmless drop leaves no way out.

A warning should leave room for an intentional choice

On Saturday morning I objected to some of the checker’s language. It was treating judgments too much like rules: a mechanic used once could be called unfinished, and more than a few enemies could be described as noise.

Those observations could prompt a useful question. They could also be wrong about a deliberate design.

I wanted the tool to phrase them as suggestions and let an author dismiss an intentional choice. A warning about a route the search could not complete was already different from proof that the route was impossible. The advice about style needed the same care.

There was a related problem in the world maps. The software knew about scenes, so conversations and signposts could become separate land patches. The player knew about a town containing those conversations and signs.

Both views had a use. An author might want every scene. A player trying to understand the fictional geography needed the locations grouped in a way that matched the journey.

These were cases where a correct internal description could still be an unhelpful explanation. The tools had to learn which question their reader was asking.

Saturday at 7:41 p.m. Checking the promises against DOS

The investigation continued after the first fixes. On Monday at 2:07 a.m., help-file handling was corrected again: the transferred player uses CONFIG.HLP and never reads GMHELP.TXT.

These corrections are important to the project’s identity. I was not trying to make the browser accept a new class of games and leave DOS behind. I wanted the files to remain useful in both environments. Testing in DOS challenged assumptions the new implementation could otherwise have kept repeating.

The discoveries also became documentation. The guide and magazine could explain the constraints using problems we had actually encountered. A failed export was therefore an opportunity to improve the output, its checks, and the next author’s understanding.

Saturday night The games left the browser and met my hands

The DOS session began with a practical request at 7:38 p.m.: make a folder I could mount, containing the installed Game-Maker tools and the games laid out for testing. I did not want to assemble the same environment by hand every time.

At 7:53 p.m., I reported that Carl’s opening animation looked wrong in DOSBox. The Bard introduction had played correctly, so the failure was not simply “animations do not work.”

I supplied a screenshot. Claude described streaks and a partly faded picture, then investigated the original reader’s buffer behavior. Its report compared Carl’s large opening chunk with the smaller chunks in the introduction that worked.

The difference mattered more than the total length of the movie. A short animation could still begin with one piece that the DOS player could not read safely.

I asked whether the problem was one frame or the entire file. I wanted the explanation precise enough to become advice: smaller animated regions, smaller pieces, or a different way of arranging what the player read.

The agent re-encoded the animation while I was trying to capture a brighter example of the failure. I briefly thought the broken version had already disappeared, then managed to get a screenshot with enough of the normal picture visible to explain what had gone wrong.

That is a very different record from a commit saying an encoder was fixed. There was a failing picture, an attempt to identify what made it fail, a proposed correction, and another thing to look at.

Other problems followed. Blaster showed black while a note continued sounding. Brief also began with a black screen. A help button reported that CONFIG.HLP was missing. The investigation was moving through the exported game as a person would actually encounter it.

I asked for the findings to enter the checks and the guide. If an animation exceeded a limit that could break DOS playback, another author ought to hear about it before distributing the game.

The same bug in two places answered a different question

The proposed work included lengthening the relevant standing frames, adding a warning for unusually short sequences, and explaining the behavior in the guide. This was a game-design correction that could be expressed through the existing format.

The distinction was useful: sometimes DOS exposed an error in the new exporter; sometimes both players exposed an error in the generated game. Keeping both environments available helped us tell those stories apart.

A walkthrough could succeed where I could not

By 9:52 p.m., I was stuck trying to backtrack past a refrigerator in Teddy’s Little Bigger Adventure. Two minutes later I explained the physical problem: my hands were not quick enough to alternate Up and Left in the way the route expected.

The bot could perform those actions with very precise timing. Its success had concealed the difficulty for me.

I asked for the demonstrations and checks to account for somebody using one direction at a time and making slower changes between keys. Claude proposed a “steady hands” rule: give the player time between actions, avoid requiring simultaneous arrows, and identify places that depended on unusually exact timing.

The requested fix was still within Game-Maker’s design space. A jump could carry sideways on its own. A step could replace an awkward maneuver. The game did not need a new engine rule to become more approachable.

A few minutes later, Teddy3 supplied another failure: I reached the outside without the keys and could not return for them. Earlier, in Sandcastle Knight, I had needed a clearer clue about how a nearby object was collected.

These are different problems from malformed files. They concern what a person understands, what their hands can do, and whether a mistake leaves a recoverable situation.

The Saturday session moved between all of them. An animation bug became an encoder change. A tap became a timing warning. A difficult jump became an accessibility request. Snowbound’s weak play became a review and a controls fix.

That was why I asked for the magazine’s interview to include the importance of my testing the games in DOS. The human contribution was visible in the things the automated route and the browser-only checks had not asked.

Sunday afternoon Learning from other people playing

The new games were not finished when their first playable versions appeared. Many received additional work after I watched other people’s video reviews and play sessions of older Game-Maker games.

That supplied a kind of information that source code cannot provide.

The code can tell me that a jump is possible. A video can show me that a player does not realize the ledge is a platform. The engine can report that a route reaches the exit. Watching somebody play can reveal that the route is repetitive, the objective is unclear, or the punishment makes the player stop caring about the next attempt.

I watched material including Level Engine’s 34 part series of an RSD Game Maker Binge and Pixelmusement’s Ancient DOS Games episode on Game-Maker. The project records those research credits on Sunday at 2:36 p.m. That timestamp marks the credit entering the repository, rather than the beginning or end of all the viewing.

I could take an observation back to Claude and ask what our own games or documentation should do with it. Sometimes the useful response was another feature. Sometimes it was a clearer sign, a better route, or a reason to stop adding more.

It is tempting, especially with agents able to produce more material quickly, to treat size as an easy measure of progress. More rooms, more monsters, and more scenes are visible results. A player’s reaction asks a harder question: is this part worth playing?

That is a useful counterweight to Maximus. One game deliberately explores capacity. The collection as a whole still needs games whose length, difficulty, and structure suit their ideas.

The research flowed into The Ultimate Owner’s Guide and the magazine as well. TURBO BUTTON gained “What Players Hate (and How to Fix It)” and “Readers’ Picks: Polish Over Size.” The latter uses fictional reader games to explain the design lesson; it is not a set of claims about actual people’s submissions.

This is one reason I wanted the publications to contain practical material. A period-style magazine can do more than make the desk look convincing. It can translate something learned from watching a player into advice another author can use.

The same feedback loop affected the software around the games. When a problem can be checked mechanically, it belongs in a tool as well as a paragraph. When it depends on judgment, the guide can explain what to look for without pretending an automated check will decide it.

Watching those videos also made the historical community feel more present. I was seeing what people had attempted with the same construction kit, where they had succeeded, and where someone arriving years later struggled.

The project was beginning to learn from that accumulated experience instead of treating the original engine as an empty box.

Monday before dawn Making the existing player configurable

The old games contained another kind of customization: some authors had edited XFERPLAY.EXE itself.

In Builder, menu words had been replaced with spaces. In Rōdïp: Rover of the Deep, status labels had been renamed, including Energy and Failsafes. Those changes affected the game’s presentation even though they were not ordinary settings in its data files.

I asked the agent to inspect the whole executable and map the opportunities for customization. The goal was to expose player text, apart from the protected original notices, along with colors, frames, and borders, instead of making another author discover byte offsets by trial and error.

The work expanded into a typed patch table and editing controls. The table lands at 2:30 a.m. Monday, and the Integrator’s DOS player dialog follows at 3:01 a.m. The reviewed settings also include positions, timing, and selected function-key behavior.

The original credits and copyright stay protected. The customizer works from a recognized player build, with rules for the supported edits. It is not an invitation to write arbitrary values into whichever executable happens to have the same filename.

The project stores those choices in its companion data. That keeps the author’s intent as editable settings: these words, these colors, this border. A project backup can preserve them alongside the game resources without asking DOS Game-Maker to understand a new section inside its original files.

When the author downloads a DOS version, the exporter applies the settings to a copy of XFERPLAY.EXE. The resulting player contains the changes. DOS does not need to read the companion file at runtime.

The web player can reflect the same recorded presentation choices, so the project can carry its look across outputs.

This is a concrete example of where the new features belong. The editor adds a manageable way to configure something historical authors were already changing by hand. The export produces an ordinary DOS game and a customized DOS player, rather than a game dependent on a new browser-only engine.

The findings went into The Ultimate Owner’s Guide, and the credits name the games whose modified players prompted the investigation. The customizer’s source map describes how the companion settings become executable patches.

Monday morning Importing old games changed what I thought was possible

Watching reviews led into another important activity: importing old games and playing them in the web app.

That was one of the port’s practical rewards. The older files were no longer something I had to arrange a separate DOS setup to investigate every time. I could bring a game into the browser, play it, and ask how a surprising effect worked.

The community’s games became another source of design knowledge.

Some discoveries were visible immediately. Others needed a closer examination of maps, blocks, character sequences, and timing. Claude could help inspect those resources and compare the technique with the original player’s behavior. My part included recognizing something interesting enough to pursue and deciding where it could fit in our games.

Monday’s commits make this exchange particularly clear. The guide gains explanations of wrapping courses, parallax, double-digit numbers counting down, and a road moving toward the player. New levels using those ideas follow. Map-printing and checking tools then have to learn how to describe them.

Monday at 10:12 a.m. The archive did not arrive one game at a time

The response was another parallel assignment: inspect the collection, list the games found, let me choose, show progress, and explain things that did not contain a game. Producing an empty project was not a useful substitute for saying what had happened.

The old packages were not always simple ZIPs containing one clean set of files. One included a DOS self-extracting archive inside another archive. The agent identified it as a ZIP carried by an executable and proposed reading its contents without running the program.

Another case was more misleading. A game’s modified player used renamed file extensions. The import process tried to restore their ordinary meanings, then reported eight supposed FLI animations as unreadable.

I asked whether they were really broken animations. It turned out they were worlds for 3D Construction Kit, a different program, sharing the extension the modified Game-Maker player used for animation.

The importer had followed the extension mapping too eagerly. It needed to inspect the contents before assigning a familiar name. The correction kept genuine graphics identifiable without relabeling unrelated files as damaged Game-Maker resources.

That is the sort of disorder a collection preserves. It may contain installers, catalogs, extra programs, duplicated games, and files arranged for a launcher rather than for a modern importer. Making the archive accessible meant learning to meet it in that form.

A character could be a menu pointer

Once I was playing the imported games, discoveries arrived one after another.

In Zarlor 2, a character looked like a mouse pointer used to select another character. Return of A-J used a hand. Party of Four offered larger portraits, with a small creature moving beneath them.

The familiar machinery of a map and a controllable character was being used to make a menu. A scene link under a selection could carry the player into the chosen game or character.

New Age Warrior used a starting room to choose between Cadet and Commando. Woman Warrior let the player walk into Play Game or Demo. These were interface choices made out of ordinary game space.

That correction matters to me. The archive was not just supplying material to a model that already understood it. Playing could overturn an explanation that sounded settled.

Timers and punches were arrangements of old parts

A number on a screen, a character-selection cursor, and a punch landing just ahead of a fighter might look like separate features in a modern engine. Here they were designs assembled from the construction kit’s existing parts.

Those discoveries gave the guide a more useful purpose. It could explain how to think with the tool, using techniques people had actually found, rather than only cataloging what each field meant.

The striking depth effects came out of that same morning of playing. They were part of a larger discovery that a remembered “simple” game maker had supported more approaches than I had kept in mind.

Driving toward a horizon

The underlying system is still operating on its familiar two-dimensional resources. The depth is an arrangement the author has persuaded the player to see.

At 12:40 p.m. Monday, the guide receives the explanation, crediting Jet! as a source of the technique. Almost immediately afterward, In The Year 2000! receives The Cloud Lane: Grandpa’s flying CitiCar seen from behind, steering through traffic that arrives from the horizon.

The new level also needed a destination. An endless visual effect is interesting to inspect, but the game needs a reason to keep going and a way to finish. The Cloud Lane combines the approaching scenery with a countdown and an opening ramp. Where Jet! was more of a demonstration of the technique, I was able to communicate an idea to Claud that the character should always attempt to move up, and eventually a path becomes available to exit the level.

After trying the results, I told the agent that Teddy’s Dream Run, Snowbound’s sled run, and Virus Blaster looked good. Then I asked for the horizon-driving technique in Virus Blaster too: riding the data bus between stages, turning an idea already shown in its transition cartoon into something to play. The agent took The Cloud Lane as its model. A successful experiment in one game had become a brief for another.

Teddy’s Dream Run and a background that moves at different speeds

Parallax was another example.

A distant skyline and nearby scenery moving at different speeds can make a scene feel deeper than a single flat background. I found an old game, Godzilla, doing this through animated blocks on a screen that did not scroll.

A row of skyline pictures could move a little between frames and loop back to its beginning. Because repeated blocks shared their animation timing, the whole band moved together. Another band could use a different speed.

The repeat has to join cleanly. In the documented example, the pictures loop across the width of a 20-pixel block. The cost is paid in block definitions and animation frames, rather than a new rendering system.

The guide receives this explanation at 11:59 a.m. Monday. By 12:43 p.m., it names Teddy’s Dream Run as a worked example; the new level lands at 12:48 p.m.

That ordering is another reminder about parallel work. A guide update and a game commit are records of work landing in the shared project. They are not evidence that the entire example was conceived and completed in the five minutes between them.

In Teddy’s Little Biggest Adventure, the technique becomes a dream run with scenery passing behind Teddy. It changes the feel of a level while staying within the original construction kit’s rules.

A speeder-bike course and a much longer sled run

A Star Wars-style speeder-bike level showed me another way to think about a wrapping map.

The guide’s diagonal-wrap explanation lands at 10:49 a.m. Monday. At 11:32 a.m., Virus Blaster gains The Ribbon Cable, a diagonal wrapping leg. Later work makes those building pieces reusable by other stages.

At 3:22 p.m., Snowbound’s Jamie Street sled run is changed to slant through the wrap, making it three times as long.

That was a particularly satisfying result because the improvement stayed inside the old map size. We were using its space more effectively. The sled could keep going through a longer course, and Virus Blaster could offer a different kind of flight.

The maps needed their own revisions. I pointed out that Virus Blaster’s diagonal courses seemed to be missing parts, and that Snowbound’s panels should join where the course crossed from one to the next. The sled-run poster was still showing a square map rather than the course as a player experienced it.

I asked for the panels to be stitched together and enlarged enough to read the trees, flags, signs, and finish. That sent the agent back to compare the printed course with the full map and the actual walkthrough route. The unrolled layout needed to explain the ride, including its seams and visible surroundings.

That is the kind of connection a simple list of features misses. Playing old games was actively changing the new software. The browser port let me investigate the past, and what I found there made the port’s own games better.

Throughout the week Following the credits back to their sources

Crediting everyone involved was a substantial part of the project, not a final line added after the software worked.

The original program has a history of its own. Its credits name G. Andrew Stone, G. Oliver Stone, Oliver Stone Jr., and Joan Stone, along with contributions such as Peter Savage’s sound and joystick work. The browser port should make that history easier to find.

The games supplied with it have their own authors, too. Preserving a CD collection means keeping those identities and notices attached to the games, rather than allowing everything to appear to have been made by the person maintaining the new website.

The review went further into the material inside those games. Music was examined and credited. Images were reviewed to identify photographs, paintings, film or television frames, and other sources where possible. The notice file records both identifications and uncertainty; an image that only appears to come from a particular source is described that way.

That distinction matters. Credit should preserve what we know without turning an inference into a fact.

The documentation also distinguishes the project’s new code and generated material from older third-party assets with their own terms. An open-source release of the construction kit does not make every image or recording carried by an old game something this fork can claim as its own.

The same care applies to our new work. The AI tools, personal photographs, recordings, research videos, and older games that suggested techniques have separate contributions to acknowledge. A technique can inform a new level while the earlier game’s art, music, and text remain its author’s work.

There are also objects that look historical but were made for this edition. The desk’s box and CD designs and its Owner’s Guide are new creations, identified as such. Atmosphere should not become a false attribution.

The result is a detailed notice and credits record. I wanted someone arriving through the web app to be able to follow the work backward: from this port to the original program, from a game to its maker, and from an asset to its source where that source could be established.

Monday at 11:51 p.m. Adding an assistant that can work on the game

I first asked whether the web editor could connect to an AI through MCP. The proposed sequence was a server for game folders, a bridge to the open editor, and support for the browser’s experimental WebMCP interface. I asked for all three in order.

I also described the destination: someone should be able to set up their own AI, describe a game, and keep asking it to build, fix, and extend that game. Since I usually worked with Ollama or OpenAI-compatible services, those became the initial connection options.

This is the AI available to the person using Sandbox Edition, separate from the Claude agents developing the repository. The same game-editing tools support the chat and the external bridge.

A later request came from losing my place. I returned to a game without the conversation I needed to remember what came next. I asked for the AI to keep brief entries in a to-do list, then asked for Doing and Done lists as well. Reminiscent of Kanban swim lanes often used in eXtreme Programming, that gave the project a record of its next steps that could outlast a particular exchange.

The assistant also gained recipes for platform levels, rooms connected by doors, driving scenes, and other patterns, described through Game-Maker’s own capabilities. Tool corrections addressed missing resources, wrong file kinds, and repeated failed calls.

The goal was a usable editing session: describe something, see the change, try it, and know what remains to do. The game still uses the same original-format resources.

Tuesday afternoon The new assistant needed playtesting too

The assistant inside the editor had its own version of the problems we had been solving with Claude. A connection could work while the experience remained confusing.

My Ollama service was on another computer, reached through Tailscale. The connection test found 29 models, but the interface appeared to offer only one. The agent traced that to suggestions being filtered by the model name already in the box and added a clearer installed-model list. This brings me back to the days of user task analysis and making things intuitive.

I tried a simple brief about a stick figure going to the gym to get buff. The resulting exchanges included failed scene edits, long tool output, and runs that seemed to stall. I asked for a copy button and pasted the failures back into the development conversation.

That was a useful separation of roles. Claude was developing the application. Another model was using the application’s game tools. Improving one did not automatically make the other good at its job.

I also wanted to see what was happening. Watching a stream of render calls without a visible picture did not help me judge the game. I asked for completed calls to produce visible results as they arrived, rather than collecting everything in one response that seemed to grow forever.

The requests for context management came from the same practical concern. A smaller model should not need the entire tool catalog in its prompt at all times. It could ask for the category it needed. Large results could be shortened, older conversation summarized, and the current goal kept in view.

Then I asked for short recipes: how to make a side-scroller, a key and lock, an NPC conversation, a diagonal course, or a driving scene. We had spent the week discovering and documenting those techniques. The assistant needed a compact way to retrieve that knowledge while it worked.

An agent built the recipe library from the guides and the existing tools. Its report distinguished checks that had passed from the next real test with my live model. That distinction was useful. A recipe could name valid tools and still need to prove itself in an actual editing session.

The to-do list completed the connection. When I returned without enough conversation to remember the next step, I wanted the game itself to retain it.

In that sense, the assistant inherited something from our development process: inspect the actual game, make a small change, show what changed, test it, and leave enough of a record to continue later.

Tuesday at 2:12 a.m. Making the project easier to keep

As the project grew, cleanup focused on keeping the site quick to open and the source manageable. Large features were loaded only when needed, long files were split by responsibility, and narrow-screen problems received attention.

By Tuesday at 2:12 a.m., the desk’s large rendering file is being split by responsibility. At 2:45 a.m., the source map becomes an index of smaller guides stored alongside their areas of code. There is a nice symmetry in that: the visitor gets guides to the software, and the next maintainer gets guides to its source.

The performance work is also about proportion. Opening a menu should not require loading a game-analysis system. Browsing printed material should not pull in unrelated engines. Separating those features lets the initial page remain smaller as the project grows.

The cleanup also depended on noticing things that looked wrong. I reported that NO CARRIER no longer looked photocopied. The agent traced that to generic printable styles overriding the zine’s typewriter font and paper treatment, then corrected the rules. Its next report described the gray edges and toner specks returning. The document had still rendered; its intended identity had been lost.

Versioning gives the games’ revisions their own clarity. A substantial change in level structure can deserve a major version, while an art correction or a longer run can be recorded differently. That distinction helps someone understand why an older walkthrough or downloaded copy may differ.

That is still preservation work.

Future access depends partly on whether somebody can understand and maintain the project. The original C source, the file formats, the TypeScript implementation, the tests, and the explanatory documents all provide different kinds of help.

I have wondered whether TypeScript is the right long-term choice when JavaScript is what the browser actually runs.

The history does not settle what tools will exist decades from now. It does show a more useful preservation strategy taking shape: keep the original material, describe the formats, make the behavior testable, and let the games leave the development environment.

TypeScript helps organize this implementation. The old formats and the ability to produce playable exports give the project a life beyond that choice.

Cleanup also includes deciding where explanations belong. A long source file, an outdated help page, or a misleading button label all place extra work on somebody else. Reducing that work is part of making this project easier to return to after the excitement of the first week.

Keeping the growing collection from arriving all at once

The performance concerns were already concrete by Friday morning. I reported that opening the desk made 248 requests and transferred 22.6 MB. I could see map files being downloaded for a game I had not opened.

That was not the kind of growth I wanted. Adding another game or publication should not make every visitor pay for it before deciding what to view.

I asked for progressive loading and for related game data to travel together where that reduced unnecessary requests. The experience should remain quick enough to browse, especially as the collection became larger.

The visual cleanup had a similar practical standard. A sticky cast stage kept the characters visible while I scrolled, but then occupied too much of the page. I asked for it to shrink or become a small picture-in-picture. A notice that new code was ready to reload stayed in the way, so I asked it to collapse after a moment.

These were cases where solving one problem created another. Keeping a stage in view was useful until it prevented me from reading. Announcing an update was useful until the announcement competed with the software.

The source needed that attention too. I wanted understandable files, consistent formatting, and a clear organization for the code we were adding. Those requests were paired with explicit protection for the original folders and narrow exceptions for documentation we had deliberately changed.

That boundary had become necessary because “leave the old source alone” was easy to say and needed more exact instructions in a working repository. Cleanup should make the new implementation easier to maintain while preserving the record it had been built from.

I kept leaving those tasks for the quieter intervals: while I slept, while other jobs finished, or once the obvious bugs had been addressed. By the end, cleanup was a substantial workstream of its own.

Tuesday afternoon and evening Giving the tour my voice

The visual guided-tour framework lands at 2:41 p.m. Tuesday, just before the afternoon merge. It gives characters from the games chapter scripts, controls to point at, and captions to explain the software.

The pending branch adds spoken narration, including voices generated from samples of my own voice. The local tools include Pocket TTS for those voices and Kokoro for stock voices used by other hosts, with pitch and speed adjustments for the characters.

I wanted to hear samples before settling on the voices. I also asked that my source recordings stay out of the repository. The website would receive the short generated narration clips; the recordings used to create them would remain separate.

File size mattered as well. I asked for mono, low-bitrate speech that stayed clear, and for the clips to be organized by area with a readable list of what each said and where it was used. The generation process writes that index from the tour’s line data, making it easier to review and regenerate a changed line.

Listening revealed problems that a file-size check could not. Courier Max’s delivery sounded slow and dopey to me, which did not suit a space courier. I remarked that the voice might suit a gentle giant, but we did not have that character. The courier needed a brisker delivery.

Pronunciation needed checking too. I heard words such as BBS and 1994 being cut short or spoken incompletely and asked the agent to run Whisper over the clips. The subsequent work gave the speech engine explicit spoken forms, such as “nineteen ninety-four,” while keeping the normal written form in the captions.

Transcription was another check, not a replacement for listening. The reports included cases where the recognizer itself misheard a word. Its useful role was to flag lines for review and make it easier to find recordings that needed another take before I would review them myself.

The hosts also needed to demonstrate what they described. I asked for a BBS chapter that logged in, visited the file area, opened a file’s details, and downloaded it, then changed the modem speed to skip ahead. On the desk, I wanted the game-pad dialog and a game box opened while they were being explained.

By 9:28 p.m., the voice updates include new desk lines, the BBS chapter, and revised character delivery. The tour has to account for those actions: point at the visible control, keep its captions usable, and put back temporary settings and downloaded material when the demonstration ends. Achievements pause during the tour, so the hosts cannot earn them for the visitor.

The published video tour gives someone a way to watch from outside the site. The interactive tour can show them around the software they have open, with captions, pause, back, next, and sound controls.

At this point in the history, the expanded spoken tour remains on the pending branch. Its development involved selecting voices, listening to performances, correcting words, and revising demonstrations alongside the code.

The tour needed a real ending

The spoken tour introduced another kind of playtest. At 7:26 p.m. Tuesday, I reported that I could not tell when it was over. The professor had disappeared, I was back at DOS, and nothing else happened.

I had also expected a recording to download. The existing recording mode had prepared a cleaner screen for an external recorder rather than recording it itself.

The label and the result had not matched my expectation. Claude treated that as something to change: an unmistakable ending and actual recording behavior, alongside the pronunciation checks I had requested.

Its next report described a test recording of the Cast chapter with both video and sound, while distinguishing that shorter test from watching a complete tour in my own browser.

That exchange captures why the tour needed review beyond whether its clips played. A visitor had to understand how to begin, what the hosts were doing, and when the visit was finished.

I wanted the hosts to show the software as well as name it. If a character discussed a guide, they should open it. If they explained a tab, they should select it. The editor was substantial enough to need separate sections for its different tools.

The final rounds were still continuing as the session approached its usage limit. There were new clips, demonstrations, and book exports in flight together. The week ended with a working project and more concrete refinements pending, rather than with every workstream stopping at the same instant.

Tuesday at 9:29 p.m. Letting the books leave too

The pending branch also adds EPUB exports for the manuals, guides, and magazines. This is the reading counterpart to the game exports.

Reading on a phone exposed another problem. I told the agent that repeatedly tapping the page-turn buttons was difficult and asked for both individual-page and scrolling views, with scrolling as the mobile default. Later, I asked for self-contained EPUB editions of the manuals, hint books, and magazines so they could be read offline. The printed objects needed useful ways to travel beyond their page viewer.

EPUB gives the same material another useful form. Someone can download a book, keep it in a reading application, adjust the type, and read offline without keeping the site open.

The EPUB packaging work begins at 9:29 p.m. Tuesday. Within the next several minutes, commits add the game manuals, hint books, other box booklets, this edition’s Owner’s Guide, and The Ultimate Owner’s Guide. TURBO BUTTON follows at 9:40 p.m., with NO CARRIER and the site’s Guide at 9:42 p.m.

The implementation treats these as books with chapters, navigation, and included pictures. It does not depend on every page being a screenshot of the website. Ordinary text can reflow, while a cover, an advertisement, or a piece whose composition matters can remain a picture.

That distinction is especially useful for the magazine. A review or interview should be comfortable to read at the size the reader chooses. A full-page ad can keep its visual identity. Internal references need to lead to the right place in the exported book, rather than expecting the original viewer to be present.

Hint books have their own problem: keeping a reader from seeing an answer too soon. The EPUB work separates answers into a linked section, giving the book a form that suits an e-reader instead of relying entirely on the printed edition’s visual tricks.

Taking the images along is just as important as taking the words. A diagram or screenshot that points back to the live site would weaken the purpose of an offline edition. The branch’s builders package the material needed for the book and check the EPUB’s structure.

I wanted the paper objects to feel as though they belonged beside a computer in the 1990s. I also want someone reading them now to have a convenient way to do it. Printable pages and reflowable books support those different uses.

Like the expanded voice tour, these exports are pending at this stage. They extend one of the project’s oldest commitments: the website should help people get to the material, and it should give them ways to take that material with them.

What I ended up rebuilding

The repository now contains a browser port, modern authoring tools, new games made within the original engine’s capabilities, a simulated computer, bulletin boards, and an unusual amount of paper.

The connection between them is access: how people discovered software, how they learned to make it, and how their work can keep being played. Preserving the original behavior and credit, keeping the files interchangeable, and letting the player travel to other sites are as central to that goal as the recreated desk.

Someone can use Sandbox Edition to start building in the modern editor, open an old game collection through a simple web player, or spend time at the recreated desk. Each route keeps a different part of the original experience accessible.

The week also changed my sense of what a finished preservation project might mean.

There will always be another detail to research, another old game to try, or another way to improve an editor. The practical goal is a version people can use and understand: something they can play, inspect, export, and learn from without needing to have followed its development.

The parallel AI work made the scope of this week possible. My conversations and playtesting shaped the result, while older games kept revealing techniques worth carrying forward. The project grew through that exchange between new tools and the community’s existing work.

The most satisfying result would be another person getting curious enough to change a block, draw a sound, build a room, or figure out how an old game worked.

That was what the original program made possible for me. It is what I want this version to keep making possible.

---

Try Game-Maker: Sandbox Edition · Browse the source

The merged history is anchored at 23c37780, Tuesday’s afternoon merge. The pending developments are described through 486c874c, Tuesday at 11:55 p.m. Personal background comes from Lewis and Game-Maker. Attribution is recorded in NOTICE.md; the pending branch documents its tour voices and EPUB builders. Saved exchanges from the development conversation supply the requests, feedback, and handoffs described here.