Freshly Squeezed Progress Report – Still Debugging and Emulating

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!