We built Client City to show what we could do, to give our clients a living portfolio that walked through their own sites and to push the limits of what a browser can render. When we finished the sixth version – a cozy town with a square, a well, benches, lanterns and a handful of client houses – we had a piece of code that was both elegant and, more importantly, reusable.
The decision to open‑source it was not a marketing stunt. It came from a simple, honest assessment: the engine was a solution that many people would benefit from, and keeping it locked behind a paywall would only slow the community we serve. We are a remote‑first studio that thrives on collaboration; we want to give back to the same ecosystem that helped us grow.
The Engine as a Tool, Not a Treasure The Three.js foundation we used for Client City is a common starting point for many developers. Our work added a few layers: heightmap terrain, photo‑real CC0 materials from Poly Haven, splat maps, instanced pine trees, oriented‑box collisions, a compass bar, signposts, and a road‑following fast‑travel system. None of these components are novel on their own, but the way we stitched them together, the optimisations for mobile, and the modular architecture make the whole package surprisingly lightweight and easy to extend.
When we open‑source the code, we are essentially saying, “Here’s a ready‑made playground you can build on.” A festival team could drop in, replace the client houses with event booths, and add a live‑streaming widget. A small e‑commerce shop could use the same terrain engine to create a virtual storefront that feels more like a game than a catalog. The possibilities are endless, and the fact that the code is MIT‑licensed removes the legal friction that often deters small teams from experimenting.
Trust Through Transparency We are a one‑person studio; every line of code is written, reviewed, and tested by a single hand. That transparency is a double‑edged sword: it gives us confidence in the quality of our work, but it also means that any flaw we introduce is ours alone to fix. By releasing the engine, we invite the community to audit it, to point out bugs, and to suggest improvements. In return, we get a pool of eyes that can spot edge cases we never imagined.
The open‑source route also signals a cultural shift. We are no longer just a service provider; we are a contributor to a broader creative ecosystem. When a client sees that we’re willing to share our core technology, it builds a deeper trust. They know we’re not hiding anything behind a proprietary wall; we’re building for the long haul, not for a quick sale.
A Practical Path Forward Open‑source doesn’t mean we abandon our business model. We still build custom solutions, run our own products like FestOps and ADHDwear, and maintain Client City as a showcase. The engine, however, becomes a reusable asset that can generate value for others without diluting our brand.
We’ve already seen a few developers reach out after the release. Some are remixing the terrain for a virtual conference platform; others are using the collision system for a simple physics demo. Even if they never use it, the mere act of sharing keeps the code alive, ensures it evolves, and keeps us honest about our own practices.
We do not promise that every line of code will be perfect, nor that the engine will solve every problem. We simply believe that the best way to improve a tool is to let others use it, test it, and iterate on it.
The decision to open‑source the thing we were proudest of was a step toward a more collaborative future, a gesture that respects both our craft and the community that nurtures it.
What would you build if you had a ready‑made 3D engine that could be customized to your needs?