Vectropolis

v0.1.1

2025-12-04T00:00:00+00:00

A round of polish and platform love—because your feedback matters (yes, especially</em> the bug reports).</p>

This is a preproduction technical demo. At this stage, it’s more of a tech demo than a game, and it may not be pretty, fun, or even start up successfully.</p> </blockquote>

Announcing technical engine builds 2025-11-06T00:00:00+00:00 The eagle-eyed among you will have noticed a new Downloads</a> link. That means the first preview technical engine builds are available for you to try.</p> This is a preproduction technical demo. At this stage, it’s more of a tech demo than a game, and it may not be pretty, fun, or even start up successfully.</p> </blockquote> You may notice the number of platforms supported is suspiciously</em> high.</p> </i></a> Platform economics</h1> Traditionally, game developers targeted a single flagship platform, usually PC or console. If the game sold extremely well, or had an online live service component, perhaps there would be budget to hire a third-party subcontractor to port it to something else after launch. Some</a> of these ports are incredible</a>. But usually, they’re not, for predictable reasons: the game has already been designed around different hardware, budget and appetite to rework it around a 2nd place platform is extremely limited.</p> Partly to ship on multiple platforms on day one, these days the tendency is to use a Big Game Engine to paper over low-level platform details (for reasons I will dive into in a future post, Vectropolis can’t use Big Engine and needs to follow a more traditional indie engine path instead). In theory, Big Engine makes it easy to kick out a build for any</a> of over twenty</a> platforms. In practice, developers mostly don’t. Why not?</p> For the purposes of game preservation, it sure would be convenient if some heroic engineer exported their Unity build to the 20 platforms on a flash drive. Unfortunately if you’re in a position to try that on your work computer, it’s just the start of your problems, actually shipping any of those ports would require meetings</em>. The CI team needs another machine to build that architecture, web team needs a folder to put it in, the publisher’s SDK isn’t shipped on that platform, our DRM system doesn’t work there, and by that time you have alerted a beancounter to the fact that macOS and Linux combined is less than 5% of our marketshare, and won’t Proton eventually get there anyway?</p> </i></a> Strategy</h1> I’d like to try something different. I’d just like to cross-compile Vectropolis for far too many platforms and just see what happens</em>.</p> Ideally, I replicate the finding that Linux users generate more and better bug reports</a>, but the only way to find that out, is to test it!</p> Side note, if you’re interested in a platform I’m not building for, please send feedback</a> to discuss if I can kick out a build for your platform.</p> </i></a> Platforms</h1> Platforms will be cut or be changed in the final release. Those on minority platforms would be well-served by aggressively and professionally reporting bugs to feedback</a> to document their interest and value in minority platform support. See also the Rust book</a>.</p> </blockquote> System requirements are definitely going to change over the course of development.</p> </blockquote> </i></a> Windows</h2> This is usually considered the flagship platform and the obvious one to support. However, each release it grows increasingly user-hostile</a>.</p> At the moment there is DX12 support across both x64 and arm64 Windows builds.</p> </i></a> Linux</h2> This is an up-and-coming gaming platform that might be worth taking much more seriously than relying on Proton-emulated APIs.</p> At the moment there is Vulkan support across x64 and arm64 Linux builds.</p> </i></a> macOS</h2> Apple is notoriously difficult for game developers, however there is a suspicioiusly well-tested native Apple Silicon port with a native Metal backend.</p> It will not be ported to Intel.</p> </i></a> web</h2> The general intuition is, a web version might be a good marketing strategy, especially for a live early demo with few entities. It suffers from many practical problems:</p> webGPU is not totally supported yet</li> wasm32 has a hard 4GB cap, and often the cap is more like 0.5GB</li> there are many reasons the wgpu spec requires duplicating allocations between GPU and CPU</li> </ul> v0.1.0 2025-11-06T00:00:00+00:00 This is the first runnable technical demo of Vectropolis.</p> This is a preproduction technical demo. At this stage, it’s more of a tech demo than a game, and it may not be pretty, fun, or even start up successfully.</p> </blockquote> </i></a> Features / test areas</h1> Movement system - WASD + point/click</li> Terrain generation</li> Terrain rendering</li> Road rendering</li> Lighting</li> GUI library (click on a vehicle)</li> Font/text rendering</li> </ul> </i></a> Known issues</h1> No loading screen (812)</li> On browsers that don’t support WebGPU, engine fails to load / loads to a white screen (809)</li> On some browsers, engine hangs shortly after launch (787)</li> Accessibility (810)</li> Text fails to render in chrome (811)</li> terrain geometry clips / has holes (813)</li> Road clips (814) because the terrain is too steep for a road here</li> UI rendering has multiple performance issues</li> </ul> </i></a> Downloads</h1> </i></a> Windows</h3> Windows (x64)</a></li> Windows (ARM64)</a></li> </ul> </i></a> macOS</h3> macOS (Apple Silicon / ARM64)</a></li> </ul> </i></a> Linux</h3> Linux (x64)</a></li> Linux (ARM64)</a></li> </ul> Announcing the online rough tech demo 2025-10-23T00:00:00+00:00 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</strong></a> that opens a live, in-browser preproduction engine build.</p> TL;DR:</strong> I’m publishing rough, sometimes-broken demos on purpose. I believe you can handle it, and early feedback beats late polish.</p> </blockquote> </i></a> Why most studios hide the rough edges</h1> There’s a standard playbook:</p> Out-of-engine cinematic first, gameplay last.</strong> The safest way to “wow” without risk—at the cost of accuracy.</li> Carefully controlled demos.</strong> One curated presentation, one hardware target, one press beat, embargo dates, streamer agreements…</li> Silence during preproduction.</strong> The belief: if players see grayboxes or placeholder art, they’ll “misunderstand,” churn, or punish the studio.</li> </ul> The subtext is simple: players can’t handle it</strong>. Studios think you need coddling, not candor.</p> </i></a> I don’t buy that</h1> Players aren’t fragile; they’re frustrated</strong>, and in the city building genre and after so many</a> high-profile failures</a>, everybody’s out of patience. We’ve learned to read glossy trailers</a> as marketing, not information. We’ve seen “vertical slices” that don’t represent the shipped game</a>. And we’ve watched day-one patches</a> carry the weight that production never did.</p> What this genre needs now is straight talk</strong>: 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.</p> Trust is built by letting people see you make the thing, not by pretending you never struggled.</strong></p> </blockquote> </i></a> The bargain I’m proposing</h1> 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:</p> This is preproduction.</strong> Expect crashes, hangs, bugs, pop-in, poor optimization, placeholder art, and much more. Check the release notes</a> for known problems.</li> Honest constraints.</strong> Browser is more limited than native, your hardware may be different than mine.</li> Scope in motion.</strong> Game design is 100% experiment. Every feature may disappear, morph, or ship later. That’s design, not duplicity.</li> No gotchas.</strong> What you see is what the status is.</li> </ol> In exchange, just send me honest feedback. Join the Discord</a>, tell me what you like and don’t like, or what you’d like to see added to the game.</p> </i></a> Common objections (and my answers)</h1> “But first impressions matter—won’t this hurt you?”</strong> Only if it’s presented as finished. Presenting it as “barely started” turns bad builds from a liability into a conversation.</p> “Competitors will copy you.”</strong> Maybe! But execution beats secrecy, and community trust is tough to clone.</p> </i></a> Why this matters way beyond one demo</h1> Games are systems. Systems get better through iteration with reality</strong>, not presentation decks. If we want durable, interesting simulations instead of disposable spectacles, we have to normalize showing becoming</em>, not just being</em>.</p> So yes—sometimes you’ll see the scaffolding. That’s the point. If you stick around, you’ll also see it come down.</p> If you try the build:</strong> 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.</p>

Vectropolis

v0.1.1

</i></a> Fixed</h1> WebGPU compatibility</strong> - Browsers that don’t support WebGPU now get a friendly heads-up instead of a mysterious white void (809)</li> Chrome text rendering</strong> - Upgraded our text engine, so text actually shows up in Chrome now (811)</li>

</i></a> Added</h1> Heartbeat process</strong> - The engine now has a pulse! Added a heartbeat to our UI layer for improved stability and responsiveness</li>

</i></a> Changed</h1> Improved logging</strong> - Better diagnostics for easier debugging</li> Dependency updates</strong> - Freshened up our internal libraries</li>

</i></a> Known issues</h1> No loading screen (812)</li> Performance freezing on launch in some cases (815)</li> Accessibility (453)</li> Terrain geometry clips / has holes (813)</li>

Announcing technical engine builds

v0.1.0

</i></a> Features / test areas</h1> Movement system - WASD + point/click</li> Terrain generation</li> Terrain rendering</li> Road rendering</li> Lighting</li> GUI library (click on a vehicle)</li>

Announcing the online rough tech demo