Changing Distribution Platforms

In The Beginning

To make the first pre-alpha builds available to testers I needed a simple and somewhat convenient way to distribute them.

Back not that many options were available:

• itch.io
• Steam
• home-grown solution

The latter was, what I started out with: a simple webpage that used Steam-authentication to restrict downloads to certain SteamIDs. This way I could look up the SteamID for my testers and give them access to the required files. However this meant testers had to manually download new versions. Far from convenient. While I used it for the earliest hardware-compatibility tests, I dismissed this option rather quickly.

Steam would have been the most convenient option for the testers as well as for me. But Steam is either all-in or not-at-all. To distribute my closed alpha builds on Steam I would have had to go through the full shenanigan, just like starting to sell the game. This includes all kind of tax information, requiring me to register a tax number with the IRS. For this, however, I first wanted to set up a limited corporation in Austria, which has steep initial capital requirements, recurring costs and an administrative overhead. (And we are talking a few 1000s of Euros, not just a few 100 - just as an aside for everyone who complains about spending a few hundred USD to setup a LLC in their respective jurisdiction. Consider yourself lucky..) So I prefer to postpone this step as long as possible. Thus Steam as distribution platform was out.

itch.io turned out to be perfectly placed in the market back then. No need for any tax information as long as I do not plan to receive payments, easy to upload new builds and automated updates for the testers (if they are using the itch.io client). It also has support for devlogs and of course the required and well handled access restrictions for setting up closed alpha testing.

One year later - Why make the switch from itch.io to Discord?

The problem with itch.io was that none of my testers used it otherwise. Heck, I had people ask me how the game was progressing despite them having access to it, resulting in awkward stares and "Oh yes, you are right, stupid of me to ask. .. Uh.. What was the name of that website again?". Sadly itch.io is very much a niche player mostly frequented by developers, hardcore indie-fans and the like.

Luckily enough for me, at the beginning of this year Discord announced their own self-managed distribution program. Since every one of my testers already used Discord, there was no friction for them testing the game. They all have the Discord client installed and thusly can benefit from auto-updates. Discord also made the right decision that distributing a game without taking money for it does not require tax-information up front. Only when the game is ready to be sold this information is required. Just like with itch.io.

As you can guess, this was not a difficult decision to make. It also allowed me to start integrating cloud saves on Discord as well as achievements when (not if) they start supporting them.

Vulkan emits Molten apple juice Metal

When I tried to use Vulkan on macOS via MoltenVK more than a year ago it failed to compile my shaders and I left it at that, thinking that it is not my fault but bugs in spirv-cross. But with the game progressing and the Metal backend falling behind the Vulkan one even more, I had to consider my options for macOS: either spend a few (many?) days working on the Metal backend or see if I feel lucky and try MoltenVK again. I opted for the latter and encountered the same error as last year during shader compilation. This time however, I was motivated to figure out what my shaders were doing exactly, for spirv-cross to fail at generating MSL-shaders.

Turned out it could not handle the definition of a struct within a uniform block. While the uniform block was handled correctly, the actual type definition was not emitted in the Metal shader code and thusly compilation failed. By moving the definition out of the uniform block all the shaders compiled perfectly. And with the odd changes here and there (only 2, really) MoltenVK was up and running in less than 2 hours. Margin Magnate now looks just as good under macOS as it does under Windows. From now on the only backend used in Margin Magnate is the one for Vulkan. This removes a huge maintenance burden for me, which is always great.

In regards to performance I do not have concrete measurements since the backends did not have feature-parity anyway. Only subjectively speaking I do not notice a degradation in performance. In fact, it feels like it is even somewhat more performant than it was before. But since I have no numbers to back this up, I prefer to err on the safe side and say, that this is not the case. On the other hand, there were certain optimizations I never came around to implement for the Metal-backend. Maybe MoltenVK applies them behind the scenes and it really is faster.

No matter what, it is great to be able to fully concentrate on Vulkan from here on out, as it is a joy to work with.