Project Damocles case study

2w 6dFrom conception to this snapshotInside a three-week milestone window

68000Legacy game architectureComplex, stateful software from a different computing era

NoneOriginal source code or design notesThe project began without the materials normally used to maintain software

The non-technical read

A difficult inheritance, turned into a useful decision.

Legacy software often reaches a point where nobody can simply open the original project and carry on. The machines have changed, the development environment has disappeared, documentation is incomplete or absent, and the people making a decision are left with a blunt question: is this still workable, or is it effectively lost?

Project Damocles was conceived to replace that uncertainty with evidence. The aim was not to promise a complete remake in three weeks. It was to establish whether a small but meaningful part of an unusually complex game could be understood well enough to behave coherently in modern software, withstand repeat testing and support informed review.

By the Day 20 snapshot, the answer was encouraging. A deliberately bounded route could be exercised from a normal start, carry state through multiple contexts, retain a recovered objective and produce matching declared outcomes across the project’s modern reference and Windows-native candidates.

That is not the same as completing the game. It is something more useful at this stage: proof that the project can move from opaque legacy behaviour to a defined, testable engineering result without pretending every unknown has been solved.

The work behind the result

Three weeks used as a forcing function.

The short timescale made scope discipline essential. The project had to answer a valuable question end to end, rather than accumulate disconnected discoveries.

Week 1
Turn uncertainty into testable questions.
Define the bounded objective, establish evidence and authority boundaries, and decide what a credible result would need to demonstrate.
Week 2
Build the smallest meaningful end-to-end slice.
Represent the necessary behaviour in modern software, challenge it repeatedly, and keep recovered findings distinct from reconstruction and new presentation.
Days 15–20
Make the result reviewable.
Compare declared outcomes across modern runtimes, prepare a private Windows candidate, document limitations and translate the engineering result for technical and non-technical readers.
Day 21
Reach the milestone with the boundaries intact.
The three-week target is a credibility milestone: a basis for evaluation and planning, not a claim that the wider recovery is complete.

Successes at the snapshot

Progress that changes the quality of the conversation.

A coherent candidate: a meaningful bounded route works as a connected experience rather than a collection of isolated demonstrations.
Repeatable behaviour: declared outcomes can be replayed and compared, making discussion specific rather than subjective.
A modern evaluation path: a private Windows-native candidate makes the result assessable outside the original hardware environment.
Clear authority boundaries: recovered findings, supported reconstruction, modern presentation and unknown behaviour are labelled rather than blurred.
A practical next decision: the project now supports a better-informed conversation about preservation, further recovery and the feasibility of a larger programme.

The technical read

Engineering confidence without disclosing the recipe.

The challenge is not simply that the original title was written for a Motorola 68000 platform. It is that a large interactive program combines navigation, state, timing, rules and presentation in ways that are tightly coupled to its original environment. Without source or notes, a modern result must be justified by behaviour and evidence rather than by access to the original implementation.

Project Damocles therefore treats confidence as an engineering property. Claims are scoped. Important state transitions are made testable. A modern reference candidate and a separate Windows-native candidate are compared at declared outcomes. When both produce the same result for the bounded journey, the team gains stronger evidence that the model is coherent—without claiming that the original internal code has been recreated.

The project also maintains an explicit authority model. Some conclusions are supported as recovered findings; some behaviour is a modern reconstruction consistent with the evidence; some presentation exists only to make evaluation practical; and anything unsupported remains outside scope. That separation is as important as the software because it prevents a successful demonstration from quietly becoming a larger historical claim.

The technical shape

Four principles behind the milestone.

These describe the engineering standard, not the protected recovery techniques used to reach it.

01 · Scope

Bound the claim.

Choose an end-to-end question small enough to verify and meaningful enough to inform a larger decision.

02 · Provenance

Label what is known.

Keep recovered findings, supported modern choices, authored presentation and unsupported behaviour visibly separate.

03 · Repeatability

Test outcomes, not impressions.

Use stable starting conditions and declared comparisons so success can be reproduced rather than merely observed once.

04 · Portability

Prove the model can travel.

Compare the bounded behaviour in independent modern forms and prepare a controlled Windows evaluation candidate.

Illustrative modernisation

What does this mean for porting a modern version of the software?

The case-study result suggests that legacy behaviour can be described precisely enough to inform a modern software specification. The example below is deliberately generic: it explains what a future porting programme could ask for without revealing Project Damocles techniques, protected evidence or any original game content.

A generic interactive loop

From player intent to visible consequence.

Most interactive software repeatedly accepts intent, applies rules, changes state and presents the result. Once those responsibilities are stated independently of old hardware, they can become requirements for a modern system.

01Player intentMove, select, interact or pause
02Input contractTranslate devices into platform-neutral actions
03Rules updateApply timing, movement and interaction rules
04State commitRecord the resulting world and progress state
05PresentationRender clear visual, audio and interface feedback
↻RepeatContinue from the committed state

Abstract conceptual illustration of a generic interactive loop, with input, rules, state and presentation represented as distinct connected layers. — Concept illustration: a generic interactive loop separated into modern responsibilities. It contains no Damocles artwork, data or implementation detail.

Abstract conceptual illustration of a platform-neutral software specification supporting several modern device targets. — Concept illustration: one rights-cleared, platform-neutral specification informing multiple modern targets. This is an example, not a proposed Damocles product architecture.

From loop to specification

Turn behaviour into responsibilities a modern team can estimate.

A useful modern specification would avoid assumptions about the original internal code. Instead, it would define player-facing outcomes, state ownership, timing expectations, failure conditions and the boundaries between simulation and presentation.

That gives producers and engineers something concrete to discuss: which behaviour must remain stable, which presentation can be redesigned, which platform services are required, and which questions still need evidence or rights approval.

Public-safe behavioural requirementsWhat the user should be able to do and observe

Platform-neutral system contractState, timing, inputs, outputs and boundaries

Modern implementation layersSimulation, presentation, storage and platform services

Rights-cleared product targetsDesktop, console, web or other approved platforms

Example specification map

What a modern team could specify.

These are generic planning categories. They neither expose Damocles methodology nor assert that any particular commercial port has been authorised.

Inputs

Device-neutral actions

Define actions such as move, choose and interact independently of keyboard, controller, touch or accessibility hardware.

Simulation

Stable rules and timing

Specify the order and frequency of rule updates so gameplay outcomes are not accidentally tied to display speed or a particular machine.

State

Explicit ownership

Describe what the world must remember, when progress changes, and what needs to survive transitions, saves or restarts.

Presentation

Replaceable modern layers

Keep rendering, audio, interface and guidance separate from authoritative gameplay so they can evolve without silently changing the rules.

Platform services

Modern operational needs

Plan packaging, input devices, storage, windowing, accessibility, diagnostics and approved distribution for each target.

Acceptance

Outcomes that can be reviewed

Attach tests and review criteria to the public-safe specification so teams can identify a deliberate difference instead of mistaking it for a defect.

Developer view · Concrete example

A runtime flow a team could actually build.

This is a conventional modern software pattern expressed with generic types and responsibilities. It demonstrates the level of specification a porting team would need; it is not the architecture or recovery workflow used by Project Damocles.

Open the detailed developer blueprint

PlatformAdapter.poll()Capture devices
Read keyboard, controller, touch and accessibility devices at the platform edge.
Output: raw device samples
normalise(samples)Create commands
Map device-specific signals to a small, device-neutral command vocabulary.
Output: Command[]
step(state, commands)Update simulation
Apply the chosen update interval and invoke gameplay systems in a defined order.
Output: candidate next state
resolve(next)Resolve systems
Evaluate navigation, collision, interaction, objectives and transition rules.
Output: validated state + events
commit(result)Commit authority
Publish one authoritative state snapshot and a list of presentation events.
Output: GameState + DomainEvent[]
present(snapshot)Present and persist
Render frames, play audio, update UI and save only at explicitly permitted points.
Then return to device capture

Illustrative interface contract

Keep the authoritative core platform-neutral.

type Command =
  | { kind: "move"; x: number; y: number }
  | { kind: "interact" }
  | { kind: "pause" };

interface GameState {
  tick: number;
  scene: SceneRef;
  player: Transform;
  inventory: readonly ItemRef[];
  progress: Readonly<FlagSet>;
}

interface StepResult {
  state: GameState;
  events: readonly DomainEvent[];
}

function step(
  previousState: Readonly<GameState>,
  commands: readonly Command[]
): StepResult;

Generic pseudocode only. Names and shapes are invented for this explanation and do not describe Damocles data structures.

Illustrative acceptance flow

Carry one requirement from prose to release evidence.

Requirement
“Crossing a valid transition loads the destination while retained progress remains present.”
Scenario
Given a known start and retained item, when the transition condition is met, then the destination and item state are both reported.
Contracts
Assign ownership to navigation, transition and state-persistence interfaces.
Implementation
Build the platform-neutral rule and connect approved platform adapters.
Automated check
Replay the scenario and compare the declared outcome—not screenshots or timing accidents.
Human gates
Review usability, deliberate differences, content authority, rights and release suitability.

Important: these diagrams are explanatory abstractions. They contain no original game assets, recovered data, addresses, identifiers, private tools or technique-level instructions.

What the case study does not claim

A successful start is not a finished remake.

Project Damocles has demonstrated that a complex legacy 68000 game with no available source code or design notes can be worked with successfully at a bounded technical level. It has not established complete-game recovery, exact reproduction of every original behaviour, rights ownership, authorisation for commercial release or a public evaluator release.

The evaluator and detailed recovery material remain private. This public account intentionally explains the difficulty, standard of work and significance of the result without publishing techniques that could compromise the project.

Case-study chronology supplied by the project lead for the 4 August 2026 snapshot. Technical status is linked to the public CR1 evidence summary and technical account.