GBGames

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!

In last week’s sprint report I managed to do a bunch of unplanned work and fixed a number of defects I had introduced in previous sprints for Toy Factory Fixer.

This time, I finally started addressing the audio for the game.

Sprint 19: Make publishable

Planned and Completed:

• Nothing…

Not completed:

• Create sound effects

Not started:

• Create multiple levels
• Create loading screen background
• Award player based on performance

This past week was not nearly as productive as the one before. I did, however, manage to make the game come alive by adding sound effects and, as a last minute decision, some music.

I am not an audio person. Many of my past projects have used the awesome tool by DrPetter called sfxer, which allows me to generate sound effects for various common game-y events such as picking up items, attacking/hitting, etc. The effects tend to sound like they are made for a video game console from the 8-bit or 16-bit era.

But for a less stereotypical video game sound, I decided to look through the various audio libraries I’ve managed to get access to. Whether through a Humble Bundle or itch.io bundle purchase, or finding libraries that were freely given away (such as these hundreds of gigabytes of sounds from Sonniss), I have a LOT of royalty-free licenses already on my hard drive.

I’ve used SoundRangers and have been happy with their paid sound effects for other projects, and I might still use them for this one, but I found I was able to get some high-quality audio from my existing libraries.

I added sound effects for clicking buttons, including a separate effect for choosing an option as opposed to confirming a selection. There are effects for dispensing toys and earning money. I still need to add sounds for workers doing work, so I’m checking into some fabric tearing sound effects. I have some voice effects that I can also see using whenever you select a worker.

Now I wasn’t planning on adding music, but between the toy dispensing sound effect getting tedious and discovering I had some decent music in my collection, I quickly threw something in, and I found that it worked pretty well. If you are curious, the music is called “In a Hurry” and comes from a Puzzle Audio Kit by Evil Mind Entertainment that I got as part of the Humble Sound Effects and Music for Games, Films, and Content Creators Bundle.

Now obviously a custom and unique audioscape created by an expert would make for a better experience. The downside is that it would cost some serious money, and as this game is going to be given away for free, I’d rather save that effort/expense for a premium offering in the future, and I’ll risk my game sounding like another game. I remember that Starcraft used sound effects that I know I’ve since heard in movies.

For now, though, my humble efforts managed to make this game feel like it has leapt forward in terms of being ready for a wide release.

You can hear it for yourself in this video:

I wanted to take a cue from the game Dig Dug, in which music only plays when you are taking action. So the music mutes when you stop the conveyor belt and unmutes when you start it.

But I got some great feedback already about raising/lowering the volume instead, so as to make it seem like the action is still happening. And I like it, so I think I’ll make that change.

Part of the reason I wanted to add audio now is that the game is about ready to be playtested by actual testers. It’s probably been ready for playtesters for months, but as I’ve said before, I’ve a very, very part-time indie game developer, so it’s been slow in making this all come together.

But I wanted audio because I wanted to avoid getting feedback that the game was silent and needed audio. So now I expect to hear feedback that the audio stinks, but I’ll tackle that problem later.

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 wrote in my sprint report about other obligations preventing me from making much progress on Toy Factory Fixer a couple of weeks ago.

This past week was very different.

Sprint 18: Make publishable

Planned and Completed:

• Create production-ready level

Unplanned and Completed:

• Create a level select screen
• Create indicator to show workers are clickable
• Create indicator to give level configuration feedback
• Defect: prevent worker placement next to shipping chute
• Defect: prevent production run button appearance when it isn’t valid to show it (crash)
• Defect: the last shipped Good Toy does not reward player before game ends

Not completed:

• Create sound effects

I don’t exactly know what happened this week, but I was a lot more productive.

I created a level selection menu, and I was fairly impressed with myself in terms of how quickly I was able to do so, complete with highlighted buttons to indicate which level you currently have selected as well as showing a description of that level.

I also fixed a few annoying bugs. In particular, there was a crash bug that was the result of the UI not updating to get rid of a button if there is no active production run of toys coming.

I also realized during my own play testing that since the game ends as soon as the last toy ships, then the reward for shipping a Good Toy is missing. I changed it so that the game doesn’t end until after the potential update occurs.

During play testing, I found that it was not very clear that the workers themselves are meant to be clicked/tapped. So I temporarily fade out and in the color of idle workers at the end of each turn if there are enough toy parts to craft a Good Toy. It’s possible I need to do more to make it clear, and there is still no indicator when the player has stopped the conveyor belts, but it might be enough for now.

There were some other minor changes, such as the color and shape of the dispenser production run button, as you can see above.

And I also found that the current level configuration menu gave way too subtle feedback about what you were choosing, so I made it more prominent, if redundant:

The custom deadline is meant to be a temporary configuration setting, as I should probably make use of the automatic deadline calculation I came up with in the previous sprint, but it’s good enough for someone to test.

And that’s my immediate goal: get this game into the hands of testers. So far my only play testers have been my wife and my son, and I think once I add sound effects I’ll feel comfortable getting feedback from people who aren’t related to me.

And adding sound effects, while originally planned as work for this sprint, didn’t happen yet. I pulled in other work as it made sense, and I’m fine with the “last-minute” prioritization.

Over the weekend I was going over some of the sound effect libraries I have access to, and I think I found some nice ones for the workers and button presses. I am less sure about music, but I can worry about it later when it is clearer how the mood of the game is coming together.

There are other minor things I need to fix, such as the loading screen being black instead of a color that matches the beige of the floor or the orange of my logo. Maybe I’ll do them 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!

Joris Dormans, co-author of Game Mechanics: Advanced Game Design and game design researcher, is also an indie game developer who focuses on emergent game play and procedural content generation.

While it is not unusual for indie games to use procedural generation, his 2017 game Unexplored leaned on PCG heavily in its marketing as a selling point.

And Boris the Brave wrote a series of articles explaining how it works!

Lock and Key Dungeons focuses on a common level design technique to create a sense of progress and provide challenges to players.

Graph Rewriting for Procedural Level Generation is about a seldom-used yet well-understood technique for generating sophisticated levels.

PhantomGrammar and Ludoscope digs into the custom tools that Dormans uses for graph rewriting and visualization.

Dungeon Generation in Unexplored dives into how Unexplored’s world is generated using the above tools.

It’s one of those “detailed yet leaves me hungry more more details” kind of things.

In my previous sprint report, I said I was frustrated that my very part-time efforts on Toy Factory Fixer had to slow down due to other obligations.

This past week’s sprint was similarly slow.

Sprint 17: Make publishable

Completed:

• Nothing

Not completed:

• Create production-ready level
• Create sound effects

I only worked for a few hours last week, much like the previous week. I needed time to prepare to give a presentation for the day job on Friday.

I explored what math model I could use to automate the calculation of a turn limit. My thinking was that as levels get created, it would be nice if I could just turn on shipping deadlines and have a reasonable deadline generated.

And so far the total number of the conveyor belt segments and the total number of toys seem to get me there, so long as I set things up so that a single worker has a reasonable chance of dealing with everything by themselves.

I found that depending on worker placement, I could finish shipping all the Good Toys within 5 turns of the deadlines I was calculating.

Once I added a second worker, I found that the minimum number of turns can drop significantly. And this makes sense: more workers means more productivity happening simultaneously. But I need to explore this dynamic more to see just how adding more workers impacts how many turns it takes to finish a level.

However, if I allow myself to put on my producer hat, I think it was a mistake to spend time on it. I still don’t have a good “first” level, and since I haven’t even made a level-generator or a level-creation tool for myself, let alone for players, did I really need to automatically generate a turn deadline?

So why was I working on it? Probably because it wasn’t exactly clear what it was that I should be doing.

I will say that I know that “Create production-ready level” isn’t a small task, but I think it is still very vague in terms of what it means to say I’m done.

What does “production-ready” mean? How do I know when I’m done? What are my criteria?

I know that I need to play around with the mechanics and see how they work together. I need to explore the play space, see what’s possible, and then figure out what makes a good introductory level.

But somehow I distracted myself with automating turn deadline calculations. I mean, it might come in handy later, but it could have waited.

Ah, well. Maybe this week will be more productive.

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!