Changing Distribution Platforms
In The Beginning
When I made the first pre-alpha builds available to testers I needed a simple and somewhat convenient way to distribute them.
Back then there were not that many options:
The latter was, what I started out with: a simple script 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 want to set up a limited corporation in Austria, which has steep initial capital requirements, recurrent 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 limited 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 for 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 single one of my testers already uses Discord, there is no friction for the 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.
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 here 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 just assume this is not the case. On the other hand, there were certain optimizations I never came around to implement in Metal. 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.