In the last post, I discussed using a “radically open preproduction process.” The eagle-eyed among you might notice there’s now an Online rough tech demo that opens a live, in-browser preproduction engine build.

TL;DR: I’m publishing rough, sometimes-broken demos on purpose. I believe you can handle it, and early feedback beats late polish.

Why most studios hide the rough edges

There’s a standard playbook:

• Out-of-engine cinematic first, gameplay last. The safest way to “wow” without risk—at the cost of accuracy.
• Carefully controlled demos. One curated presentation, one hardware target, one press beat, embargo dates, streamer agreements…
• Silence during preproduction. The belief: if players see grayboxes or placeholder art, they’ll “misunderstand,” churn, or punish the studio.

The subtext is simple: players can’t handle it. Studios think you need coddling, not candor.

I don’t buy that

Players aren’t fragile; they’re frustrated, and in the city building genre and after so many high-profile failures, everybody’s out of patience. We’ve learned to read glossy trailers as marketing, not information. We’ve seen “vertical slices” that don’t represent the shipped game. And we’ve watched day-one patches carry the weight that production never did.

What this genre needs now is straight talk: real performance numbers, honest scope, and runnable, testable demos. When a studio shows work-in-progress with context, I think players won’t punish the roughness—they appreciate being treated like adults.

Trust is built by letting people see you make the thing, not by pretending you never struggled.

The bargain I’m proposing

I’d like to show you my terrible builds, half-shipped features, and bad designs. In return, I’m asking for feedback delivered in good faith so I can improve all three. Here’s the working agreement:

1. This is preproduction. Expect crashes, hangs, bugs, pop-in, poor optimization, placeholder art, and much more. Check the release notes for known problems.
2. Honest constraints. Browser is more limited than native, your hardware may be different than mine.
3. Scope in motion. Game design is 100% experiment. Every feature may disappear, morph, or ship later. That’s design, not duplicity.
4. No gotchas. What you see is what the status is.

In exchange, just send me honest feedback. Join the Discord, tell me what you like and don’t like, or what you’d like to see added to the game.

Common objections (and my answers)

“But first impressions matter—won’t this hurt you?” Only if it’s presented as finished. Presenting it as “barely started” turns bad builds from a liability into a conversation.

“Competitors will copy you.” Maybe! But execution beats secrecy, and community trust is tough to clone.

Why this matters way beyond one demo

Games are systems. Systems get better through iteration with reality, not presentation decks. If we want durable, interesting simulations instead of disposable spectacles, we have to normalize showing becoming, not just being.

So yes—sometimes you’ll see the scaffolding. That’s the point. If you stick around, you’ll also see it come down.

If you try the build: thank you. You’re helping steer something that’s still taking shape, and that’s the kind of collaboration it will take to make this a reality.