GBGames

Last time, I reported that I was working on automating the release builds for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Due to other priorities taking up my time, this effort is still ongoing, and for much longer than I would like.

Sprints 2026-MJ_5 and 2026-MJ_6: Release SDL3 update version

In progress:

• Ensure Mac version can still be built/deployed

To recap, back in October, I started the work of updating Toytles: Leaf Raking from libSDL2 to libSDL3. I had expected that it might take me a week or two at most, assuming I could put in the hours.

It was mostly straightforward and quick to do except for when it came to dealing with libSDL3_mixer, which was significantly different enough from libSDL2_mixer in design that it required some rearchitecting of my own code.

I spent weeks of calendar time on that effort, even though it only represented a handful of hours of game development in all of December, and I finally finished at the end of January.

Next was putting out a new release on every platform that I support. Linux was easy, as I do my development there, and the scripts I use to make a release are mostly the same.

The Windows port took a couple of weeks, although it represented again only a handful of hours of effort, and most of this effort was trying to make sure that the next time I want to cut a release will be automatic and fast.

And here I am, still working on the Mac port, and the story is similar. In the last couple of weeks, I put in only a little more than 5 hours of game development time in. Which is too bad, because I really needed to put some time in to solve this one.

Warning: the following gets a bit technical.

Basically, to release a Mac build, I want to make sure my game supports both Intel-based Macs and the Apple Silicon-based Macs. Apple provides a way to do so with the so-called “fat” binary, or Universal Binary. Basically, it’s one application that can run on either one of the hardware options without the player needing to worry about it.

Of course, to build it that way, you need to explicitly configure the build to support both architectures.

Last time, I did so by manually building libSDL2 and my game on my Intel-based Mac Mini, then copying the binaries to my Mac in Cloud instance of an M1-based Mac, building new libraries there, then using lipo to combine the libraries into a Universal Binary version, then building the game with those libraries.

This time, I don’t want to do it manually, and I don’t want to depend on two different Macs. I want to make this part automated as well.

Now, SDL3’s documentation mentions how to build a Universal Binary for the Mac:

cmake .. "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13

And if I extract the SDL3 source code and use cmake manually, it works just fine.

However, because I wanted to automate this build as part of my own project’s build scripts, I wanted to have my project’s cmake scripts configure and build SDL3 and all of the other SDL3-based libraries.

And it felt like no matter how I tried to make things work, CMake was doing the most surprising wrong things and never the right thing in terms of passing the CMAKE_OSX_ARCHITECTURES variable to SDL3’s cmake scripts.

Now, I think CMake and CSS have something in common: it’s relatively easy to put together something that seems to work but might have fundamental flaws based on misunderstanding or ignorance of how it is supposed to work.

For CSS, things felt a lot less random once I put in time to understand the Box Model. I was no longer randomly trying different values for margins or padding to get things to line up.

CMake, on the other hand, continues to be a challenge for me to learn. The docs are great…once you know how everything works, but until then, they seem quite abstract and confusing.

Anyway, I spent a few hours trying to figure out why the following cmake script would not result in the cmake command above:

SET(SDL3_CONFIGURE_ARGS
    "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64"                                                                                           
    "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.15" 
        -DCMAKE_INSTALL_PREFIX=${TARGET_INSTALL_DIR})                                                                                  
 
MAKE_DIRECTORY(${PROJECT_BINARY_DIR}/${SDL3_EXTRACTED_DIR}/build)                                                                      
ADD_CUSTOM_TARGET(SDL3_SHARED_LIBRARY                                                                                                  
                  ALL                                                                                                                  
                  ${CMAKE_COMMAND} ${SDL3_CONFIGURE_ARGS} ..
                  COMMAND make
                  COMMAND make install
                  WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${SDL3_EXTRACTED_DIR}/build
                  COMMENT "BUILDING libSDL3")

As an explanation, I am creating the SDL3_SHARED_LIBRARY target as a custom command. It calls cmake with some arguments (SDL3_CONFIGURE_ARGS), then runs make and make install.

Now, you’ll notice that I have the arguments separate from the command. I have a few, including a target install directory that I want to specify. I don’t want to install to the Mac’s system. I want it to be in a known location for my own build.

And when I didn’t have the -DCMAKE_OSX_ARCHITECTURES argument specified, it would just build on the native architecture of the Mac I happened to be building on. It would specify the deployment target and the target install directory correctly.

That is, passing SDL3_CONFIGURE_ARGS to my custom target’s cmake command worked just fine.

But once I added the -DCMAKE_OSX_ARCHITECTURES argument with two values separated by a semicolon, it stopped interpreting things correctly.

In the above case (which wasn’t my first iteration, by the way), it would build the arm64 version. The semicolon seemed to get interpreted in a way that it was treating it as the end of the command, so x86_64 was seen as a new command.

That’s annoying. What about if we add VERBATIM to the invocation of ADD_CUSTOM_TARGET()?

Well, all that does is treat SDL3_CONFIGURE_ARGS as a single argument being passed to cmake. That is, instead of three separate arguments, it’s one big one…and completely wrong.

Also annoying.

I tried escaping quotes, quoting around escaped quotes, having no quotes, and using or not using VERBATIM for each case. I just kept getting the semicolon treated as the end of a command, leaving x86_64 as a completely separate command, or I got it to treat arm64;x86_64 as a list to expand (so it passed along “arm64 [space] x86_64”), or that one long argument.

I just couldn’t get it to do what I wanted, which was to pass along the arguments as I actually wrote them.

In the end, I found that the problem goes away when I don’t try to use a variable that represents multiple arguments, which makes CMake treat it as a list to sometimes expand or not based on some seemingly non-intuitive rules. I instead now use a separate argument:

SET(MULTI_ARCH_ARG
    "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64")

SET(SDL3_CONFIGURE_ARGS
    -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15
    -DCMAKE_INSTALL_PREFIX=${TARGET_INSTALL_DIR})
    
ADD_CUSTOM_TARGET(SDL3_SHARED_LIBRARY
          ALL
          ${CMAKE_COMMAND} "${MULTI_ARCH_ARG}" ${SDL3_CONFIGURE_ARGS} WORKING_DIRECTORY
          COMMAND make
          COMMAND make install
          WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${SDL3_EXTRACTED_DIR}
          COMMENT "BUILDING libSDL3")

Note that I pass along MULTI_ARCH_ARG by quoting in the cmake command, but I don’t quote the SDL3_CONFIGURE_ARGS.

The above worked, and I could move on.

I could have moved on earlier by not trying to do the above, but I was determined to figure out how to get CMake to do what I wanted, and in the process, I am now more familiar with how CMake variables and lists work. Next time I run into something similar, I have this experience under my belt, and I think the struggle was worth it for what I gained.

And now I’m fighting with SDL3_ttf dependencies not building with multiple architectures. SDL3_ttf depends on Freetype and Harfbuzz, and those are apparently building with the current architecture (arm64) and so when the x86_64 version of SDL3_ttf is trying to build, it can’t find the x86_64 version of those dependencies. Hopefully solving this one won’t take another week.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report, I was creating a new SDL3-based release for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Since SDL3 is so different and I’ve been unable to dedicate substantial time to it, the work to create release builds for each platform I support is still ongoing.

Sprints 2026-MJ_3 and 2026-MJ_4: Release SDL3 update version

Completed

• Ensure Windows version can still be built/deployed

In progress:

• Ensure Mac version can still be built/deployed

Since Toytles: Leaf Raking is in the No ICE in Minnesota Bundle on itch.io (which, by the way, at the time of this writing has raised over $500,000 for the Immigrant Law Center of Minnesota and is still going!), I’ve been focusing on updates for the desktop version of the game.

The Linux version was done right away, but when I last did the work to release a build for Windows, I apparently did a poor job documenting how I did so, so I had to reverse-engineer how I did it before with SDL2 in order to figure out how to do so for SDL3.

And this time, I’m writing scripts to do it for me so that next time I have executable documentation.

I run Ubuntu has my main development system, and one thing I love is that cross-compilers exist. Basically, I can build a Windows version of my game just by using the C++ compiler from MinGW, but I need to use the MinGW development libraries that SDL3 provides.

Next up is the Mac build, complicated by the fact that I don’t have a Silicon-based Mac. I do have access to Mac computers I can remote into thanks to a service I pay for.

Due to how they handle billing by the hour even if I only use one minute and my limited development time which sometimes finds me trying to squeeze in development minutes at a time, I feel pressured to make sure I have an entire hour at a time to dedicate to the effort.

I’m not sure how much I can iterate on trying to automate the Mac build, but I hope I’m most of the way there already and just need to adapt my scripts in minor ways.

Assuming I can knock out the Mac build soon, I’ll move on to the Android and iOS builds soon after.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I had finished the SDL3 migration for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

As soon as I get this release version built on all supported platforms and out the door, I can start focusing on the Major Update(tm).

Sprint 2026-MJ_2: Release SDL3 update version

Completed

• Ensure Linux version can still be built/deployed

In progress:

• Ensure Windows version can still be built/deployed

I try to automate what I can, partly to make sure it is repeatable. I don’t need to remember how to do something if I can just look at the script I wrote.

But I also like automation because it takes something that tends to be stressful and time-consuming and turns it into something that is routine and easy.

So as much as possible, I like to have scripts that build and package my games for release, and over the years, more and more things have been automated.

I even got my iOS build mostly automated, which has the bonus benefit of reducing my need to touch Xcode.

Anyway, the SDL3 migration has naturally thrown a wrench in my existing scripts, so I need to update them. They should more or less work as-is, and I just need to make sure I have new libraries and maybe potentially point the scripts towards them.

But deploying those versions to the various app stores is still a manual effort, and I want to change it.

For the Linux version, I created a script to take a finished build and upload it to itch.io’s servers using butler, itch’s app used for such purposes. And it works pretty well! I can just give the script the name of the project, the version number to release, and the channel (in this case Linux), and it does the right thing.

Well, mostly. I uploaded the tarball, when instead I should have uploaded a directory, which means someone with an older version of the game will not be able to cleanly update to the newer version. I need to fix that.

I am also working on the Windows version. Again, I have scripts that do the work for me, but in this case it requires me getting the SDL3 libraries for Windows first and ensuring the scripts know where to find them.

The Android build should be similarly very quick as most of the effort to build the bundle for the Google Play store is done, but the iOS and Mac builds are trickier, mainly because I don’t have a modern Mac to do development on so I work remotely on a cloud service provider. It’s not ideal, but it is cheaper than buying a new machine each time Apple decided an older one is obsolete.

But my goal with creating new deployment scripts as well as improving the build scripts is to make sure that such release events aren’t a big deal in the future.

Wish me luck!

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report from mid-December I was still in the middle of migrating my code from SDL2 to SDL3 in preparation for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I spent the beginning of January reviewing 2025 and planning 2026, but this past week I finally got back to game development and finished the migration work.

Sprint 2026-MJ_1: Preproduction

Completed

• Update SDL2 to SDL3

If you’ve been following along and are interested in the technical details, most of the upgrade was pretty straightforward and easy, especially since the SDL3 migration guide was fairly detailed and a lot of the changes were renames or small interface changes.

But I was struggling with migrating to libSDL3_mixer, which has completely changed, which meant my code also needed to change how it handled audio significantly.

Before, I just played sound effects at a certain volume on whatever free audio channel was available.

Now, SDL_mixer has tracks and mixers, and so now I needed to manage those as well as the sound effects.

Toytles: Leaf Raking doesn’t have music (yet!), which means I could worry about supporting audio looping later.

Once the SDL_mixer migration work was done, I then solved a problem involving mouse input and rendering scaling.

Basically, if you resize the window, such as maximizing it to be fullscreen, the game renders the screen to that new window as best it can. However, I found that the mouse cursor was still only getting recognized in the dimensions of the original window.

That is, if I was running the game at 1280×720, and I change the window to run on my 4k monitor at fullscreen, the mouse cursor and mouse button clicks were still acting like the game was still 1280×720. That is, only the top left of the window.

It turned out to be an easy fix. SDL3 has a function called SDL_ConvertEventToRenderCoordinates which takes an event, such as SDL_MouseMotionEvent, and converts the coordinates based on the current renderer. Well, actually, the docs show it takes in a lot of different things, but the point is that when I use this function, the input works as expected no matter what the window size and logical rendering settings are like.

Now I’m just checking to make sure the game works from beginning to end and on all platforms without any issues before producing a new release.

Oh, I also updated the copyright year, which reads “2016-2026” now. That’s right, this year marks the 10 year anniversary of Toytles: Leaf Raking‘s initial release! That’s why I am very interested in creating a Major Update(tm) to celebrate.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I was making very slow progress on migrating my code to SDL3, specifically SDL3_mixer, for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

It has been another slow couple of weeks since then.

Sprints 2025-MJ_8 and 2025-MJ_9: Preproduction
In progress:

• Update SDL2 to SDL3

I didn’t give an update last week because I didn’t have much to say. I don’t have terribly much to say this time either, as I once again hadn’t put in many hours, but I am sketching out ideas for how the game could be improved and enhanced.

One thing I might try to do is borrow some ideas from a game I’ve been obsessed with recently. Dice the Demiurge is an incremental dice game for one player by Sophie Houlden, the creator of Sophie’s Dice.

One thing that I love about Dice the Demiurge is that it sometimes encourages you to do things in the real world. For instance, if you choose to play as a Mage, you can gain a bonus level by spending time each day for a week learning a new language. I’m currently on my third world and have chosen to play as a Rogue, and I’m currently looking for opportunities to gain a bonus level doing…rogue-ish things.

Some of the real world things you can do are more intimidating than others. Early on, I also gained a permanent Notion 1d18 by singing in the shower after finding the Wandering Emporium, but I could also gain a dice pool by giving up on something unfulfilling, which is a surprisingly big thing to try to fulfill.

Anyway, this game has a lot of such mechanics based on you doing something in the real world, and as it is a single-player game, it’s obviously enforced by your own honor system.

But I wondered if there was something that Toytles: Leaf Raking could encourage the player to do in the real world that would fit the theme of the game, such as offering to help a neighbor with a chore, or saving money for a big purchase, or making plans for the week based on checking the weather forecast.

Would a single-player leaf-raking business simulation have enough players with an honor system to only give themselves a bonus in the game when they do the actual real-world action? It might be worth a try.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report, I was still migrating my code to SDL3, specifically SDL3_mixer, for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Despite having time off from the day job, I got less done this week than normal.

Sprint 2025-MJ_7: Preproduction

In progress:

• Update SDL2 to SDL3

The holidays are always strange in terms of predicting how productive I will be.

Having time off from the day job doesn’t always translate into having more time to work on my business. Family activities and preparations for big visits naturally dominate.

Even when I do find myself with “idle” time, I might be exhausted. I think I napped more in the last week than I have in most months!

Some forward progress is better than none, of course, and I always manage to do something. I was updating code to use my new MixTrackManager that I mentioned last week, and a few more hours should be enough for me to finally finish this migration work.

And of course, last Friday kicked off the itch.io Black Friday sale which I am participating in, although I wish I had been more deliberate and prepared for it.

While I work on updating Toytles: Leaf Raking, you can get it now and ensure that you’ll get those updates for free in the future, when I will likely raise my prices!

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I was still migrating my code to SDL3, specifically SDL3_mixer, for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Alas, I am still, STILL working on it.

Sprint 2025-MJ_6: Preproduction

In progress:

• Update SDL2 to SDL3

Again, the main migration work that I have left is audio-related. To make things easier, I decided to create a MixTrackManager to manage my MIX_Track objects.

Basically, when I initialize my game, I will also configure a set of tracks, grouped by name.

For example, I might have one track for all user interface sound effects. Every button click and swooshing transition will likely play on its own. That is, if you clicked a button, you couldn’t have clicked a second button simultaneously, so won’t need a second track to play both sounds. One track will work just fine for “UI” sounds.

However, maybe there will be lightning crashes, the sound of rain hitting a roof, and the sound of wind. All of these might be “ambient” sounds that could play together, so I should have at least as many tracks available.

SDL_mixer lets you tag tracks, but the main use is to treat a bunch of tracks that are so-tagged as a collective group of tracks to play at once, for instance.

What I want is to be able to say “Play this sound effect on the first available track in the ‘ambient’ tracks”, and hence the MixTrackManager.

The old SDL_mixer just let me specify -1 as the channel to play on, and it would play on the first available channel rather than require me to specify a specific channel. I wanted to have something similar while also retaining the ability to have separate sets of tracks for different purposes.

So MixTrackManager allows me to create a set of tracks for a given tag, but I use my tags differently from how SDL_mixer is using them.

But maybe calling them “tags” even though the purpose is to just name a set of tracks (and even as I use that name to use SDL_mixer’s tagging functionality, too) is confusing things.

I might consider renaming things, but the functionality it will allow is the key: I will be able to play audio more or less the way I did before.

It’s taking me a long time to get to this point, and frankly I am not sure why exactly it has taken me so long, but I’m almost there.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!