Category: Game Design

In my previous report, I updated the title screen and logo for for my strategic leaf-raking business simulation game, Toytles: Leaf Raking, in anticipation of its 10 year anniversary.

I continued working on enhancing the menus and interface.

Sprint 2026-MJ_19: Update title screen

Complete:

• Create new default menu buttons
• Add transitions between menus
• Move Credits and Privacy Policy under Options Menu
• Create quit confirmation screen
• Update option screen background
• Update credits screen background
• Update Privacy Policy background

As a reminder, the game’s current title screen, which has pretty much remained the same since I released the game in 2016, looked like this:

And here it is in motion:

You can see that there are no animations, no user feedback regarding the buttons, and general poor quality of the visuals.

And I spent the previous week addressing all of these issues.

Here’s the latest title screen, now with a rake:

And here are the menus in motion:

You can see that the buttons look and feel interactive (and might look familiar to anyone who has played Clown Alley Creator). The menu transitions make it clear what is happening when you press a button, and the visuals are greatly improved.

At least, I think so. What do you think?

I also added a confirmation menu when you press the button to quit. The original game didn’t ask for confirmation.

What’s left to do? I want to find a better font for the buttons and labels. All the text in the game looks the same, and while it is functional, I’m looking to find something readable yet playful.

Then I can start focusing on the in-game visuals.

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!

Now that I have finished updating all of my projects to use SDL3, I can focus my efforts on the Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I started with a new logo and title screen.

Sprint 2026-MJ_18: Update logo

Complete:

• Create new title screen logo
• Update title screen background

Since it was first released in 2016, the title screen has basically looked like this:

It was just a simple text title, with some very pixelated imagery on a simple grass background and some weird looking leaf sprites.

When I was originally developing the game, I remember deciding NOT spend too much time on trying to make the art look good. I am not an artist by trade, and while my programmer art is potentially better than most, it’s still programmer art, and I knew from past projects that I can spend a lot of time polishing something and still end up with an ugly result. At least if I was quick about it, I could be more likely to actually finish the game.

The end result isn’t pretty, but it’s kinda got its own charm. I hope, anyway?

But for the upcoming 10 year anniversary of this project, I think it is time for a facelift. Here’s the latest version of the title screen:

I made the new logo using Inkscape. Since I always intended for there to be a series of Toytles games, this logo can be reused for future projects. Toytles: Snow Shoveling? Toytles: Lemonade Stand? Toytles: Go-Kart Racing? There’s a lot of potential.

I decided to replace the leaves with something that looks better. After looking into creating something more stylized, I ended up taking a picture of some leaves of the maple tree in my backyard, then using one of them as the model that I traced.

I also created a new rake sprite, but I decided to hold off on putting it on the title screen until I had more screen real estate, which required changing the menu.

I ended the week working on updating the buttons. The existing buttons are basically static images that I created by using a rounded rectangle inside of another rounded rectangle. I can use better, more button-looking buttons that animate.

I also plan to rearrange the buttons so that there are fewer options to choose from, and some of these buttons could be on a submenu.

And with submenus, I can add new backgrounds. And transitions. And better fonts for the buttons and blocks of text.

I am quickly finding that even simple improvements bring a cascade of changes, many of which I anticipated, but some of which I didn’t realize would feel so necessary rather than be considered a separate nice-to-have.

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 previous report, I finished updating Toy Factory Fixer from SDL2 to SDL3, and then I started working on updating my family-friendly creativity tool that allows you to create your own fun and zany clowns, Clown Alley Creator.

It went fairly smoothly.

Sprints 2026-1 and 2026-2: Release SDL3 update version

Complete:

• Ensure Android version can still be built/deployed
• Ensure iOS version can still be built/deployed
• Ensure Windows version can still be built/deployed
• Ensure Linux version can still be built/deployed
• Ensure Mac version can still be built/deployed

Clown Alley Creator and Toy Factory Fixer actually share a lot of the same infrastructure code, so other than finding a few differences, such as Clown Alley Creator needing to load different types of resources, and changing how it handled something needlessly differently, I had a smooth update.

I was able to build a release for Windows, Linux, and Mac, and I submitted the iOS and Android releases to the app stores for review.

The only tricky part was once again getting surprised that my automated scripts for building a release for certain platforms wasn’t working as expected, and I had to troubleshoot and find out why the Windows version wasn’t building correctly for Toy Factory Fixer and Toytles: Leaf Raking anymore. It was really bizarre, but it shows why it is important to have reproducible builds.

Now that the SDL3 updates are finished for all three of my projects, I can get back to working on Toytles: Leaf Raking’s Major Update ™ again. I finished the week by starting to work on the new title screen logo.

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 working on the SDL3 update for Toy Factory Fixer, my toy factory management game in which you hire and manage workers in order to ship toys by the deadline.

Aside from adding some new functionality to handle music differently, most of the porting effort was straightforward.

Sprints 2026-1 and 2026-2: Release SDL3 update version

Complete:

• Ensure Android version can still be built/deployed
• Ensure iOS version can still be built/deployed
• Ensure Windows version can still be built/deployed
• Ensure Linux version can still be built/deployed
• Ensure Mac version can still be built/deployed

SDL3_mixer works completely differently from SDL2_mixer, which meant my code needed to work completely differently, too.

Once I made changes so that I could play and stop music and change the gain on any given track easily, I then just needed to make sure that the audio was playing the same as before. I was able to play the old version of Toy Factory Fixer in one window and the new version in another, and it helped me determine when something wasn’t playing (it turned out I had a typo and named the wrong sound effect in one place) or was too loud.

Otherwise, I was able to quickly create a release for Windows, Mac, Linux, Android, and iOS, and I submitted the games for review to the respective app stores.

Next up is my family-friendly creativity tool that allows you to create your own fun and zany clowns, Clown Alley Creator, which I anticipate taking even less time to update to SDL3.

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 previous report, I was finalizing the SDL3 update for the iOS port of my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

This past week, I resubmitted it for review and started working on the SDL3 update for Toy Factory Fixer, my toy factory management game in which you hire and manage workers in order to ship toys by the deadline.

Sprint 2026-MJ_16: Release SDL3 update version

Complete:

• Ensure iOS version can still be built/deployed

While I waited for the App Store to review and approve the newest release of Toytles: Leaf Raking, I started updating my first Freshly Squeezed Entertainment project to use SDL3 as well. Since I already did much of the work of figuring out what I needed to do to upgrade Toytles: Leaf Raking to use SDL3, I was able to get many of the updates completed quite quickly.

In fact, I was surprised at how quickly I was able to get the game running with the new libraries.

The only thing that didn’t quite match was the music. Since my SDL3 update also involved updating the audio library SDL3_mixer, and since SDL3_mixer was a complete overhaul from SDL2_mixer, my own code needed to change quite a bit to handle audio differently.

And Toytles: Leaf Raking only has sound effects (for now), but Toy Factory Fixer has music.

And it wasn’t playing music quite right, partly due to how music is no longer a special piece of functionality that works on a single channel and is now just treated as generic audio on potentially multiple tracks.

Basically I need to add some code to stop playing one music track and start playing another when it transitions from menus to in-game and back again, and I almost had this work finished by the end of the week, so I expect that once I do, it will just be a matter of creating a new release for each platform the game is available on, and I expect I’ll be able to do so before the end of the 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!

Last time, I reported that I was still automating the SDL3 update build for the iOS port of my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I made good progress, but even though I thought I was done, it turns out that I’m not finished yet.

Sprint 2026-MJ_15: Release SDL3 update version

In progress:

• Ensure iOS version can still be built/deployed

My project’s build scripts can now load the .xcframework for Apple-based builds or normal libraries for every other port.

To get there, I learned a bit more about CMake and even cleaned up my own build scripts based on that new understanding.

I was able to successfully build the app more or less automatically and run it in the iPhone simulator.

Then I went to submit the app to the App Store. First, I click on Validate in Xcode, which I will confess to not exactly understanding what kind of validation it does, but I figure that if it passes here, then I don’t need to worry about the kinds of things it checks for.

Unfortunately, it seems quite limited, and so as soon as I submitted the app for review to the App Store, I had an email that told me I had a few things that needed to be corrected that I have never run into before.

Basically, since SDL3 has code that lets you access Bluetooth, the camera, and the mic, Apple detects this and thinks you need to have usage description entries in your app’s Info.plist to explain to your players what you need such access for, even if your app doesn’t use that functionality.

NSBluetoothPeripheralUsageDescription, NSCameraUsageDescription, and NSBluetoothAlwaysUsageDescription were flagged in the email I received, but I also addressed the mic with NSMicrophoneUsageDescription. I use variables for the project title because my Info.plist gets generated by my build scripts:


<string>${GB_PROJECT_TITLE} would like to use Bluetooth controllers for input.</string>
<key>NSBluetoothAlwaysUsageDescription</key>
<string>${GB_PROJECT_TITLE} would like to use Bluetooth controllers for input.</string>
<key>NSCameraUsageDescription</key>
<string>${GB_PROJECT_TITLE} does not use the camera.</string>
<key>NSMicrophoneUsageDescription</key>
<string>${GB_PROJECT_TITLE} does not use the microphone.</string>


I confirmed the right project name showed up by looking at the Info.plist file that was generated and at what Xcode showed, and I submitted the app again.

This time, it successfully kicked off a review, but unfortunately on Saturday it was rejected because the app crashed on startup.

So, that’s not good, and it shows that I should have tested it on my own hardware before submitting it. I now have to figure out why it is crashing in the first place, then fix it so that it doesn’t.

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 previous report, I said that I was working on the SDL3 iOS port of my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I am sorta finished, but why am I still working on it?

Sprint 2026-MJ_14: Release SDL3 update version

In progress:

• Ensure iOS version can still be built/deployed

How am I “sorta finished” with the iOS port?

I mean that I was able to successfully build the app and run it in an iPhone simulator.

Normally, I would just move on to building the app and testing it on my actual iPhone and iPad test devices.

But my goal isn’t to just manually build this app and submit it to the App Store and move on.

I currently have three different games that I support across Windows, Mac, Linux, Android, and iOS. I’ve been trying to automate my builds as much as I can to make it easier for me to support these existing games and support the new ones I will be making for hopefully many years to come.

If I had to manually fight with Xcode each time that I wanted to create a new release of any one game, it would be error-prone and a waste of my time. Each release would be painful, and I would do it less often.

Now you could argue that I’ve spent too many days on this work as it is, that I’m already wasting time.

To that I would say that maybe I agree with you, that I do feel like this effort is taking too long. I am really behind on my plans due to all of this automation work I’ve been investing my time into.

So if anything, I’ll admit that I’m worried I am justifying all this effort and time when instead I should be moving more quickly.

My plans are basically on hold until I get these new releases finished, and the releases are on hold until I can automate their creation as much as I can. And maybe I’m wrong to do so?

But on the other hand, I’ve been living this manual build and release life for years, and I think I’m finally willing to put in the hard work to make my life easier.

If I have any concerns, I think it is that I so easily let myself keep working on a task long after the time I thought it was going to take, and I feel like I should be a bit more deliberate about actually deciding how to proceed.

Anyway, I fully expect that I’ll finally have this work actually automated soon. Basically, my build scripts need to be changed to do this one-off wacky thing involving supporting Apple xcframeworks for my iOS port, while pretty much all of my other ports do not have to worry about it.

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 working on the SDL3 mobile ports of my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I continued to fight with the Apple ecosystem to create my iOS port.

Sprint 2026-MJ_13: Release SDL3 update version

In progress:

• Ensure iOS version can still be built/deployed

I am so close. Every SDL2 to SDL3 update for each platform I support is finished except for iOS.

I ended up looking at the script libSDL3 uses to build its Universal library, and it is TOO Universal! It combines everything: Mac, iOS, visionOS, tvOS, and watchOS.

I don’t need all that, so instead I adapted my own library build scripts to create my own Universal libraries to support just iOS, and I did the same for SDL3_image, SDL3_mixer, and SDL3_ttf.

Now I have a few .xcframeworks that I can use to build my app and have it run in the simulator or on an actual hardware device. That’s a lot nicer than having separate builds like I used to with SDL2.

But to get there involved a lot of false starts, such as installing needed things like the Metal toolchain and deciding not to include the debug symbols because I would get errors that they weren’t valid debug symbols.

Next was updating my own application’s build process. I used to have static libraries for SDL2, but now that I have dynamic SDL3 libraries, I need to be able to not only build my app with those libraries but also run the app by pointing to those libraries when they are embedded in the app.

I ran out of time last week, but once again I am making slow and steady progress.

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 previous report, I finished working on the Mac port of my strategic leaf-raking business simulation game, Toytles: Leaf Raking, and then I proceeded to work on the Android port.

I finished the Android work relatively quickly and started working on the iOS port by the end of the week.

Sprint 2026-MJ_12: Release SDL3 update version

Completed

• Ensure Android version can still be built/deployed

In progress:

• Ensure iOS version can still be built/deployed

As I said last time, I had an Android port that was almost finished. I basically needed to test it out manually on my phone to make sure it worked correctly, then I created a bundle and submitted it to Google Play for review.

Then I spent the bulk of the week figuring out what I needed to change to get SDL3 libraries built for iOS. The documentation for SDL3 has suggestions for how to incorporate the library as a subdirectory or submodule of my project, but I would rather build the libraries separately, especially as I will be using these libraries in each of my apps. I should need to build the library for each one.

I had a script that basically built static SDL2 libraries that I incorporated into my app, but the downside was that I needed to build one set of libraries for an app for the iOS simulator to test in and a completely different set of libraries for an app for testing on an actual iPhone or iPad.

Apple allows you to create Universal libraries, but ever since the development of Silicon-based Macs, you couldn’t make assumptions that x86_64 was for the simulator and arm64 was for the iOS hardware.

However, apparently SDL3 allows you to create a very Universal .xcframework. That’s great, except I ran into trouble building it, both on my Intel-based Mac and the Mac in Cloud M2-based Mac, although for different reasons.

I was able to use my old Intel-based Mac Mini to work on the Mac port, but I ultimately ran into a problem in which SDL3 uses and expects newer iOS SDKs than my obsolete machine supports. And on the newer Mac, I ran into problems because it was depending on SDKs for platforms I don’t care about and don’t want to bother with, like visionOS or watchOS.

I will need to do most of my work with Mac in Cloud, unless I get myself a Silicon-based Mac. Either way, I’ll figure it out and hope that the SDL3 port for iOS doesn’t take too much longer.

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 fighting with Apple’s development ecosystem to automate the creation of a Mac port of my strategic leaf-raking business simulation game, Toytles: Leaf Raking

In the end, I wasn’t able to completely automate the creation of the Mac application, but my scripts do a lot more than they used to so I can spend as little time in Xcode as I can.

Sprints 2026-MJ_8, 2026-MJ_9, 2026-MJ_10, and 2026-MJ_11: Release SDL3 update version

Completed

• Ensure Mac version can still be built/deployed

In progress:

• Ensure Android version can still be built/deployed

My apologies if you aren’t interested in the technical, behind-the-scenes work, but this post is going to be a somewhat technical, behind-the-scenes post.

My goal was to automate the creation of a Mac version of the game and get it published on itch.io as quickly as I could.

I already have a deployment script that works for Windows and Linux, so adding the Mac port wasn’t difficult.

But I first needed the Mac port.

I was already using CMake to create an Xcode project. As much as possible, I tried to get my CMake configuration and scripts to create an Xcode project that had as much configured as possible. A long time ago I used to manually copy in my resources directory, which holds all of the images and audio files that I use in the game, but eventually I got the configuration to do that for me automatically. Similarly, I got my account/team information tied in so I didn’t have to manually specify that I wanted to use my account for code signing the project.

I still had issues with other things being a manual effort, though, such as creating a Universal binary, which can run on older Intel-based machines as well as the new Silicon-based ones. Last time, I had to create a set of SDL2 libraries on my Intel-based MacMini and another set using Mac in Cloud, then use something like lipo to combine them together into a “fat” binary, then build my project in Xcode using those fat libraries and making sure to configure the project to also be a Universal build.

But now my build scripts can create SDL3 libraries that are Universal binaries, and I can create a Universal app that I can test easily once the build is finished.

Unfortunately, I struggled to automate code-signing and notarizing. Between Apple’s documentation strongly encouraging using their GUI-based Xcode, rarely mentioning their xcodebuild CLI tools, and needing to dig deeply into the details of certificates and provisioning, something that Xcode’s manual effort handles automatically, I decided I had been working on this automation work for way too long and to cut my losses.

I made progress. I can create Universal libraries and a Universal app automatically, so I can quickly go from nothing to a program I can run and playtest. I can confirm that everything works, that it has the right permissions, and is packaged together properly. Archiving, notarizing, and exporting are relatively quick manual steps, and then I am finished and can upload my new Mac app to itch.io.

Next up was the Android build.

It was fairly straightforward to update my project’s build scripts. SDL3 provides an android-project directory, which I copy into my project, and then use CMake/configure to update files based on my project’s details.

I ran into problems running it, however. It seemed to keep crashing when launching the game.

Ultimately it came down to having an older version of SDL3. There was a mismatch between the android-project’s Java code and the C code related to SDLControllerManager, and it took me awhile to find it, but the discrepancy was already addressed in the latest SDL3 version. Once I grabbed the latest SDL3 and built it with my project, it finally ran successfully.

Then I had to update how touch presses were handled, which I think was potentially due to the high DPI of mobile devices. Basically, SDL3 touch events are scaled from 0.0 to 1.0, and I would multiply it by the screen width and height that I requested in order to identify where on the screen the touch event occurred.

But in high DPI mode, if you use SDL_ConvertEventToRenderCoordinates(), it scales to the screen width/height already. So I was basically taking an event’s coordinates and multiplying them by the dimensions of the screen a second time, which made it seem like the inputs were happening way, way offscreen. No wonder it seemed like input wasn’t working right!

So I ended the week pretty close to having a new Android version ready, but I wanted to test it some more to ensure that there weren’t any other quirks or surprises. Then I’ll work on the iOS version.

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!