Turning the Workshop Into a Working System

A local system with a proper job

The AI side of TW Farms spent a proper stretch exploring: try a setup, learn from it, move on. That was the right way to start, and a poor way to continue once the work became a real project. The workshop is now being organised into a working development environment.

R.I.L.E.Y. is running locally, using NVIDIA Nemotron 3.5 Lightning 30B through llama.cpp. Behind the long name, that model is serving the workshop from the studio machine. Local is a deliberate choice. The project stays here, the start-up is ours to govern, and the assistant is on hand for the work in front of us.

Around that model there is now a proper bridge, an MCP and tooling layer, governance and start-up rules, and a structured TW Farms workspace. The bridge is the controlled doorway between the model and the workshop. MCP, the Model Context Protocol, is a defined way for an assistant to use tools, so R.I.L.E.Y. can take part in the work inside a clear boundary. The start-up rules bring the system up the same way each time, with the person directing it still in charge of what it is for.

R.I.L.E.Y. has already been used for real development and maintenance, alongside the conversations that help a problem get thought through. It can stay with a job now: development work and ordinary project upkeep, inside rules set on purpose. I still choose the direction and judge what is worth keeping. The assistant takes on effort that would otherwise eat the day. The creative decisions stay with the creator.

One tool, owned by the person using it

Farm Forge is Priority One. The intention is a standalone map-development tool: intuitive enough for a map maker to understand, and built so the creator stays in control. In time it should help with terrain, roads, routing and the other groundwork that currently takes a great deal of careful, repetitive work. Approachable matters as much as capable. A tool that needs a guided tour before it will help lay out a track has missed the people it was meant for.

GIANTS Editor and Unreal Engine have both been part of the exploration, and that history stays on the record. The foundation we are building is lighter and independent: a Farm Forge we understand, shaped around the way map makers actually work.

So the present task is consolidation before any further expansion. Another experiment piled onto an untidy project feels like movement right up until you have to work out which copy was the real one.

Two histories, compared on purpose

While the project was being pulled together, two historic Farm Forge source trees turned up. Both contain work that was done for a reason. They are being compared carefully and merged into one canonical project, with the useful parts kept. The next build needs a single source worth trusting.

The Python source merge matrix for the main source files is complete, and the identical files are identified. The same work, found twice, can be treated as such. Classification of the rest is still underway: NVIDIA material, Unreal material, experiments, tools, assets and documentation. That slower half decides whether the merge becomes a clean project or a larger mess with neater folder names.

SHA-256 duplicate checking is part of the same consolidation, alongside a wider structural audit. A SHA-256 hash is a fingerprint for a file, so matching fingerprints mean matching contents even when the folders disagree. The audit then asks whether the project around those files hangs together, or whether two different ideas of Farm Forge have been inherited. Settling that now is dull in the best way. It keeps us from rebuilding a solution we already had.

What the experiments are allowed to keep

Some of the existing work earns a close look immediately.

Terrain work already in the project includes Madison terrain handling, ASCII grid terrain support, and A* routing experiments. An ASCII grid writes terrain as plain text values: modest, inspectable, and movable without a heavy editor. That accessibility matters when the job is to understand the ground. A* is a classic method for searching out a path across a grid, used here as an experiment in how a route might cross terrain data. It is early work towards roads and routes that respect the landscape, and it is being preserved while we evaluate it.

NVIDIA and Omniverse work has been explored successfully, including an early USD proof of concept. USD, Universal Scene Description, is a shared way to describe a 3D scene so tools can pass it between them. The proof of concept shows that this path can work at a small scale. It stays with the rest of the NVIDIA material while the audit decides where it belongs.

The Unreal Engine work is being retained as reference. It answered questions, and those answers ought to stay within reach. The architecture we are choosing is a lighter, independent foundation: closer to the map maker, easier to reason about, and able to grow on its own terms.

Madison remains the first major real-world target. Anything that survives the audit has to help that map, or help the tool that will build it. A road that follows the terrain, chosen by the person making the map, is still the kind of result Farm Forge is being shaped for. First comes the clean project. Then a build we can use and judge.

What's Next

• Finish the Farm Forge consolidation.
• Complete the duplicate and conflict audit.
• Organise the modules that survive into a structure that can be worked in.
• Continue the terrain and routing work already in the project.
• Begin turning those surviving foundations into the next usable Farm Forge build.

That next build should be something we can try on Madison and learn from quickly.