Claude Ported a 1993 Amiga Game

Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly is the original Babylonian Twins developer's project note about moving a Baghdad-built MC68000 assembly game from 1993 into Godot. It deals with a hard question: can an LLM read old assembly well enough to recover game behavior, not just translate syntax? The author says the first port took an evening, while getting the feel right and shipping took more weekends and evenings. For Claude Code, Anthropic's coding agent, the practical takeaway is simple: a legacy-port evidence trail is the notes, commands, diffs, screenshots, and tests that let someone check why a port behaves the way it does.

Let the model read before it rewrites

The interesting part of the Babylonian Twins port is not that an LLM produced Godot code quickly. It is that the model had to infer intent from MC68000 assembly, old project memory, notes, and repositories.

That is a different job from normal code completion. In a Claude Code workflow, the first useful move is often to ask for an inventory: routines, data tables, sprite assumptions, collision state, input handling, and anything that looks like a game loop.

The trap is starting with convert this file to GDScript. Old game code often hides meaning in layout, timing, and hardware constraints. If the agent translates too early, it can preserve the shape of the code while losing the behavior that made the game feel right.

A better first prompt is boring and powerful: read these files, name the behaviors, and show the evidence for each guess. That gives the human something to review before the rewrite begins.

Treat feel as separate from translation

The source note has a lovely split: the first port was fast, but the real work was getting the feel right and shipping it. Anyone who has touched old games will recognize that sentence immediately.

A platformer is not just draw calls and collision checks. It is jump gravity, input buffering, animation timing, camera follow, enemy wake-up distance, and tiny mistakes that became part of the original game.

So the practical move is to split the work into two lanes. Let Claude propose a mechanical port, then review feel as its own artifact: short clips, screenshots, input traces, or side-by-side notes from the original.

The trap is treating a running Godot scene as proof. Running is good. Familiar is harder. A port can compile, load assets, and still be wrong in the first three seconds of movement.

Use memory as data, not vibes

The author did something many successful agent sessions quietly depend on: he fed the model decades of human memory. Not just code. Not just a repo. Memory of how the game was built, what mattered, and what the old tools were doing.

That matters because legacy systems are full of missing context. A variable name may be absent. A routine may exist only because the Amiga had a particular constraint. A map editor screenshot may explain more than a thousand lines of disassembly.

The trap is letting memory stay conversational. If the human says, the camera always led the player slightly, ask Claude to turn that into a checkable note: where it should happen, how to observe it, and which target file implements it.

This is also where concise repository memory helps. A small CLAUDE.md note can say which emulator output is canonical, which Godot version is used, and which behaviors must not be modernized without review. Keep it short. The agent should not need a novel before every run.

Try one reversible port slice

The safest experiment is one behavior, one target file, and one receipt. Pick something visible but bounded: player jump, ladder entry, enemy patrol, map tile collision, or camera follow.

Ask Claude Code to read the legacy code first, write a mapping table, make the smallest target change, and stop. That is not glamorous, but it keeps the agent from turning a reverse-engineering task into a weekend-long rewrite with no trail.

This fits the broader habit behind the related training topic: make the convention small enough that people actually use it. It also pairs well with the autonomy boundary discussed in Breaking Claude Code Opus 5 Auto Mode, where the hard part is deciding what evidence must exist before the agent keeps going.

The limitation is real. Claude can misread old CPU flags, infer the wrong coordinate system, or smooth away hacks that were intentional. The point of the workflow is not to make the model perfect. It is to make its guesses reviewable.

Copy this slash-command receipt

Use this as a small Claude Code slash command for one legacy-port slice. It is deliberately narrow. The command asks for a receipt before more code, which is the habit this story makes worth stealing.

# /port-slice

You are porting one legacy behavior, not the whole game.

Inputs:
- Legacy files:
- Target files:
- Observable behavior:
- Run command or scene:

Steps:
1. Read the legacy files and list the routines or data tables involved.
2. Write a mapping table from legacy symbols/instructions to target concepts.
3. Name every assumption, especially timing, coordinates, flags, and units.
4. Propose the smallest target change that ports this one behavior.
5. Make the change only after the mapping is clear.
6. Identify one verification step a human can run.
7. Stop and output the receipt below.

Receipt:
- Behavior ported:
- Legacy evidence used:
- Assumptions made:
- Files changed:
- Verification command or manual check:
- What still might be wrong:
- Question for the human:

If you repeat this more than a few times, turn the mapping style into a Claude skill. A good skill can carry the reusable knowledge: 68000 addressing notes, Godot scene conventions, emulator capture steps, and the receipt format. Keep the command for the task. Keep the skill for the reusable method.

Try this next

Pick one visible legacy behavior and run the slash-command receipt before asking Claude to edit more code. If the receipt is vague, the port is not ready for a bigger slice.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Claude Ported a 1993 Amiga Game.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly — source
• Claude Code — getting started
• Claude Code — skills
• Claude Code docs: en hooks

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.