Future Games and Mac Support

It's my first ever commercial game contract. I'm still technically in school, but whatever, it's just a summer job. I'm supposed to be doing some audio programming for a game called Waveform, which was newly released but was only available on Windows. "Whatever," I thought, "I'll just make a Linux version for myself and maybe pitch that later." Discussion of the audio work continues, and I make the implication that I'll effectively be doing a Linux port on the side.

"Well, we were thinking about doing a Mac version anyway, do you want to do that instead?"

And thus, my first port is born. 4 months later, Valve announces Steam for Linux and Humble contacts me with a bunch of work ready to start. A whole business is born. Accidentally.

That was almost 9 years ago! A lot has changed since then - in particular, my pitches have changed quite a bit. Back in 2012, Humble Bundle was at its height and games were getting Linux/OS X versions like crazy. The way you would usually pitch a Linux version was by pitching a Mac version first, then you'd show them both builds and be like "lol, fooled you, they're actually the same!" That worked pretty well ~5 years ago, but these days it's not the best plan. Apple has changed course significantly with the Mac, and in pretty major areas - the removal of their only standard graphics library is the change everyone has already beaten to death. As they have diverged further and further away from open standards, the ability to build for one and then quickly build for the other has gotten less and less possible for developers who don't have a lot of resources (and the resources are dwindling), meaning eventually they may have to pick between one or the other.

I moved back in November and I spent all of December just cooling down after a remarkably tough year, both professionally and personally. Part of that was putting together the new office, which has been upgraded from 5 computers and multiple devkits shoved into a corner desk in an apartment with a single ethernet cable literally duct-taped to the baseboards across two rooms and a fireplace (seriously) to a whole room with actual tables and actual thought put into the wiring and layout of things. Looking at all the hardware, I noticed one bit that stood out - the trusty flibitMacBook, the original MacBook that has built every Mac game I've ever shipped. It still runs Mojave, as I didn't want to ruin it with Catalina, and it turns out it isn't compatible with Big Sur anyway. And of course, it is running an Intel processor. Intel Macs will be going away soon, and Mojave is going to hit end-of-life this year. It's still the best laptop I've ever owned, but it's on its way out. I could possibly get a new MacBook, but for what I've gotten from Apple as a developer these past few years, I don't think I can comfortably give anything to them as a customer anymore, certainly not on the desktop front.

I've put it off for as long as I could, but after looking at Apple's trajectory vs. my own infrastructure for Mac support, it's looking like 2021 is the year that I have to say goodbye to the Mac as a primary target. This is a huge change that affects a number of my existing customers, so let's establish the important part first: I will continue to support my current Mac games for as long as I physically can. You bought a Mac version, you're keeping that Mac version. I didn't put out posts like this one for nothing. You gave me your money and have treated me very well this past decade, this house I'm working in wouldn't be my home without both Linux and Mac customers, you deserve at least some of my attention based on that alone. A lot of studios have been taking away your games lately, those studios are dickheads. Besides, the whole point I'm trying to make is that I'm not taking away your games, Apple is. I'll even attempt to build Apple Silicon binaries and support that hardware as well if it seems like it's easy to do without first-hand testing (admittedly a bit lofty to attempt, but considering I'll probably have to support Aarch64 on Linux/Windows soon anyway it doesn't seem crazy).

New games, however, will primarily be Linux (and Windows, if applicable) only. If a studio really twists my arm (we're talking "you get all the royalties" level of twisting) I'll think about it, but otherwise I'll instead defer to others who have become Apple experts and are now better suited to replace me in that role. I thought about putting it in the second tier along with consoles (which are now my gateway port to Linux instead, bizarrely enough), but considering the endgame is very clearly to make macOS more like iOS/tvOS (another subject that has been beaten to death, please don't e-mail me about this), it will almost certainly end up being in that category instead; that is to say, I'll help other developers support it but I won't be involved myself.

The "preserve the old, trim down the new" model makes the most sense to me. It still respects my existing customers, but doesn't permanently trap me into a loop where I half-support macOS because I did before, but it attracts new Mac customers that I now also have to support, but it won't be good support since I can barely run new Mac apps myself anymore... etc etc. Sure, my old games still get bought, but there's nothing quite like a brand new launch. In a way, I'm hoping to see a lot of Mac customers turn into Linux customers over time, so maybe I'll be able to see some of you again on a different platform.

Could I have learned my way around modern macOS and tried to preserve that part of the company? I dunno, maybe eventually. These past few years have spawned an absurd amount of new technologies, many of them absurdly complex - Vulkan alone has been a multi-year learning process and I still barely understand a large portion of the spec. But in Vulkan's case, I wanted to learn to use it. Metal may be nicer to look at in comparison, but beauty is only skin-deep - any multiplatform developer will tell you that Mac drivers still haven't improved despite Metal happening, and reporting bugs to Apple when you're not rich is like pulling teeth with boxing gloves. Contrast that with Linux, where Vulkan is in some places downright appalling, but when we run into driver problems I just post a RenderDoc capture on the Mesa issue tracker and get a response (and sometimes even a commit hash!) usually on the same day. As software continues its unabated exponential curve of complexity, having access to both the software stack (in its entirety) as well as the communities that build it all will be critical, and the contrast of Apple getting bigger and more reclusive while independent developers get smaller and more desperate is something I can't ignore. (Indies are kind of in the middle right now, and of course AAA never really cared.)

It has been a really incredible decade, and again: Mac users have treated myself and my clients extraordinarily well in that time. I just wish Apple was that kind to us as well. But, what can you do, independent games just don't have the same financial appeal as collecting credit card interest and reviving the workout VHS genre. I can only hope laptop manufacturers have improved since 2012, because I still remember the selection back then... good grief.

GitHub Sponsors!

I'm happy to announce that I am now in the GitHub Sponsors program! This means that anyone with a GitHub account can now subscribe to a monthly payment system that will allow me to continue my work maintaining the numerous FOSS game development projects that I maintain, including FNA and FAudio.

You can find my sponsorship profile here.

If you're on the fence about this, I'll give you quite the incentive: Microsoft is skipping all payment processing fees, so in addition to taking extra money out of Microsoft's pocket (which I think my audience will take some joy in...), everything you pledge will go directly to me. A slight change of pace from Patreon's usual scams, hm?

I've been very vocal about the poor state of the crowdfunding ecosystem, and I think the GitHub Sponsors program is very much what we've all been looking for. I think you'll agree, and I hope you'll pledge what you can!

Want a Linux game?

I have my own hit list as always, but I'm always looking for more projects! Now's a really good time to hit me up while it's on my mind. Don't forget, whether you're an indie developer or an independent developer, there's a good chance I can accommodate your needs!

Love, flibit
flibitijibibo.com

Bill's Hat

Turn a minimal Fedora installation into a SteamOS box!

1. Write Fedora Workstation NetInstall ISO to a USB drive
2. Boot USB image, install Minimal configuration with standard partition layout matching SteamOS'
3. Set root password, create a user called 'steam', set a password for it
4. Reboot, log in as root
5. A whole bunch of commands:

dnf group install hardware-support
dnf install Xorg xorg-x11-drv-evdev libglvnd-egl vulkan-loader.x86_64 vulkan-loader.i686 lightdm flatpak NetworkManager-wifi kernel-modules-extra bluez
dnf config-manager --add-repo=https://negativo17.org/repos/fedora-steam.repo
dnf install steam steamos-compositor steamos-modeswitch-inhibitor.x86_64 steamos-modeswitch-inhibitor.i686
setsebool -P allow_execheap 1
systemctl enable sshd.service
systemctl enable lightdm.service
systemctl set-default graphical.target

6. Edit /etc/lightdm/lightdm.conf:

pam-service=lightdm-autologin
pam-autologin-service=lightdm-autologin
user-session=steamos
autologin-user=steam
autologin-session=steamos

7. Create /var/lib/AccountsService/users/steam:

[User]
Session=steamos
XSession=steamos
Icon=/home/steam/.face
SystemAccount=false

8. Reboot, should work now!

9. Additional steps for NVIDIA users:

dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
dnf install kernel-devel dkms-nvidia nvidia-driver-libs.x86_64 nvidia-driver-libs.i686
reboot # Should be using the NVIDIA driver now!

flibitBuild

Want to replicate my build machine? Grab CentOS 7 and have a look...

# Update base install before doing anything else
yum update
# Add EPEL
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# Add SCL
yum install centos-release-scl
# All the base build tools!
yum install bzip2 bzip2-devel clang cmake cmake3 gcc-c++ git hg \
    libcxx-devel libstdc++-static libuuid-devel libxml2-devel llvm-devel \
    lzma-sdk-devel openal-soft-devel openssl-devel patch svn yum-utils \
    yum-plugin-copr
# SDL2 dependencies
yum-builddep SDL2
# Coprs for MinGW as well as GCC 8, needed to build Clang/LLVM/osxcross
yum copr enable mlampe/devtoolset-8
yum copr enable alonid/mingw-epel7
yum install devtoolset-8 mingw32-* mingw64-*

# CMake3 by default
alternatives --install /usr/local/bin/cmake cmake /usr/bin/cmake 10 \
    --slave /usr/local/bin/ctest ctest /usr/bin/ctest \
    --slave /usr/local/bin/cpack cpack /usr/bin/cpack \
    --slave /usr/local/bin/ccmake ccmake /usr/bin/ccmake \
    --family cmake
alternatives --install /usr/local/bin/cmake cmake /usr/bin/cmake3 20 \
    --slave /usr/local/bin/ctest ctest /usr/bin/ctest3 \
    --slave /usr/local/bin/cpack cpack /usr/bin/cpack3 \
    --slave /usr/local/bin/ccmake ccmake /usr/bin/ccmake3 \
    --family cmake

# Also:
# Modify unistd.h to change __block to anything but __block
# The CMake config provided by SDL2-mingw is terrible, delete the block
#  that starts with "if(NOT TARGET SDL2::SDL2)".
# Be prepared to pass -std=gnu99 manually. A LOT.

# To enter Mac building mode (and to build osxcross itself):
# scl enable devtoolset-8 bash

Wait, a "plan"?

Well, this is a .plan file, so here's my TODO. Expect nothing from it, ever.