Category: Game Design

In last week’s sprint report for Toy Factory Fixer, I focused on making the audio less tedious and making the toys feel better when they land.

It was a very small start to adding to the game’s feel, and I found myself continuing with it.

Sprint 30: Polish and end game

Planned and Completed:

• Award grades to player performance
• Add juiciness to toys landing on conveyor belt

Unplanned yet Completed:

• Add juiciness to toys moving on conveyor belt
• Interpolate money changes
• Change value of small vs large toys

Unplanned and Uncompleted:

• Create different types of workers

Like the previous sprint, I didn’t get started on putting any effort into game development early on due to the July 4th weekend and spending time with family.

That said, somehow this last week was still one of the most productive I’ve had all year. After multiple sprints in which I didn’t finish my original planned work, pulling in multiple pieces of unplanned work AND getting them done feels good.

And the game itself feels a LOT better.

If you recall from last week’s report, I created a dinky dust cloud animation. It’s not great, but the idea was that it made it clear that a toy landed on a conveyor belt.

Here’s the animated GIF I created to illustrate it, which looks ridiculously simple to me now:

It’s better than no effect, but just barely.

So I made the toys squash and stretch to sell it more. I spent a little bit of time learning about squash and stretch as an animation technique, and then I made two simple changes.

One, I created a new DISPENSING state for the toys. Each turn in the game moves the toys along the conveyor belts if they aren’t being actively crafted by a worker, and so now I can animate the toys differently if they are being dispensed in a given turn.

Two, I did what I said I was imagining last week, and I made the toys arc up into the air before landing. Basically, I used a sine wave and interpolated a vertical offset (stay in school, kids!). Then, I changed the scale of the toys using that same sine wave technique so that as the toy launches up into the air it would squash, then stretch, and as it came to the top of the arc it would squash, and then stretch as it came back down.

And it was so delightfully playful! I was a bit giddy, in fact. It’s my new favorite thing about the game.

I mean, look at it compared to the animation above:

You’ll note that I also made the toys lean back as they are moved along the conveyor belt (a rotation based on a sine wave and the direction of movement), and it might not be obvious but I made the value of money interpolate instead of instantly changing values.

Again, I love the effects of these simple changes. The toys were the focus of the game before, but now the toys FEEL like they should be the focus of the game.

I now have to rework the dispenser art again, as I want it to look like a cannon shooting the toys out. And the lack of animation from the workers is now very obvious and should be addressed.

But I returned my attention to the end of level grade report. The original ending let you know if you won or lost based on whether or not you shipped a Bad Toy.

Here’s a screenshot from February which doesn’t look much different from last week:

And here’s what it looks like today:

In wanting to be more forgiving and give the player a self-directed challenge, I wanted to grade the player in three categories: the quality of toys shipped, the number of turns taken to finish the level, and how much the player earned versus spent.

Now I need to work on calculating these values more. For instance, grading the number of turns taken requires judging how many turns the player should have taken. I would need to figure out what “par for the course” is versus what would be amazing, and there are still a number of variables related to the time it takes toys to traverse the conveyor belts, the time it takes workers to work on separating them and crafting them, whether or not the player started production runs early, etc.

But overall, I like this screen, and I really like the joke that “MEETS EXPECTATIONS.” is always there no matter how well or badly the player did. It replaced the “GAME OVER” text before, and I originally wanted to have different text based on how the grades worked out, but I might keep it this way because it amuses me as a commentary about how many companies handle performance reviews.

Finally, I decided to start adding new worker types to the game. I didn’t get too far in terms of actually implementing it, but I did change the health of the toys so that they take longer to work on with the “normal” worker.

I’m thinking of adding two new worker types, one that crafts toys more effectively, and one that separates toys more effectively. These workers cost more.

I’m also considering some changes. Perhaps instead of tediously assigning a crafting task to each worker, you tell the worker to focus on crafting or separating. So a worker will not pick up toys if they are in a crafting mode, but they also won’t craft if they don’t have the inventory to work on the toy in question.

Also, what if you can’t hire the specialists unless you spend money to put out a call for workers, who show up within X turns? What if there are unlimited normal workers but a limited supply of specialists? Or limited supplies of all workers? Can you hire workers faster if you offer to pay more for them? Will they take longer to show up if you offer to pay less?

These are just thoughts, and I do need to worry about feature creep, but maybe they can be in a future deluxe version of this game if enough players want it.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

Last time, I reported that I finally fixed the issues I had with Android 11 and added some fancy effects to the toy dispenser to give it some more character.

This past week I planned to continue adding juiciness to the game.

Sprint 29: Make publishable

Unplanned yet Completed:

• GBLib: Make it easier to play a random sound with one command
• Add variety to sound effects

Planned and Uncompleted:

• Add juiciness to toys landing on conveyor belt

Planned and Not Started:

• Award grades to player performance

Ok, so let’s start with the fact that I didn’t do much at the start of the week, and when I finally did put in some time a couple of days after the sprint technically started, I decided to change the plan and instead work on fixing how tedious the worker grunts sounded.

Whenever you tap on a worker, hire a worker, or give a worker a job to do, you’ll hear the worker make the same sounds two sounds. One is kind of a confused acknowledgement that you selected a worker, and another is a confirmation “Uh, huh!”

Over and over. It gets old.

I basically made two more versions of each sound effect with a different pitch. So it’s the same two sounds, but each has a little bit of a difference.

I’m not sure if it is enough to make it feel less tedious, though. I’m thinking I’ll revisit these effects and create a variety of grunts/barks.

Weeks ago I found that my existing GBLib code didn’t make it easy to play random sounds. Basically, there was a command to play sounds, and I abstracted away the number generator that tells it which of a few options to play, but the way I did so expected that a number generator was owned by some other object.

Which at the time made sense: I could create a single number generator object, and then it can get used by multiple objects that need it, whether it is for audio or something else.

But it practice it made it painful to create these sound objects because I had to do the extra work of figuring out what other object was responsible for the number generators.

So I changed things so that while you still needed to pass it a number generator, the play command object now owns the generator object and will manage its lifetime.

And I created some helpers so that the generator created was guaranteed to be tied better to the size of the collection of sound effects you want to choose from randomly.

Ok, so for now, my library has been improved for future games, and the audio grunts are less tedious. Next, I decided to work on adding a special effect when the toys land on the conveyor belt.

It wasn’t going to be a major effect. I just wanted a dust cloud or something to convey that there was an impact as the toy hit the belt, which happens whenever a Bad Toy gets dispensed or when a worker tosses a finished Good Toy.

I managed to create a somewhat OK piece of art that combines an impact ring and some translucent clouds. It doesn’t look like much by itself.

But it’s not meant to be static. I scale it up in size and make it more translucent as it finishes animating, and … well, I think it still doesn’t look like much, but on the other hand, it sells the impact (especially when you hear the thud sound effect with it):

I have yet to create this effect when the toy is dispensed because I also need to change how toys get dispensed. Right now, the way toys get dispensed is that they appear behind the dispenser art, and they slide right out onto the conveyor belt right next to it. I would need to change it so that they look like they are spit out a bit higher so that they land on the belt next to it, but that requires changing a few more things.

I considered not doing the change, but I am starting to enjoy the juiciness I’m adding. It makes the game feel more playful, and I’m already picturing the toys getting dispensed in an arc like they were fired by a short-range t-shirt cannon.

The main game play change was one I didn’t get to at all. I wanted to change the game ending from either a binary win or loss based on perfection to giving the player a grade. The idea is that the game will be less harsh while also giving the player goals they can self-assign. If you got a C grade, you can decide if it is good enough or if you want to replay the level to try to get a B or an A.

I’ll spend time on it this coming week.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

In my previous sprint report, I talked about updating my project to use SDL2’s new android-project directory and Android’s gradle-based build. Upon doing so, I fixed a screen orientation defect where the game played in portrait mode despite the configuration specifying it should be in landscape mode. I also started work on improving the art for the dispenser so that it communicates what is happening to the player better than it has.

Sprint 28: Make publishable

Planned and Completed:

• Add juiciness to dispenser
• Defect: game seems unresponsive on main menu screen (Android)

Ok, I might be premature in saying this, but I think I fixed the Android 11 touchpress issue that my tester reported.

With SDL2, I basically pretend that a tap is a mouse click by paying attention to the values that come from SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events. There are also SDL_FINGERDOWN and SDL_FINGERUP events, which are for touch events, but since the default behavior is for mouse events to get simulated from touches, I ignored them.

My tester said that tapping on the screen didn’t seem to make the menu options respond at all. I added some debug text, and I changed my code so that the SDL_FINGERDOWN/UP events modify my game’s input data. Oddly, we learned that the taps do seem to cause at least some effect in terms of setting the simulated mouse cursor position, but there was no down event or up event that changed whether the simulated mouse button was down or not. Weird.

I found that I couldn’t reproduce the issue with an earlier version of Android that my phone and tablet have access to, and I don’t yet have an Android 11 phone, so other than the Android emulator, I wasn’t able to do much.

However, if you run the emulator, and in a terminal you run adb shell, then you can run the input command with arguments to simulate a tap on the screen.

And I found that the simulated tap does indeed seem to reproduce the behavior.

Well, I finally decided to play unique sounds when the SDL_FINGERDOWN and SDL_FINGERUP events are processed, and when I ran input tap…the sounds played!

WHAT?!

Ok, so to cut a long story short, it turns out that the tap is so quickly simulating a touchpress and release that the two events end up in the same queue.

My code processes SDL2 events using a typical event pump. Basically, I have a function called update() that calls SDL_PollEvent() in a while loop. If it returns 0, there are no events, but if it returns 1, it means that there is one…namely, the event pointer argument that is now set.

The SDL2 wiki says:

The common practice is to fully process the event queue once every frame, usually as a first step before updating the game’s state:

while (1) {
    SDL_Event event;
    while (SDL_PollEvent(&event)) {
        /* handle your event here */
    }
    /* do some other stuff here -- draw your app, etc. */
}

And quite frankly, the code above is almost what my own code looks like.

The way my game’s UI works, though, is to detect a mouse click on a UI element whenever there is an update in which the mouse button is down and then later up while the cursor is over the element.

And it does so across separate calls to the update() event pump.

Well, I discovered that if I change the while loop’s condition, I can exit the update() function whenever a finger/button down or up event occurs, ensuring that my game’s input data is set correctly.

void HardwareLayer::update()
 {
+	bool handledTapOrButtonClick = false;
 	SDL_Event event;
-	while (1 == m_sdlInstance.PollEvent(&event))
+	while (!handledTapOrButtonClick && 1 == m_sdlInstance.PollEvent(&event))
 	{
 		doRenderUpdate(true);
 
@@ -345,6 +346,7 @@ void HardwareLayer::update()
 
 			case SDL_FINGERDOWN:
 				{
+					handledTapOrButtonClick = true;
 					m_fingerIDs.insert(event.tfinger.fingerId);
 					if (m_fingerIDs.size() < 2) 
 					{
@@ -358,6 +360,7 @@ void HardwareLayer::update()
 
 			case SDL_FINGERUP:
 				{
+					handledTapOrButtonClick = true;
 					for (std::set<long long>::iterator iter = m_fingerIDs.begin(); iter != m_fingerIDs.end(); ++iter)
 					{
 						if (*iter == event.tfinger.fingerId)
@@ -399,6 +402,8 @@ void HardwareLayer::update()
 
 			case SDL_MOUSEBUTTONDOWN:
 				{
+					handledTapOrButtonClick = true;
+
 					if (SDL_BUTTON_LEFT == event.button.button)
 					{
 						m_mouseButtonStatuses.at(GB_MOUSE_BUTTON_LEFT) = 1;
@@ -412,6 +417,7 @@ void HardwareLayer::update()
 
 			case SDL_MOUSEBUTTONUP:
 				{
+					handledTapOrButtonClick = true;
 					if (SDL_BUTTON_LEFT == event.button.button)
 					{
 						m_mouseButtonStatuses.at(GB_MOU

The update() function already gets called multiple times between draw calls, so it isn’t as if I lose anything by exiting the while loop early. I’ll end up right back in a new while loop and can handle the next event without missing a beat.

And so now I wait to hear from my tester to find out if this worked on a real device with a real person’s fingers.

Fingers crossed!

In the meantime, I also worked some more on the dispenser art. If you recall, I had another tester tell me that he had trouble understanding why it looked like the game wasn’t advancing, so I decided to update the art and use animation to make it clearer.

The new dispenser art has arrows that now light up and turn off as it is running. I added a bit of a glow to try to sell it.

But I also created a lever switch. The handle moves towards the Play side when the turns are advancing, and it moves towards the Stop side when they aren’t. The Stop square changes fades in and out to make it clear that everything is stopped.

As a final bit of juiciness, each time the dispenser spits out a toy, it changes size, almost like it is building pressure and then relieving it. It’s a subtle effect, but I think it looks decent enough.

I’m looking forward to hearing from my other tester to see if this graphical enhancement makes it easier to understand what the current situation is at a glance.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

In my last sprint report, I finished up my work of updating my build scripts to create an iOS project successfully to deal with Apple’s latest requirements, and then I turned my attention back on addressing Google’s new requirements.

Sprint 27: Make publishable

Planned and Completed:

• Defect: game plays in portrait mode instead of landscape (Android)

Not completed:

• Add juiciness to dispenser
• Defect: game seems unresponsive on main menu screen (Android)

The good news was that I didn’t need to change too much of my existing Android build process. I basically needed to replace the older SDL2’s android-project directory with the new one, change a few files so that it did what I expected, and then change my CMake files so that it used the new gradle-based build rather than the old ant-based build. I was pleased that aside from a few things, much of the work was changing the directory names to match what was expected.

While the SDL2 docs mention using the command ./gradlew debugInstall, I wanted to have more fine-grained control. I wanted to be able to run three separate steps: build either a debug or release build, sign a release binary, and install the APK.

When I checked the Android docs, they mentioned the arguments assembleDebug and assembleRelease, so building is as easy as changing the argument to gradlew.

While I haven’t uploaded to the Google Play store yet, signing looks like it is the same as before, which I do with jarsigner and zipalign. I assume that since I can run a signed release build on my own hardware that it is not going to require any changes when I do upload it, but I’m prepared to learn otherwise.

And installing, either in the Android emulator or on my device, uses adb as before.

One thing I ran into was that the build would look like it was fine, but then suddenly I’d get a bunch of linker errors along the lines of:

undefined reference to 'std::logic_error::logic_error(char const*)

It turned out that in android-project/app/jni/Android.mk, I needed to uncomment the APP_STL line to make sure it uses the C++ STL that my project requires. Then it built correctly.

I sent the latest builds off to my testers. Based on my own testing in the emulator and using adb shell to play with input tap, I’m worried that the touchpress detection is still not working in Android 11. I was using SDL2 2.0.14, and I even tried by downloading the latest in-development branch from GitHub, and it still didn’t respond correctly. But maybe my tester who was having issues on his device will see something different.

In the meantime, my other tester who reported that the game runs in portrait mode instead of landscape mode on his phone informed me that the new build does in fact run in landscape mode correctly now. So that’s one defect fixed!

While I wait to hear back from my other tester, I got back to actual game design work. I started experimenting with some graphical enhancements that didn’t pan out, then I started working on updating the dispenser’s look.

This new dispenser is a bit bulkier to hide the fact that it basically draws over the toys. The old dispenser had a skinny part, and toys would show in the background, which broke the illusion that they were coming out of the dispenser.

But this new dispenser also allows me to make it clear if turns were advancing or not. One thing I was told by one tester was that it wasn’t very obvious at times that you needed to hit the Go button to make things move forward, especially when you were hiring or telling a worker to do something. The game is kinda continuous-turn-based, and so it continues until you perform such an activity, and then it stops everything, and you have to hit Go to again.

Right now, the only indication you have is that the button says Go instead of Stop, and the fact that nothing is moving.

So I wanted to make the dispenser light up when the machines were active, and perhaps have a different animated light to indicate that it was stopped.

I might change it so that one of the arrows is a lever, which is up when it is running or down when it isn’t, with a blinking light to make it clear which setting it is.

Anyway, I’m easing back into it, but I’m happy to get back to actual game development rather than fighting with platform-specific changes brought about by other companies changing requirements.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

In the previous sprint report, I wrote about spending time figuring out how to build SDL2 and combine it with my CMake-generated iOS Xcode project for Toy Factory Fixer successfully, as well as configuring that Xcode project to automatically know where to find my app icons, which made me a bit giddy when I got it working.

I continued with the iOS work in the next sprint.

Sprint 26: Make publishable

Planned and Completed:

• Create iOS icons

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)

I once again didn’t spend as much time as I would have liked on game development, but then again, I took my first true day off for the first time in what feels like years. Normally my days off from the day job tend to become opportunities to spend more time on game development, but my family took a trip out of town, and when we came back, the kids went to a day camp, and so my wife and I spent the day together. Due to a variety of things going on, I didn’t do any game development until halfway through the week.

I created a script to take a 1024×1024 PNG and convert it into all of the image sizes I would need for iOS app icons.

I learned a few things from this experience that I can take to my future projects. One, when it comes to generating those icons, I need to start with a higher resolution image. As it is, I had to actually generate a larger icon from a smaller one, and so it looks more pixelated than I would have liked.

And that leads to two: I should probably use vector graphics to create art initially so that I don’t need to worry about issues when I scale the image for a different purpose later. Between icons, marketing materials, and even in-game art, vector graphics would provide more versatility.

Anyway, my game now has icons for iOS. I did have a scare in which I deployed the app to my iPhone, then when I used the app switcher, I saw the icon was missing. What gives? I double-checked, and I wasn’t missing any icons as far as I could see. And I didn’t see how to specify this specific icon in the app switcher (which comes up when you hit the Home button twice quickly).

It turns out that iOS caches things…and it had my app’s old icon, which was no icon.

So once I restarted my phone, everything worked fine. Hopefully this information helps someone in the future.

So now that the iOS port seems to be working properly, I returned my attention to Android issues. If you recall, Android 11 seemed to have broken things like touch input and respecting the fact that my game should run in landscape mode instead of portrait.

And since I am using an older version of SDL2, I needed to update to 2.0.14, which actually requires me to update from the old ant-based build to the gradle-based build.

The good news is that SDL2 comes with an android-project directory, just as before, and the documentation for it is a lot better than the iOS docs. I was able to compare what I already had in my project directory to what they specify, see that most of the compiling parts are identical, and basically move everything into a subdirectory that didn’t exist before.

Then, I needed to make sure that the Android.mk file specified the correct STL, and everything built and linked correctly.

So far, so good, but next is the part where I need to change from using ant to gradle, and the docs get a bit opinionated about how to create a debug build or how to deploy directly to your hardware. Literally, all it says is:

Run ‘./gradlew installDebug’ or ‘./gradlew installRelease’ in the project directory. It will build and install your .apk on any connected Android device

Normally, I build my code, then create an APK package, then sign it, and that signed APK gets uploaded to the Google Play store. If I wanted to test it on my device, I would create a debug build and deploy it using adb to install.

So I need to dig a bit more to see if there is a gradle way to do what I already did before, which is build the APK as a separate step from doing something with the APK like installing it on a device or signing it.

So far, when I ran gradlew as above, it downloaded gradle.

I hate that. I mean, I should have read some docs about gradle and gradlew, so it is my fault, but why the heck is there a tool to download a tool from someplace random and put it on my machine without so much as asking me if it was OK to do so? I already have to deal with it when it comes Javascript at the day job.

Anyway, after it downloaded gradle, it failed, so I still need to figure out what changes I need to make to get this build working. I’m hoping it won’t be much longer before I can get an Android build working and deployed to my testers to verify whether or not it works on Android 11.

Meanwhile, I’ve also been trying to dig back into the design of workers, toys, and the level layout in the game. I want to make sure that the player doesn’t feel bored by obvious decisions to make, whether by giving them the ability to hire more interesting and varied workers or throwing different kinds of toys or movement patterns in the game. I’ve got some ideas, and some might be terrible, but some made me laugh as I wrote them down, so hopefully something good can be shared soon.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

A few weeks ago, I reported about needing to figure out how to build my project for iOS, something that was solved but needed re-solving due to Apple changing some requirements about how things should work.

I am late with my reports due to traveling out of town for the first time in over a year, so here’s my report for the next two sprints.

Sprint 24: Make publishable

Planned and Completed:

• Create iOS build

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)
• Create iOS icons

I managed to put in a few more hours than usual, and I finally managed to figure out how to build the project.

Part of the problem was that Apple’s requirements changed, yet the docs for SDL2 for iOS haven’t, so I knew I was going to need to figure out things on my own. I tried looking online for clues, because obviously someone has done this successfully recently, right?

I got so frustrated that I eventually posted on the SDL2 Discourse about it, adding detail to an existing thread.

If you recall from the last report, I had this linker error:

Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_CHHapticDynamicParameter", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticEventParameter", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_CHHapticDynamicParameterIDHapticIntensityControl", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
"_CHHapticEventParameterIDHapticIntensity", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticPattern", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticEvent", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_CHHapticEventTypeHapticContinuous", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


I thought it was related to hidapi, and it wasn’t clear to me if it was something I was expected to build myself or not.

When I looked up the symbols in question, I found them in the Apple Developer docs. It turns out that they come from the CoreHaptics framework. So once I added that dependency to my CMakeLists.txt file, the project built just fine.

It sounds like this might be a bug in SDL2 for not specifying it as a dependency? It’s not clear, but at least I can solve it for this project for now.

I tried creating an SDL2 framework and an XCFramework again, now that I can specify that dependency, but I could not figure out a way to get the project to actually link to what it was supposed to. It seemed like Xcode/clang couldn’t find the SDL2 library when it was in a framework, but it linked just fine if it was a static library, so I ended up creating static libraries for the simulator and static libraries for the device. It’s a bit annoying to have to switch between them either manually or at CMake configuration time.

One person suggested that I could add the target as a dependency of my project, but I’ll leave that as an exercise for future me to figure out. For now, I’ll just generate an Xcode project with CMake with an argument that says which libraries to point to.

Sprint 25: Make publishable

Planned and Completed:

• Nothing. B-(

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)
• Create iOS icons

Ok, so after the previous sprint’s success, I actually spent a big part of the next sprint trying to get the various scripts and CMake files coordinated and a bit more automated.

And one of my favorite things was solving an annoying manual step I have had to do.

Basically, each time I generate my Xcode project, I would need to do a few things within the Xcode IDE itself, which is not my favorite thing to do.

I would need to drag and drop my Images.xcassets into my Resources folder, then I would need to specify that I want to use the Asset catalog, but then Xcode would generate one for me, so I would need to delete the icon set that it created, then specify the icons I have.

Every time.

It’s error prone and tedious and annoying.

But I finally got CMake to do it for me, and I giggled and cheered and did a little dance in my chair when I saw the icon appear in the iPhone simulator.

Years ago, I tried to research how to do it myself, and the problem was that, again, Apple changed how things are done, so what worked in older versions of CMake and with older versions of Xcode/iOS no longer worked. And unfortunately, the Internet is littered with obsolete solutions.

Well, today I find that there is a CMake Discourse, and there is a person named Craig Scott who posted in a thread where someone asked a similar question.

Rather than adding each part of the asset catalog individually, see if adding it as a whole directory works instead:

target_sources(${TARGETNAME} PRIVATE Assets.xcassets)
set_source_files_properties(Assets.xcassets PROPERTIES
MACOSX_PACKAGE_LOCATION Resources
)

Adding directories rather than files is not officially supported by CMake as far as I’m aware, but doing it this way should allow Xcode to see the asset catalog and compile it for you. I don’t recall if setting the source file properties is required or not, but give it a go and see.

Wouldn’t you know it, but that actually worked for me. Now I didn’t need to drag and drop my Images.xcassets into the right place. But the asset catalog was still not being used.

But I see in that same thread the original poster had the following:

XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_APPICON_NAME "AppIcon"

Now, I’m embarrassed to say that I still had trouble and thought it was still not working, but I later saw I had a typo with the set_source_files_properties line in which I accidentally typed IImages.xcassets instead of Images.xcassets.

And correcting that line meant that now the asset catalog with my icons is automatically getting used.

The only manual step left is related to code-signing, but I can otherwise run cmake and then build the Xcode project without a lot of manual fiddling.

And it feels great! In fact, I’m doing another little dance in my chair right now.

If you are curious, here’s the section of my CMakeLists.txt:


TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework AudioToolbox")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework AVFoundation")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework CoreAudio")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework CoreGraphics")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework CoreHaptics")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework CoreMotion")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework Foundation")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework GameController")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework ImageIO")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework MobileCoreServices")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework OpenGLES")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework QuartzCore")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework UIKit")
TARGET_LINK_LIBRARIES(${GB_PROJECT_NAME}-bin "-framework Metal")
TARGET_SOURCES(${GB_PROJECT_NAME}-bin PRIVATE "${PROJECT_BINARY_DIR}/data/resources/Images.xcassets")
SET_SOURCE_FILES_PROPERTIES(${PROJECT_BINARY_DIR}/data/resources/Images.xcassets PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
SET_TARGET_PROPERTIES(${GB_PROJECT_NAME}-bin PROPERTIES
MACOSX_BUNDLE TRUE
MACOSX_BUNDLE_INFO_PLIST ${PROJECT_SOURCE_DIR}/ios/Info.plist.in
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "${CODE_SIGN_IDENTITY}"
XCODE_ATTRIBUTE_ENABLE_BITCODE "NO"
XCODE_ATTRIBUTE_INSTALL_PATH "$(LOCAL_APPS_DIR)"
XCODE_ATTRIBUTE_SKIP_INSTALL "NO"
XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER "${MACOSX_BUNDLE_GUI_IDENTIFIER}"
XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_APPICON_NAME "AppIcon"
RESOURCE "${OTHER_RESOURCE_FILES}")


Unfortunately I still haven’t created iOS icons yet, but once I do, I think I am done with creating a successful and repeatable iOS build, and I can refocus on getting SDL2 and Android 11 working together again.

But last weekend I was out of town again and so I had less time to work on the project, which is why this report is a few days late, too. I did spend some time thinking of game mechanics and other ideas that I can’t wait to prototype.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

In last week’s sprint report, I was investigating problems with touch input related to some incompatibility introduced by Android 11 as well as figuring out why the latest SDL2 version forced me to change how I build it for iOS.

I continued to investigate the iOS build in this past week’s sprint.

Sprint 23: Make publishable

Planned and Completed:

• Nothing. B-(

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)
• Create iOS build

The above summary doesn’t indicate what I actually got accomplished, which were some subtasks under “Create iOS build.”

Notably, I learned a lot about why things are different. I mean, it’s still not clear on the SDL2 side, but Apple recently made changes due to their new M1 chip architecture.

In the past, I used a script which took libSDL2, libSDL2_image, libSDL2_mixer, and libSDL2_ttf, built them for multiple architectures, and combined them into what’s known as a “fat” universal binary.

So whether I am running my app in the iOS simulator or on an iPhone or iPad, it just worked.

Except the way that fat universal binary was created was to smash a bunch of different symbols for different architectures together, which worked fine so long as you could be sure that symbols for one architecture were different for another.

And with M1, which is ARM-based, that’s no longer the case. Now there are two different ARM-based systems possible, and lipo, the tool that combines them, won’t do it:

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: build/Release-iphoneos/libSDL2.a and build/Release-iphonesimulator/libSDL2.a have the same architectures (arm64) and can't be in the same fat output file

This is new as of Xcode 12.3, apparently. Or more accurately, it’s now being enforced, as it turns out that the way I was doing it (and many others, apparently) is not supported and hasn’t been for some time. Whoops.

So now my perfectly fine build system is no longer perfectly fine and I need to investigate.

And I know it isn’t that new to hear, but I hate working with Xcode. Ask me how many times I tried to change something like a library search path (which is annoying enough since there is no mechanism to find the path within the UI) and found that a big part of my configuration changed with no way to revert except to start over.

But I learned about Apple’s proposed solution of creating an XCFramework, and I spent time trying to figure out how to adapt my script to create one of those instead.

While I was at it, I realized that the way my build scripts worked wasn’t even taking advantage of the SDL2 framework I put together. I must have found that the framework was frustrating to figure out how to get Xcode to find and so I just pointed to the individual libraries instead of the single SDL2 library I bundled them all into.

Anyway, I found that I still struggled with getting the app to build with the new XCFramework, possibly because while SDL2 has a scheme for building a framework, the related libraries don’t.

After a few false starts in which my build scripts were still trying to find the individual libraries, I did manage to get to it to build using the XCFramework by manually adding it in Xcode since CMake doesn’t know what an XCFramework is yet, but then I get linker errors related to joystick-related code:

Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_CHHapticDynamicParameter", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticEventParameter", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_CHHapticDynamicParameterIDHapticIntensityControl", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
"_CHHapticEventParameterIDHapticIntensity", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticPattern", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticEvent", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_CHHapticEventTypeHapticContinuous", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Joysticks might be related to the hidapi target that SDL2 has, and perhaps I need to build it, too? How strange, and I wish the SDL2 docs said something about it.

Digging into the source for SDL2, I did find src/hidapi/README.txt which indicates that there are multiple platforms to build for, such as Mac OS X. But am I supposed to also do it for iOS? Why have I never heard of this before when it came to Linux, my main development environment? Or Android? I feel like I shouldn’t need it.

But I guess I’ll continue experimenting.

I got to spend a chunk of my personal Independence Day working working on it, and I gotta say, it was nice to be able to concentrate so much time on a hard problem at once. I doubled the amount of time I would spend on game development last week, and it feels like so much could get done with a week of such days.

What’s frustrating about not having that much time to dedicate to it regularly is that I have spent another week on trying to get things working so I can build on iOS again, and I haven’t spent time on figuring out the Android 11 issue, and what’s more I haven’t spent time on making my game itself better.

Not being able to ship a working game is a major problem, and since I’ve chosen not to use an existing game engine that presumably would have handled all of this for me, it’s on me to figure out. But it would be nice to have this working soon so I can get back to spending time on game design and implementation.

Still, I did get to show off the game to a live audience. The IGDA Des Moines chapter held its monthly meeting last Tuesday, inviting members to demo what they are working on for a few minutes and get advice from attendees. I showed off the game, and I got some great feedback.

One thing that was said that made me concerned was that “factory” in the title implies a factory-style game play. Since factory games is its own genre, there might be expectations from the title alone that the game play will match those found in Factorio or Big Pharma. I might need to find out if this is going to be a real problem requiring a name change…or maybe I just put it out there and see what the feedback is from real players.

It was also pretty cool to see what other indie game developers are working on.

Anyway, I expect that I’ll figure out this iOS build issue in the coming sprint. The main annoyance is that it seems to mean I’ll be doing MORE manual work within Xcode rather than being able to automate it through scripts and command line tools.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

Last week, I reported that I successfully created an Android emulator to investigate a few Android 11-specific issues that play testers found while trying out Toy Factory Fixer..

I continued my investigation.

Sprint 22: Make publishable

Planned and Completed:

• Nothing. B-(

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)
• Create iOS build

I originally had a few other features/tasks in my plan, but I recognized that I was being ridiculous with putting everything in my sprint. I have a project backlog for a reason.

So I put off adding extra levels and changing how the player is rated, and I focused on trying to get the game working on the platforms I plan to release it on.

Which meant my sprint was basically spent trying to figure out why Android 11 plays so weirdly with my use of SDL2, as well as finally getting around to the work of creating an iOS build.

As for Android, I spent some time initially trying to figure out how to build with the latest version of SDL2, which now also expect you to use the gradle build instead of ant as before, in order to use the new Android NDK and SDK, which may or may not help me either fix or at least investigate the problem. It definitely felt like yak-shaving.

I tried to see how far I could get while continuing to use the ant build, but certain key Android command line tools no longer exist or do not function the same, and so I hit a dead-end there. It looks like I need to figure out the change.

But in the meantime, I had a hunch. I had originally commented out some code that handled the events SDL_FINGERDOWN and SDL_FINGERUP because it turned out that on iOS Retina displays the values were not normalized as documented, which resulted in some problems when I tried to use them to specify where the simulated mouse cursor was. And this was fine, as I said last week, when the mouse events came in as expected, and they worked on Android and iOS the same.

But now that Android isn’t doing mouse events, what if I put that code back?

I could build with the old 2.0.12 version of SDL2 and the old dev tools, test it in the emulator, and I can do an “adb shell” to the emulator, then run “input tap” with x and y coordinates to simulate taps.

In my investigation, “input tap” definitely simulates tapping the screen, so I can launch my app if I provide the x and y coordinates that map to the app icon in my menu.

And now when I simulate a tap, I see that the values of the debug output changed to represent the position of the tap! Woo hoo!

So I sent a new build to my tester, and then while I waited to hear back, I decided to start working on the iOS build.

The iOS build has been fairly straightforward in general, but I figure if I am upgrading to 2.0.14, then I should do so there. Unfortunately, 2.0.14 changed some things for iOS as well. There used to be a directory called Xcode-iOS, and in it was a directory called SDL. I have a script to build the iOS libraries that I got from Tom Black, but it depends on that directory to build the SDL2 library.

Looking into the SDL2 commit history, I see that the SDL directory was removed last November, but it wasn’t clear to me why. After some more digging, the best I could figure out was that there was no more need for this iOS-specific Xcode project directory and that everything was unified into the Xcode directory?

I did find out that there was a file in the SDL2 build-scripts directory called iosbuild.sh, and when I ran it, it seemed to actually create the SDL2.a file that I was trying to create. I didn’t get to spend too much time trying to unify this knowledge into a functional build, however, because I finally heard back from my Android 11 tester.

The good news: tapping on the screen does in fact change the location shown by the debug input. He can even see the buttons on the main menu change based on what effectively works like mouse hover. In fact, when I test on my Ubuntu machine as my main development environment, mousing over the buttons does show them depressed, even if you don’t click, and that same effect occurs on the mobile app. Since there is no mouse, the last place you touched effectively acts like the current mouse cursor position, and so I already have a defect to fix in which it looks like buttons stay down when they shouldn’t.

The bad news: apparently all the app registers is the mouse position, and tapping does not, in fact, simulate a mouse button press like it should.

The good news from that bad news: I can see that same problem in the emulator when I use “input tap” which means I can be a bit more confident when I fix this issue. When I use the actual mouse with the emulator, I do not see a problem, but “input tap” apparently simulates the problem exactly.

I tried to change my SDL_FINGERDOWN/UP handling code to simulate mouse button down and up, but apparently it either does not work or it is too fast for my input code to register. My input handling is based on immediate mode GUI, specifically from reading Jari Komppa’s IMGUI docs, and so basically it takes a couple of updates to process whether or not an on-screen button has been pressed.

So I need to debug a bit more, but now I have an emulator and the knowledge that the input command in an adb shell can duplicate the behavior my play tester sees on his screen.

I also had a chat with a different play tester about a feature suggestion he had made – a Free Play mode. The idea is that instead of trying to finish a level, the game just continues indefinitely. I liked the idea, but I also recognized that I might have assumptions about what would appeal to him, so we talked about the details a bit.

One concern I have with merely having infinite toys is that eventually you can hire enough workers that they can too easily handle any number of Bad Toys coming down the line. Of course, I need to test my hypothesis. Perhaps I can create an algorithm that will increase the quantity and variety of Bad Toys being produced in a consistent way, and then see if the challenge eventually drops or if it can still be present.

Ultimately, this week was frustrating in that nothing got actually completed, but I did get closer to solving the Android 11 touch press issue, and I might contribute to an open source project as I resolve my iOS build issue.

But I’m looking forward to getting the builds figured out so I can get back to making the game itself better.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

In last week’s sprint report, I had added more sound effects and changed the way music played in Toy Factory Fixer.

In this past week’s sprint, I spent my time investigating why the Android build seems to work just fine on my devices but not on the devices of my testers.

Sprint 21: Make publishable

Planned and Completed:

• Nothing. B-(

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)

Not started:

• Award player based on performance
• Create multiple levels
• Create iOS build

To start with, I was hoping to do a lot more than I did. I was optimistic.

But there seems to be two problems with Android 11 that my testers have uncovered, and I worry about how inconsistent it seems to be.

One tester says that the game looks fine on his Android 11 device, but he can’t get past the main menu because tapping the screen seems to do nothing. It looks like the game is frozen.

So I sent him a custom build with some debug output that shows the state of the simulated mouse input, including the last known touch position and whether or not the “mouse button” is down. And just in case, I also added a counter that increases every second.

And I’m glad I did. Apparently the other debug text never changes, but at least the timer does, so I can confirm that no, the game is not frozen, but yes, there is a problem in which touch presses aren’t getting detected at all.

I had suspected that the touch presses were being detected offscreen, which is an issue I’ve encountered on iOS with the Retina display and how it handles touch presses, but no input at all? What gives?

I’m using SDL2, and it basically has two mechanisms for input. One is to detect the touches as independent fingers, so it is possible to do multiple fingers at once and detect pinch and zoom and such. The other is to treat touch presses as simulated mouse events. As I don’t currently have a need for multiple simultaneous touches, I pretend that the game just has a mouse, and it works great.

Except not anymore!

And since I still don’t have an Android 11 device to test on, what can I do? Maybe the Android emulator.

The docs are very heavily focused on using the Android development IDE, but frankly, I don’t wanna use the Android development IDE. I like my own setup, thank you very much.

Well, I am happy to say that after a little over 5 hours across the last week, I managed to get the command line tools to pull down the platform tools, the system images, and more to be able to launch an Android emulator.

I’ll write up what I did, since the docs can be confusing or conflicting or point to deprecated and outdated portions of the docs. I partly had to guess at what was expected as arguments. Some needed quotes, for instance.

Now you might think, “You had the Android IDE to do it for you. Why make it harder on yourself?” Because I wanted to. I wanted to know how it worked. I wanted to write a script to automate things rather than rely on clicking or dragging files manually.

Anyway, I’m still investigating the Android 11 issues, and now I have emulators I can run to help me test even with devices I don’t own.

But unfortunately, it is pretty much all I had done last week. I imagine with a few more hours I could have done more to determine what I can with the emulators, including noticing if there are any obvious differences between running the game with Android 10 and Android 11. I found an issue on GitHub that sounded similar, but apparently it was not quite the same issue I’m hearing about. Still, it sounds like some weirdness is happening with Android 11 and SDL2, and I want to see if I can contribute to figuring it out.

So no new updates to show off this sprint, but I have been experimenting with some level layouts. People on my mailing list got to see a video of one that I shared last week. Sign up for the Curiosities Newsletter if you want to also receive exclusive sneak peaks of the work behind-the-scenes.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

I wrote in the last sprint report that I’ve finally added audio to Toy Factory Fixer, which made the game feel more alive.

Last week I continued making the game audible.

Sprint 20: Make publishable

Planned and Completed:

• Create sound effects
• Create loading screen background

Not completed:

• Award player based on performance
• Defect: game seems unresponsive on main menu screen (Android)

Not started:

• Create multiple levels

I changed the music so that it now plays constantly and at different volumes rather than going silent when the conveyor belt is stopped. Starting and stopping the conveyor belt now makes a nice mechanical startup/shutdown sound.

I added sounds for workers. They now respond audibly when you ask them to do something. They even make nice swooshy swiping effects when picking up Bad Toys from the conveyor belts. You can hear them tear apart Bad Toys and put back together Good Toys. When they toss Good Toys back on the belt, there is a subtle but satisfying thump.

I started to worry about the size of the download. Adding audio definitely makes the entire game take up way more space. It’s mostly .wav files, but I have some .ogg files for the music and larger sound effects. Some of these files are on the order of 30KB to 70KB, some are over 100KB, and a few are even over 250KB.

I am not doing anything fancy with audio, but these numbers seem very large.

It’s been quite a few years since I have seen good discussion about it, but I know there are optimizations to be made.

For instance, I don’t rely on the audio being in stereo, so I used Audacity to change them all to mono, which halved the size of the files without sacrificing much in the way of audio fidelity.

And I got one suggestion this weekend to reduce the bitrate from over 700Kbps to 128Kbps, so I’ll try that this week.

The other minor change I made was to create a loading screen background. Up until now, it’s been a black screen with some text at the bottom to say what is loading, but now that other people are actually play testing it and playing it, I wanted to make it look a bit nicer.

Speaking of, I already got some really bad news from a play tester. Apparently, on his Android 11 device, the game is stuck on the main menu screen. No touches appear to be detected at all, as otherwise he should have seen some touch indicators appear on the screen in the form of a growing/shrinking gray circle.

At first I thought it was a potential compatibility issue, but another play tester reported that the game seemed fine on his Android 11 device…except instead of being in landscape mode like it should be, it was in portrait mode.

So something weird is going on, and I don’t have a recent Android device to test on. I have Android 6 on my old tablet, and Android 8 on my phone. I am due to upgrade my phone, and so now I have a reason to get one sooner.

I could try to use emulators to see if something can be reproduced there, but I never use Android emulators. It’s pretty easy to deploy to real hardware, so I just test on my devices. And setting up an Android emulator is painfully annoying, since you need to align the virtual device, the CPU/ABI, the Android version, and more just right.

But while I wait to get a newer phone, that’s what I’ve been finally investigating how to do. I’ll try to write up what I learn.

And before I started looking into that urgent defect, I started working on changing how the game ends. Currently, the game requires perfection: one Bad Toy shipped, and you failed!

Instead of being so Dark Souls about it, I wanted to let the player find ways to get better. You shipped 13 Good Toys and 4 Bad Toys? You get a C! Try to get a B next time!

This coming week is the start of my sixth month working on this one month project. I’m hoping to figure out why the game seems to be misbehaving on Android, and I haven’t even started porting it to iOS yet. I hope there are no surprises there…which probably means I should start porting now.

One of my testers suggested a Free Play option, and I like it enough that I might try to add it before the game is officially released.

I also recently watched a GDC Europe 2015 talk called “Game Feel: Why Your Death Animation Sucks” by Nicolae Berbece, and while my game is meant to be a non-violent one, it did give me some thoughts about ways to give the game more personality. Many years ago, Josh Larson of Numinous Games once gave me the advice to make my game graphics more “juicy” which was along the same lines of thought.

For instance, while there is now a sound when a toy lands on the conveyor belt, a dusty particle effect would help sell the impact more. And having the workers look at toys they are planning on picking up would be a relatively simple thing that could help with the fact that they otherwise don’t animate at the moment.

I started experimenting with what it might look like, and, uh, it could use some work:

Perhaps separating Bad Toys can show some toy stuffing falling on the ground, and earning money could have some pizazz to make it a bit more exciting than it is, too.

I’m not sure if there any opportunities for screen shake, but never say never.

Hmm, it sounds like I’m taking on feature creep, and, well, maybe it is. We’ll see how much ends up in the first release versus a later update.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!