Vectropolis

Announcing technical engine builds

The eagle-eyed among you will have noticed a new Downloads link. That means the first preview technical engine builds are available for you to try.

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.

You may notice the number of platforms supported is suspiciously high.

Platform economics

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 of these ports are incredible. 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.

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 of over twenty platforms. In practice, developers mostly don’t. Why not?

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. 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?

Strategy

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.

Ideally, I replicate the finding that Linux users generate more and better bug reports, but the only way to find that out, is to test it!

Side note, if you’re interested in a platform I’m not building for, please send feedback to discuss if I can kick out a build for your platform.

Platforms

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]((https://vectropolis.city/feedback/) to document their interest and value in minority platform support. See also the Rust book.

System requirements are definitely going to change over the course of development.

Windows

This is usually considered the flagship platform and the obvious one to support. However, each release it grows increasingly user-hostile.

At the moment there is DX12 support across both x64 and arm64 Windows builds.

Linux

This is an up-and-coming gaming platform that might be worth taking much more seriously than relying on Proton-emulated APIs.

At the moment there is Vulkan support across x64 and arm64 Linux builds.

macOS

Apple is notoriously difficult for game developers, however there is a suspicioiusly well-tested native Apple Silicon port with a native Metal backend.

It will not be ported to Intel.

web

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: