Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Worker Animations

In last week’s sprint report for Toy Factory Fixer, I added new worker types.

I continued to focus on the workers last week.

Sprint 32: Worker polish and training levels

Planned and Completed:

  • Animate worker putting down toy

Planned and Uncompleted:

  • Make worker eyes follow to nearest toy on belt
  • Move toy parts towards inventory
  • Create floor training levels/tutorial

After adding some simple yet effective enhancements to the toy movement that I thought made the game a lot more enjoyable to experience, I thought it seemed odd that the workers continued to stay stationary, so I thought I should do something.

Early in the week I managed to separate the arms from the workers, and I created a way to rotate the arms based on time relative time it takes for a toy to move.

But first, I had some fun with them. You know, to test it out:

Toy Factory Fixer - worker arm animations

Ultimately, I ended up creating a specific motion for the arms to flip toys into the air, which works for both throwing separated toy parts into the inventory and throwing a crafted Good Toy onto the conveyor belt.

Toy Factory Fixer - worker arms animated

Before I could work on anything else, I found that there was a strange flicker with the arms that occurred if there were multiple workers. It took a bit of investigation, but the arms animate if the worker has finished either crafting a Good Toy or separating a Bad Toy. Crafting and separating happen at the same time, but toy parts will go into the inventory first, then Good Toys will be thrown onto the conveyor belt.

All well and good, except I reuse the same variable to manage a timer to move toys in each step, and I reused that same timer to manage the rotation of the arms.

Now, each step only occurs if it needs to. That is, if there is no worker putting down toys, then those sequences and the use of the timer for those sequences won’t happen.

So when you have one worker, or when you have multiple workers who all finish separating toys at the same time, nothing goes wrong, but when you have multiple workers who aren’t doing the exact same thing at the same time, then the timer, which governs the rotation of the worker’s arms, rotates the arms during an irrelevant step. It was too easy for things to go wrong due the overuse of a single variable.

So, for example, a worker who just finished separating toys will launch the toy parts into the inventory, raising their arms and lowering them back down based on the same timer that is moving the toy parts into the inventory. But then that same timer starts over for the next phase, and so that worker will raise their arms again even though they shouldn’t.

In the end, I ended up adding more states for the worker to represent when they “celebrate” finishing the job of separating or crafting a toy, and it made it easier to manage. The arms only animate when the worker is in one of those celebration states, and immediately after that animation ends, I change the worker’s state so that they don’t animate the arms anymore.

The next thing I started to look at was changing what happens to separated toy parts. Currently, they fall offscreen, but I think it would be more intuitive if they were thrown at the inventory on the right side of the play area. So a small bear head would get thrown at the small bear head inventory icon, and perhaps it would animate to really make it clear that the small bear head quantity is going up.

It turns out that it would take quite a bit of work to change the static inventory widget that only redraws when there is a potential for the inventory numbers to change, and I ran out of time to work on it this past week. I expect to get it done early this coming week.

I didn’t purposefully mean to do any work on creating the training levels, but between having new worker types and testing their animations, I ended up playing through a few different sessions and figuring out that I actually have a fairly enjoyable game coming together, even with it being unbalanced. I need to create a solid set of levels before I release it to the world, but it’s exciting when you realize that you got distracted from testing something because the game itself distracted you.

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – New Workers

Last week, I reported that I had added a lot of “juiciness” to the toy animations as well as some other enhancements, and I made changes to the end of game grading of the player’s performance.

This past sprint, I wanted to focus on the workers.

Sprint 31: Polish and end game

Planned and Completed:

  • Create different types of workers

Planned and Uncompleted:

  • Animate worker picking up/putting down toy
  • Make worker eyes follow to nearest toy on belt

I added two new worker types to the game. One type is significantly stronger and so more capable of separating Bad Toys, but they can’t craft Good Toys as well. The other type is an expert at sewing and does a great job of crafting Good Toys but is terribly weak and can’t separate Bad Toys into parts as easily.

So the idea is that when you hire a worker, you have a tradeoff you can make. Maybe you want your strong workers closest to the dispenser to catch and work on Bad Toys as fast as possible, and your sewing workers can be closer to the shipment chute. Maybe you want the jack-of-all-trades regular worker who isn’t great but isn’t terrible at any job.

I found it straightforward to add the new types to the game in terms of updating the hiring menu. I already had the strength and craft stats in the game, so it was a matter of creating workers with different stats.

I needed new art, though, so I spent some time doodling some concepts.

I wanted the strong workers to come across as muscle-bound, large, solid characters, so the characters were more blocky and rectangular.

Toy Factory Fixer - Strong worker concept art

I wanted the sewing experts to read as more dynamic and speedy, and I experimented with triangle-based character designs.

Toy Factory Fixer - Sewing worker concept art

In the end, I went with these two as the base of my sprites:

Toy Factory Fixer - Sewing Worker

Toy Factory Fixer - Strong Worker

I started out drawing them at 1024×1024, being a bit sloppy but getting the basic line, shadow, and lighting in. Then I scaled down to the size they are in the game, and it more or less held up.

I added texture and color to the strong worker before scaling down, and the end result wasn’t very clean.

I scaled the sewing worker before adding color and texture, and it felt like I had more control over the end result.

Toy Factory Fixer - Sewing Workers scaled

Toy Factory Fixer - Strong Workers scaled

And here’s the updated hiring menu.

Toy Factory Fixer - Hiring menu with three worker types

One thing I need to do is figure out if the hiring cost makes sense. Right now, I am operating on the idea that the experts are worth more than the well-rounded worker, but maybe it doesn’t work out that way in actuality, so their costs and stats might change before I release the game.

I would love to get the workers animated. At the very least it would possibly help to see them moving their arms and blinking their eyes. When they toss the toys on the conveyor belt, I’d like to see them actually look like they are doing so. Maybe do a celebratory dance once in awhile. Something to make them look more alive.

And the more I play test, the more I am not a fan of the current variations of the worker barks. I tried changing the pitch to make it sound slightly different, but I think I made them too different. In the end, it makes it sound like the wrong audio cue is playing.

I’ve got a lot of work ahead of me, but I think I am close to making a releasable version of the game. I was hoping to have it out by my birthday next week, but it isn’t looking like I’ll make it. Still, it’s close, and I’m excited.

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Toy Juiciness and Player Grading

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:

Toy Factory Fixer - Impact dust cloud animated

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:

Toy Factory Fixer - Toy movement juiciness

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:

Toy Factory Fixer - Game Over screen

And here’s what it looks like today:

Toy Factory Fixer - Level end grade report

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Sound Effect Variety and Animation Juiciness

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.

Toy Factory Fixer - Impact dust cloud

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):

Toy Factory Fixer - Impact dust cloud animated

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Android Defect Fix and New Dispenser Art…Again

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.

Toy Factory Fixer - Animating Dispenser

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.

Toy Factory Fixer - Dispenser animation

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Android Defect Fix and New Dispenser Art

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.

Toy Factory Fixer - Old vs New Dispenser

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – iOS Icons, Android Updates, and Design Tweaks

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Solving iOS Build Issues

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:

Xcode is annoying

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.

Toy Factory Fixer running in iOS simulator

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!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Xcode/iOS Woes and Demoing in Public

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:

Xcode is annoying

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!

Categories
Game Design Game Development Geek / Technical

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.

Toy Factory Fixer - Debug output

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!