GBGames

In my previous sprint report for Toy Factory Fixer‘s development, I had added some enhancements that make it clearer to the player (and potential viewers of a future Let’s Play or even just a family member watching over the player’s shoulder) that the Bad Toy parts get thrown into the inventory.

For this past sprint, I wanted to focus on continuing to make workers seem a bit more than static robots, as well as start work on creating actual levels rather than the test ones I have been using since the beginning.

Sprint 34: Worker polish and training levels

Planned and Completed:

• Make worker eyes follow to nearest toy on belt

Unplanned and Completed:

• Test feedback: not clear what you need to do (such as hire workers)
• Finalize grading algorithms

Planned and Incomplete:

• Create floor training levels/tutorial

I had a very productive week in terms of game development. I mean, relatively productive. I am still doing this work very, very part-time, but I found I was able to focus on the work for longer sessions and so things came together more and I was able to be more thoughtful with my efforts.

I even have to split this report into sections!

Worker Eye Tracking

Anyway, I separated the pupils from the worker sprites so that I could animate them separately, which resulted in some creepy visuals at first as at first I only rendered pupils when the eyelids were blinking:

I don’t have a one-to-one correspondence between an in-game object such as a worker and its sprite. The way the game object is rendered is handled separately from the logic related to that game object, which might sound like it is possible to overcomplicate things, but I found that it simplifies the code of each.

Retroactively adding animations such as pupils pointing towards the nearest Bad Toy required adding a way for workers to target a nearby toy, and offsetting pupils properly for each worker type. I got this work done very quickly early in the week, and I was more or less satisfied with the results.

And getting it out of the way early meant that I could focus on level design, something I’ve been neglecting for arguably way too long.

Intro Level Design

Up until now, I’ve had a few levels that I’ve used to test things out early on, mainly so that the game play had a place to live.

But now I wanted to work on what levels will be in the final, published version of the game.

I don’t have a lot of experience with level design. I think I’ve picked up on social media from other developers that a first level is probably something you should make after you’re almost done with everything else. As a first level, it is the main introduction to the game for your players, and if you’re still tweaking balance or game play, you could end up doing a lot of rework.

At the same time, I know that I want to introduce the game gradually to the player, so a stripped down first level seems easier to start with. And since game development is an iterative process anyway, I can start by roughing out levels and expect to come back to them as a feature of the work and not a mistake.

So I added a level configuration that limited what workers would show up as available to hire in a level. On the first level, I’ll only allow one type of worker.

Then, I wanted to make sure that there wasn’t much for the player to do. So I had the entire level consist of two Bad Toys, which the player than crafts into two Good Toys. The idea was that the player gets a super basic intro to how the game works.

Updating Grade Calculations

And then I saw the end of level performance review, which grades the player on three things.

One is based on whether or not you let any Bad Toys get shipped, which you pretty much can’t in this level. So, an easy A for quality.

Another is based on whether you completed the level quickly. Basically, I compare how many turns it takes a player to how many turns I think are optimal. This level is small, and I was able to figure out an optimal number of turns for it manually, add it to the level configuration, then change the shipping deadline option to match it as an optional challenge for the player rather than the arbitrary deadline options I had before, and even fix the grading so that it calculated it correctly (whoops, it has been wrong for weeks!).

But the third thing the player was graded on was Return on Investment. Basically, did you spend less than you earned? By how much? I needed to tweak how the grade was calculated here as well. It was failing the player (uh, mainly me) for what I thought were respectable ROI numbers. So now it’s not quite linear in that anything less than 0% ROI is a failing grade, anything under 100% is a C, and you get better grades now for doubling or tripling your ROI.

With the way the level was currently designed, it was impossible to get a passing grade here. You always spent more hiring the worker than you could earn from two Good Toys shipping successfully.

So what are my options?

• I could get rid of ROI. I have struggled with grading the player on how well they can do by hiring fewer workers, partly because of the commentary on labor that it introduces. Then again, I think it adds a strategic element to the game.
• I could get rid of ROI for the training levels only. So you will be graded on quality and optionally (at the player’s discretion?) speed but not on how much money you earn because, you know, the factory is paying for your training.
• Make the training toys worth more? That way, the math works out that you ace the ROI artificially, but then that would be confusing for future levels. I’d probably need to communicate that these are special training toys, and that seems like a lot of extra work.
• Add more toys. Basically, this goes from being a quick training level to being a full-fledged introductory level.

I decided to flesh out the level, adding more toys. It’s still limited in that it gives the player only one worker to worry about, and there are only small toys, but instead of being short and sweet and potentially boring, it gives the player more credit by making it a challenge to ace all three grading criteria while still allowing the player to get passing grades even with mediocre play.

Basically, instead of one production run of only two toys, there are now multiple production runs that gradually increases the number of toys dispensed in a row, and eventually introduces toys dispensed together in a single batch.

The nice thing about having the ROI grading criteria more nailed down is that it gives me a rough sense of how many production runs and toys a given level should have. Basically, expect that perfect play means you will get at least 300% ROI. While I still find level design is complicated, with needing to figure out the effects of conveyor belt layout, production run configurations, starting money, and more, having the A+ == 300% ROI gives me at least one thing to anchor the design to.

I’m finding that I am tweaking things such as the cost to hire a worker, both to make it easier to hire more workers (it is more fun to see lots of workers than fewer workers) and get a good ROI (getting a good grade is more fun than not).

As I said, I probably should have been doing a lot of this work earlier, but I am glad I got to focus on it as much as I did last week. There were a lot of questions that came up that had no wrong answers and a lot of potential areas to explore, such as how long a given level should take or how optional some of the grading criteria should be.

Streamlining New Player Experiences

Finally, as I was trying to play the game as if I was completely new it, I decided to address a concern pretty much every tester brought up more or less directly: it is not clear what you’re supposed to do when you first play the game.

The very first thing you should do is hire a worker, but it is easy to miss the “Hire” button. I could add tooltips, or a bouncing arrow pointing at the hire button, or otherwise make it clear you should go there right away.

Or, what I ended up doing was changing the default menu to the Hire Worker menu instead of the main in-game menu. So right away, the player knows to hire a worker, instead of being expected to figure out that they should do so AND how to do so.

I even disabled the “Go” button until there is at least one worker hired, so if the player exits out of the hire menu, they can’t really start the level until they go back to it and hire a worker.

Summary

The game has a little bit more polish, some tweaks to how it rewards the player’s performance, and a more streamlined introduction to the game play that doesn’t leave the player wondering what to do.

I also gained a lot more insight into what the level design work is going to look like going forward.

That’s not bad for a week’s worth of part-time work.

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 focused on enhancing the workers by animating their arms, which helps make Toy Factory Fixer just a little more enjoyable to play. I wanted to continue making the workers more interesting in the next sprint.

Sprint 33: Worker polish and training levels

Planned and Completed:

• Move toy parts towards inventory

Planned and Uncompleted:

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

A big part of what the workers do is separate Bad Toys into parts. I had the toy parts merely fall off the bottom of the screen, but the inventory count on the right would increase. Yet, it was not very clear that there was a connection.

So I fixed it. Toy parts now fly from the worker’s hands to the inventory, making it clearer that the parts are added to the inventory.

I even animated the icons in the inventory so that you knew which ones were getting increased.

And I made the toy parts rotate because everyone loves things flipping through the air.

I decided to try adding particle effects, because why not?

I wanted to create a cartoony cotton fluff to represent the stuffing coming out of the toy parts, but trying to draw them from real references was awkward. I ultimately ended up looking at Winnie the Pooh and the Honey Tree.

But my cotton fluff looks more like a dust cloud, especially since it fades over time. I’m not entirely pleased with how it looks, and so I think I’ll change it.

Ultimately, I spent all of my time on getting the toys to move to the inventory and getting things to animate that I didn’t get to other worker enhancements such as eye movement. The arms move, but they still look dead inside, and I would like to make them look more emotional.

But more importantly, and perhaps in hindsight what I should have been doing for many months, I need to focus on creating levels.

I’ve been tweaking a few things as I have been play testing, especially once I added the new worker types a few weeks ago, but I need to create a few solid intro levels.

In the meantime, I’ve gotten more play tester feedback, and some of the things I want to do to address that feedback seems critical for a first public release.

It feels simultaneously like I am so close to creating that first publishable version and also so far away because it takes me weeks of part-time effort to do what would probably take me mere days if I was focused on it full-time.

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

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.

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!

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.

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

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

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.

And here’s the updated hiring menu.

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!

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

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

Sprint 30: Polish and end game

Planned and Completed:

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

Unplanned yet Completed:

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

Unplanned and Uncompleted:

• Create different types of workers

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

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

And the game itself feels a LOT better.

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

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

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

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

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

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

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

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

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

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

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

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

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

And here’s what it looks like today:

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

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

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

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

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

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

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

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

Thanks for reading!

—

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

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

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

Sprint 29: Make publishable

Unplanned yet Completed:

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

Planned and Uncompleted:

• Add juiciness to toys landing on conveyor belt

Planned and Not Started:

• Award grades to player performance

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

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

Over and over. It gets old.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I’ll spend time on it this coming week.

Thanks for reading!

—

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

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

Sprint 28: Make publishable

Planned and Completed:

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

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

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

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

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

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

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

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

WHAT?!

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

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

The SDL2 wiki says:

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

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

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

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

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

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

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

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

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

Fingers crossed!

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

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

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

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

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

Thanks for reading!

—

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

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

Sprint 27: Make publishable

Planned and Completed:

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

Not completed:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading!

—

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