Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Making More Noise

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

Last week I continued making the game audible.

Sprint 20: Make publishable

Planned and Completed:

  • Create sound effects
  • Create loading screen background

Not completed:

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

Not started:

  • Create multiple levels

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Toy Factory Fixer - Worker Personality

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

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

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

Thanks for reading!

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

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Let’s Make Some Noise!

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

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

Sprint 19: Make publishable

Planned and Completed:

  • Nothing…

Not completed:

  • Create sound effects

Not started:

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

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

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

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

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

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

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

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

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

You can hear it for yourself in this video:

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

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

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

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

Thanks for reading!

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

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Levels and Addressing Feedback

Last week, I wrote in my sprint report about other obligations preventing me from making much progress on Toy Factory Fixer a couple of weeks ago.

This past week was very different.

Sprint 18: Make publishable

Planned and Completed:

  • Create production-ready level

Unplanned and Completed:

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

Not completed:

  • Create sound effects

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

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

Toy Factory Fixer - Level Selection

Toy Factory Fixer - Level Selection

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

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

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

Toy Factory Fixer game play

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

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

Toy Factory Fixer - Level Configuration

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

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

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

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

There are other minor things I need to fix, such as the loading screen being black instead of a color that matches the beige of the floor or the orange of my logo. Maybe I’ll do them this coming week.

Thanks for reading!

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

Game Design Game Development Geek / Technical

Exploring Procedurally Generated Dungeons in Unexplored

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

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

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

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

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

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

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

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

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Creating a First Level

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

This past week’s sprint was similarly slow.

Sprint 17: Make publishable


  • Nothing

Not completed:

  • Create production-ready level
  • Create sound effects

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading!

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

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Optional Deadlines and Deeper Insights

In last week’s sprint report I started taking steps to make the game Toy Factory Fixer releasable at least to play testers.

There are things as a developer I could tweak in code, but I want to give the player options to make changes, and so I continued that work in last week’s sprint.

Sprint 16: Make publishable


  • Create way to choose if game has deadline or not

Not completed:

  • Create production-ready level
  • Create sound effects

I only managed to work a little over 2 hours on the game last week. Between a few deadlines at the day job and needing to investigate my son setting up his own Minecraft server using a website we explicitly told him he couldn’t do, I found myself using the time I normally would work on game development to do other urgent things.

In a way, I’m frustrated because while I know there is still quite a bit to do to really finish Toy Factory Fixer, it feels like I am letting my foot off of the gas pedal right when I’m nearing the end.

I have averaged a little over 5 hours a week on game development these last three months, and it is noticeable when I put in less time last week.

I managed to implement a configuration for the player to choose whether or not to play with a shipping deadline, which is kind of like providing a way to choose an Easy or Challenging mode.

The game is still completely silent, and even though I’ve been listening to some music that may or may not make it into the game, I think at the very least there should be sound effects to give the player feedback when something happens or when they perform an action.

At the very least, I don’t want play testers to say, “You should add sound effects” when they could be focused on any of the other things I haven’t considered instead. B-)

As for putting together a good production-ready level, I spent some time doing some deep thinking about the dynamics of the game, and I was blown away when I realized that an assumption I made about the best location for a worker was completely wrong.

Toy Factory Fixer - Worker placement

I figured that a worker placed so that it was near the greatest number of conveyor belt locations was the best. I figured it meant more opportunities to pick up Bad Toys.

But it turns out that the best location is a function of the worker’s toy separation rate, the toy’s health, and the distance between opportunities to pick up a toy. In the screenshot above, a Bad Toy will pass by above and below the worker. If a worker picks up a Bad Toy, during the time spent working on separating that toy, other toys will continue along the line.

When the worker is finished and becomes idle, another Bad Toy within reach can be picked up. It is possible for the next Bad Toy to have moved on too far for the worker to reach if the worker is too close to the turn.

I am still working on balancing numbers such as the number of stitches a toy has or how much strength a worker has, but this kind of analysis hasn’t been done yet, and it is already giving me insights into what makes for a challenge, what is too easy, and what might be impossible.

Now I just want to spend more time on actually making 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!

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Almost Done?

Last week’s sprint report for Toy Factory Fixer focused on the work of allowing toys to occupy the same conveyor belt tile without overlapping and making the dispenser put out more than one toy at a time, which opens up ways to change the flow of the toys in the game.

Next up was letting the player start production runs of toys earlier.

Sprint 15: create an economy


  • Allow player to start production run early
  • UNPLANNED: Create Android app icons

Not completed:

  • Create way to choose if game has deadline or not

Stretch if above got done:

  • Create sound effects

I originally wanted to release this game within one month, but it didn’t happen. Between working very, very part-time on it and it still taking longer than expected, I haven’t been doing all of the other things I anticipated doing after this project was released.

As such, I realized it has been a few months since I last put something out in the Google Play or Apple App Stores, and it is entirely possible that they changed something on their end that might require me to update my own build and release process to be compatible.

Up until this past week, all development and testing has occurred on my main Ubuntu desktop system. At the very least I can put the game on my Android phone and ensure it works there.

So I created some basic app icons, which feature the toy bear. It’s not the typical angry man yelling face that you see in almost every other game’s app icons, but I am sure it will pass review.

The game seems to work fine on my phone, although I noticed some issues with the ways buttons look when you use the touch press instead of a mouse cursor. Basically, the mouse cursor is invisible, and so buttons look like you are pressing them even when you are not. I think I remember fixing this issue in a previous game, so I will see if I can steal my own fix for it.

Otherwise, the other major piece of work allows the player to start a production run earlier. Before, the details about the next production run would appear when you have less than 10 moves left before it starts. Now, you get a simple button that tells you the number of turns, and if you click it, it opens up the detailed view.

Toy Factory Fixer - Start Production Run Early bonus

You are now presented with the option to start the run immediately, with a note that explains that you get a money bonus if you do so.

So now you have the choice of starting the production run early and getting rewarded for it, or waiting it out, which you might choose if your workers are currently overwhelmed with the existing toys.

As you can see, I also rearranged the UI and changed the level layout slightly so that everything is visible. It feels a lot better, and I spent way too long with the old look that covered up parts of the game.

I started work on adding a screen to let you configure the game. The only option at the moment is to let you play with or without a shipping deadline. I like the deadline since it provides pressure on the player to get your workers crafting Good Toys earlier even as Bad Toys still need to be handled, as I’ve described in previous reports. But I also recognize that some players might prefer not having that pressure.

But once this option is available, I think there’s only one other thing I want in the game before I would say it is finished enough to release.

Well, a few things. I let my wife and my son play on my phone, and I got some feedback about UI and what is hard to understand or what looks strange. So I want address some things.

I also want to add a cost to having a lot of workers. My son successfully finished the game level by hiring lots and lots of workers. Which is fine, but it shouldn’t be so easy, and I’m sure even if I spend time balancing the numbers it won’t be much more challenging.

So I want to add something to the game that discourages hiring too many workers. My current thinking is an end of level wage that needs to be paid, so you can pay to hire a lot of workers, but then you have to pay them at the end of the level based on the current shift’s wages. If you can’t afford the wages, you lose.

I like it since it gives the player another victory/loss condition to worry about, but I worry that the feedback for the player is too late. I don’t want people to get frustrated when they feel like they did well only to lose in the end because it wasn’t clear how to pay attention to the wages. And I’m not sure I like the message it sends about labor and pay.

So perhaps there needs to be some kind of arbitrary limit to hiring that you can impact in-game, such as needing to pay to upgrade the factory’s worker capacity. “Expand Restroom Size” and “Create Larger Breakroom” and things like that? Maybe it will be more intuitive and immediate for the player.

It merits some exploration. And maybe I’ll do both.

I should also spend time creating levels for the player to advance through. Right now there is only the one level. I’d prefer to have it generate levels, but maybe that’s a future feature. For now, I want to have at least a few levels that increase in challenge and variety as you play through them. And level design isn’t something I can just churn out in mere minutes.

And of course, it would be good if there were some sound effects.

And I keep thinking about how the game needs more juiciness, some character. The general art direction is lacking in any kind of personality or consistency. In my head there were named workers, people to relate to, but that’s not implemented. It feels like extra, but maybe that’s the kind of extra a game needs to avoid feeling lifeless.

So maybe I’m not almost done after all. It feels like I have at least another month of work on it. But the game is definitely playable already, and I look forward to sharing it with play testers.

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!

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Dispensing More Toys At Once

Today is the 15th anniversary of GBGames, LLC being founded!

It would have been an awesome day to launch a new game, but alas, Toy Factory Fixer is not ready for release. However, I will be asking people on my mailing list if they want to sign up to try the game early.

Interested in being one of those people? Sign up for the GBGames Curiosities newsletter today!

In last week’s sprint report, I created an indicator to show details about the new production run of toys coming down the conveyor belt as well as created a shipping deadline to encourage the player to have some urgency when it comes to creating Good Toys earlier in the game.

Last week, I focused on making it possible for more than one toy to exist in a single conveyor belt location at once.

Sprint 14: create an economy


  • Allow multiple toys to occupy same belt space
  • Defect: Fix Z-ordering so mouse goes over the HUD

Not completed:

  • Create way to choose if game has deadline or not
  • Allow player to start production run early

Stretch if above got done:

  • Create sound effects

Because early on I wasn’t sure how large the play area or tiles were going to be, I made toy positions based on tiles instead of the screen area. This worked great in terms of being able to render them anywhere since I could just multiply their position by the size of the tiles. That is, a toy located at position (3, 1) with tiles of 64×64 pixels square would be at (3 * 64, 1 * 64) or (192, 64).

The fun thing is that their positions were already floating point numbers, so I could make it look like they were a bit more randomly placed by adding a small offset that is less than one. I can find out which tile they were on by taking the floor of the number, so a toy at (3.25, 1) would still be on the tile at (3, 1), but it would get rendered at (3.25 * 64, 1 * 64) or (208, 64) instead of (192, 64).

Just jiggling the offset of toys being placed on the conveyor belt with -0.25, 0, or 0.25 in both the X and Y directions made for a pleasing visual:

Toy Factory Fixer - Jiggled toy offsets

Well, a relatively pleasing visual. I saw that some toys overlapped other toys visually when they shouldn’t. For instance, in the image above, you can see the small bear-headed doll looks like it is on top of the large doll-headed bear when really it should be drawn behind it.

I realized it was due to the toy sprites drawing centered from their top left instead of the bottom center. It required changing offsets for the toys being rendered, but it made it a lot easier for everything to Z-order correctly.

Toy Factory Fixer - Z-ordering toys correctly

But just drawing a toy slightly off didn’t change anything in terms of the game mechanics. Toys were still allocated 1:1 to a conveyor belt location. Well, it wasn’t strictly true, because it was possible for a worker to place a toy on a belt location that was already occupied, resulting in two toys in the exact same location. With the jiggled offsets, it looks less bad most of the time, but it still occasionally looked like one toy instead of two. Also, most of the game still operated under the assumption that only one toy could occupy a space at time.

For instance, the money you earned from shipping a good toy? You got that bonus based on whether or not there were more good toys shipped since the last check, which meant that shipping two or more toys still gave you the same money bonus as when you shipped one toy.

I wanted the game to recognize that multiple toys can be placed in the same tile, and that required creating the concept of “tracks” on the belt.

I created 9 tracks, and each track is associated with a rendering offset. Think of a 3×3 grid, with (0, 0) in the center, and everything else some combination of either 0.25, 0, or -0.25.

So when a toy gets dispensed, I find out which of the tracks is still open on a particular conveyor belt location, and I assign the toy to that track. This track system prevented the problem of toys being placed in the same exact location.

Instead of preventing workers from putting crafted Good Toys down on occupied belts, they checked if the belt had any unoccupied tracks to place the toys in.

And once everything worked well with one toy, I changed the dispenser so that it could dispense more than a single toy at once.

Here’s a close-up of a belt tile with five toys on it:

Toy Factory Fixer - Crowded Belt

I ended up not getting anything else accomplished this week other than fixing a defect in which the mouse cursor appears under the HUD, something that you wouldn’t see in the mobile app anyway.

So why did I spend all this time on getting multiple toys to occupy the same location?

A big part of the challenge of the game is in managing the flow of Bad Toys coming down the conveyor belt. A single worker can only work on a single toy at a time, so any other toys will continue moving down the line.

With only one toy per belt location, I only had so much room to manage that challenge. I could manage the conveyor belt layout, and allow the player to make strategic decisions about where to place a worker so that the worker can pick up multiple toys as they pass in either direction.

Now with up to 9 toys occupying the same location, other strategies will need to be deployed because one worker or two workers might not be enough to handle it all.

It sounds like a simple strategy: hire as many workers as you can. Done.

And I will need to balance the game play in terms of how the Good Toys earn you revenue and how much workers cost, but I came up with some ideas about how to handle the victory/loss conditions, too. If each worker hired also results in an end-of-shift payment owed, and if spending more money than you earn can result in a loss, it might provide the opposing pressure to avoid that simple strategy above. And if you keep your workers through multiple shifts/levels, then not only do you need to anticipate the end of the shift but also your long-term likelihood of surviving.

I need to figure out how to communicate it to the player so they know to anticipate it rather than get surprised by it, but I think it provides a much more elegant way to end the game instead of merely failing you if you shipped any Bad Toys.

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!

Geek / Technical

Another Reason for Terminal to Freeze/Lock-up

I finally resolved a mystery on my main Ubuntu GNU/Linux system. Apparently randomly, my terminal would appear to lock up. Except I could open a new tab, and that terminal worked just fine.

tl;dr – I was accidentally putting the terminal into Read-Only mode. See further down below for the quick solution.

Now, I’ve got enough experience to know that it is possible to enter Ctrl+S to pause output, which is not fun to discover if you are used to using that shortcut to save files and suddenly find your system acting like it froze. The easy solution is to remember to hit Ctrl+Q to unpause output.

But that’s not what I was experiencing, although the symptom looked similar. I could see the cursor blinking, which indicated to me that the terminal was still active. But Ctrl+Q didn’t unpause, and I know I wasn’t doing anything close to hitting Ctrl+S in the first place.

I’ve tried searching online, but most people talk about the pausing/unpausing thing above.

For a bit, I thought I was having a faulty keyboard issue in that it was sending signals that it shouldn’t. One symptom I found was that it would sometimes open a new tab, and I almost never open tabs for my terminals. I usually just open a new terminal.

I thought the freezing terminal might have been Vim, but the file in question isn’t that large, and I write most of my code in Vim all the time without experiencing this issue, so what gives? It only seemed to happen when I was writing in my daily log, which I use to document what I did the day before, such as tracking how much time I spent on game development or writing.

Well, the other day it seemed to be occurring more frequently than usual, so I tried experimenting.

I found that I could reproduce accidentally opening a new tab whenever I typed the word “minutes” but only when I did so quickly, and often when I typed something before it. I type that word every morning in my log, and I’ve really only seen this issue happen when I was writing in my log.

But I found I could get it to occur without Vim, just having the terminal at the Bash prompt. So it is definitely related to the terminal program itself.

When a new tab would mysteriously appear, I could see that I had typed “min” in the original terminal tab, and “es” was in the new tab, so something was happening when I was typing “ut.”

But in order to open a new tab, the keyboard shortcut is usually Ctrl+Shift+T. But I wasn’t touching Ctr+Shift at all, so that made me think it was definitely the keyboard glitching.

That is, until I saw this menu appear:

Terminal Menu With Shortcuts

Why did that menu appear? Well, apparently as I was typing quickly to try to reproduce the issue, which I had done successfully multiple times, my right palm accidentally hit my keyboard’s menu key, the one key I never purposefully use which is located between the right alt and right ctrl keys.

Menu Key

And if you look closely at the menu, you’ll see that it has a keyboard shortcut for opening a new tab. When this menu is open, you just hit “T” instead of Ctrl+Shift+T.

I realized then that I must be palming the menu key accidentally, then hitting the letter T to open a new tab. And I must be doing it so quickly that I never see the menu pop up.

It Turns Out that Terminal Has a Read-Only Mode

But what else is there? There’s a “Read-Only” mode? And the keyboard shortcut is “O” to toggle it on or off?

Apparently when the terminal appears to freeze, the issue is that I must be accidentally hitting the menu key on my keyboard with my palm, then typing the letter O so quickly that I don’t see the menu appear.

And the solution is to purposefully open that menu and typing O (or clicking the menu entry with my mouse, but come on, that seems wasteful) to toggle Read-Only mode back off. Alternatively, terminal has its own non-shortcut-enabled menu which a Read-Only checkbox to toggle.

Terminal's Main Menu

So there we go. If you didn’t hit Ctrl+S to pause your terminal’s output and need to hit Ctrl+Q to unpause it, you might have also accidentally put your terminal into Read-Only mode and need to toggle it back off. Mystery solved.

I hope this information helps someone out there. I might still investigate getting a new keyboard, but maybe I can adjust my posture instead for now.

Geek / Technical

Free Book – 3D Math Primer for Graphics and Game Development

Fletcher Dunn recently tweeted that the book 3D Math Primer for Graphics and Game Development is now available for free at

Vectors & matrices, representing orientation in 3D, graphics & physics basics, and more. Beginner to intermediate level.

Remastered to be web & mobile friendly!

3D Math Primer for Graphics and Game Development

The 14 chapter book was originally published in 2011, which might feel old enough to be irrelevant in what is supposed to be a fast-paced, technology-driven industry, but as the site says, “… we’re proud to say that most of the material in this book, like Bilbo when he still had The Ring, hasn’t aged a day. Vectors and matrices work the same way, F still equals ma, and people still use Blinn-Phong.”

And while the title says “Game Development” in the name, it’s also a useful reference for non-game uses. I can imagine unlocking some amazing data visualization techniques by leveraging the knowledge in this free resource.

It is currently available on the website and is meant to be web and mobile friendly, but it sounds like there are plans to create a PDF version as well.