MF / SOURCE / OPEN MACHINERY

See how it moves.

Open source is part of the release, not a link buried in the footer. Read it, inspect its state, learn from it, report a problem, or make a version we did not imagine.

Raves of Qud

The project repository contains the Godot client, the C# bridge mod, developer tooling, tests, and deep technical documentation.

View repository
Project code
Mutant Factory’s viewer, bridge, tools, and documentation. The Raves repository identifies this code as MIT licensed.
Local mod files
The bridge code you place in your own game’s mods folder so the two programs can communicate.
Original game assets
Not in the repository. Raves extracts required tiles locally at runtime from the copy you own.
Builds and installers
Player-facing packages will be linked from release pages once they are verified and published.
01

Code

Improve rendering, the bridge, platform support, testing, accessibility, or packaging.

02

Documentation

Make a difficult installation step legible to someone who has never installed a mod.

03

Testing

Verify behavior against a real game version and report the exact path that failed.

Contribution guidelines and dedicated issue-reporting templates are still being prepared. The repository is the current technical source of truth.

Code is only one layer.

A repository is useful when somebody can understand the system well enough to test it, repair it, move it, and build another interface around it.

01

Portable data first

Important state should live in formats that can be diffed, versioned, tested, transformed, and rendered by more than one interface.

02

Adapters have boundaries

Game-specific and framework-specific code should stay separate from reusable behavior wherever the working system allows it.

03

Inspectors are product features

Debug views, graph views, textual representations, deterministic replays, and visual comparisons help users form their own model.

04

The work should travel

Local, portable, and self-hostable systems can outlive a vendor, interface, author, or institution.

What AI does. What it does not.

Much of software work is tedious, repetitive, and error-prone. Windows change size. Save files contain invalid data. Platforms disagree. These failures are familiar, and many individual fixes already exist in open-source code.

AI helps construct the test. It does not decide whether the test passed.

01

Start with failure

Use AI to collect known edge cases and turn them into deterministic tests that fail the same way every time.

02

Marshal known parts

Bring together existing algorithms, tools, and processing steps instead of pretending familiar engineering is new invention.

03

Design backward from proof

Change the implementation until repeatable tests, real data, and visible results agree. A model’s opinion is never the pass condition.

04

Publish the connections

The useful result is another open system: code, schemas, tests, documentation, and the wiring that makes the pieces work together.

It applies a new coordination tool to familiar engineering work, verifies the result deterministically, and releases the useful structure as free and open-source software. It is not a claim that every use of AI is ethical.

People have different views and personal experiences with AI, including harmful ones. Those experiences deserve respect. Enthusiasm for this narrow use is not a demand that anyone share it.