Freshly Squeezed Progress Report – UI Enhancements and Training Levels

In last week’s sprint report, I added more effects to make the workers seem more alive, streamlined the player’s start to the game, and updated the grading criteria for the end of the game. I also started work on creating the first level of the game.

My plan for the last week was to continue creating and tweaking the training levels as well as addressing some issues I noticed during recent play tests.

Sprint 35: UI enhancements and training levels

Planned and Completed:

• Prevent worker menu from showing actions that aren’t possible
• Make Options menu clearly separate from game play menus

Unplanned and Completed:

• Defect: Prevent player from commanding worker until after turn is finished processing
• Unpause after leaving a menu that auto-paused

Planned and Incomplete:

• Create floor training levels/tutorial
• Worker menu should allow other workers to get picked

So having other people participate in play testing is invaluable for a game’s development. I might regularly dive deep into an aspect of the game, but even if I come up for air and try to get a sense of the whole of it, I know too much.

I play the game based on my own understanding of it, which is much more comprehensive than someone hasn’t been working on it almost daily for 35 weeks.

All this is to say that it was very eye-opening to see what areas of the game made someone struggle that I wouldn’t have noticed, such as not knowing where to tap on the screen, knowing what to do at any given time, or even getting frustrated when trying to do something only to have the game simulation catch up and take the option away.

I watched my wife play the game for the first time in weeks, so there were a lot of enhancements since her last play test, and this was the first time she played on what is a candidate for a final version of a level that will make it into the game.

One thing she uncovered turned out to hide an insidious bug that I thought I had already addressed.

Preventing workers from doing two things at once

Basically, the game runs in turns. A turn runs in phases, such as moving all of the toys down the conveyor belt, or allowing idle workers to pick up nearby Bad Toys, or letting workers do their jobs, etc.

After a turn starts, it continues through the phases until it is done. So even if you tap on a button or a worker and open up a menu, the turn continues until all phases are done.

What was frustrating my wife was that she sometimes wanted to tap on a worker to open up its crafting menu, but before she could tell it to craft anything, it would pick up a Bad Toy and so would be unavailable to craft anything. Doh!

So I made a note to try to address that problem.

But what I uncovered in my own experimenting with it is that you can, in fact, tell the worker to craft a Good Toy while it is simultaneously grabbing a Bad Toy, which means two toys end up being held by the worker.

Oddly, due to how crafting and separating work, the very next turn would show the worker throwing a Good Toy on the belt, and I have no idea where the Bad Toy went.

So a minor annoyance was actually hiding a major defect.

I ended up making workers show as busy when a turn is progress, but as soon as the turn is over, the crafting menu will appear if it is available. So now it is impossible to get into that state, and despite my worries, it actually doesn’t feel terribly arbitrary.

You tap a worker, open up its menu, and you see “Worker is currently busy” for a moment, and then either the worker stays busy or the crafting menu appears.

It occurred to me only now as I write this sprint report that it is possible for certain phases to allow a pause. The reason why the turn phases finished no matter what was because when I didn’t have them do so, I ran into a similar defect. When you opened the worker menu, the crafting menu would appear, but one of the phases checks to see if a worker is idle and is ready to pick up a Bad Toy. So if you told the worker to craft after that phase, the worker would be seen as eligible when it really wasn’t, and so you would see the worker hold two toys (and sometimes lead to a crash).

But perhaps some phases, such as one before checking worker eligibility for picking up Bad Toys, could allow you to command a worker, so at the start of a turn the worker is idle, but partway through the worker would be busy, and so long as the change happens at safe times within a given turn, it would be fine AND might feel more responsive.

Well, maybe I’ll try that approach if I get more feedback about it or if the current approach starts to bother me enough.

Clearer UI and menus

I also noticed that it isn’t always clear which button to press, so I made a number of changes.

Before, the options menu looked like it was part of the game, which kind of hid the fact that it was basically asking you to quit the game.

The new options menu makes it very clear that it is separate and asking some very big questions:

I also changed the “Back” button and “Options” buttons to be more iconic and gave them a different color, which might help with communicating that they are different. I also made sure that the back button was in the same location on each menu, as before it was inconsistent, which means a player can’t use muscle memory and also means the game feels inelegant and awkward.

The back button was now a big X, which required updating the helper code that creates those standard looking buttons to allow me to pass in an arbitrary font.

And since I did so, I might a well make the bigger buttons use a bigger font.

Also, I added bigger buttons to certain menus to make it clear what the player is encouraged to do next.

Here’s the old level configuration options menu:

And here’s the new menu, with a bigger and clearer call to action:

Even the main menu, which already had a large button, now looks better with a bigger font:

vs

A simple thing like making the font bigger on the bigger buttons really adds to the clarity of the game.

Automatically unpause the game

Another play tester gave me this same feedback across multiple builds, so I decided to experiment with a change that might address it.

The game runs in turns, but to avoid tedium, the player doesn’t have to advance turns manually. There is a Go button that starts the turns, and the turns will advance until the player hits the Stop button. Then the current turn will finish, and the next turn won’t start until the player hits Go again.

I wanted the game to be more about thinking than about dexterity, and so the expected way someone would play is that they might tap a button to open a menu, and when that happens, the continuous turns would stop automatically. Then the player can plan, tell a few workers to craft something, or even hire a worker, and do so on their own time. When they are ready, the player can hit Go.

But my play tester found that it broke the flow of the game. Basically, when he opened a menu, the game seemed to pause, but when he was done with the menu, either by taking an action or hitting back, he expected that the game would start back up again instead of requiring him to hit the Go button each time.

So I thought, “Why not?” and tried to implement a pause/unpause. So instead of a menu resulting in the continuous turns stopping, the turns would be paused, and exiting the menu would unpause. I changed the turn update code to only advance if the turns were advancing AND the game was not paused.

I needed to make sure that turns started advancing again once you unpaused, which introduced a problem.

Let’s say you have three idle workers. If you tap on one, you can tell the worker to craft a Good Toy. But as soon as you do, the next turn advances, and so you might find yourself wasting turns as you quickly try to tell the other workers to craft something.

So I decided to add the Go/Stop button to every menu, which required rearranging some things for some menus.

If the turns weren’t advancing, the Go button would be disabled in those menus, waiting until the player would get to the main in-game menu to hit Go. But if the game was merely paused, the player had the option of also stopping turns from advancing entirely.

Now, I’m worried it is a bit clunky, but I think part of the problem is that there is no visibility into whether you are merely paused or actually stopped. You can see the presence of the Stop button as a clue, but I think it is too subtle.

So I decided to revisit the lever widget I made, which sits on top of the dispenser sprite to indicate if the game has stopped or is playing. I want to make an intermediate state that shows the game paused instead.

Unfortunately, even though I updated the art and have all of the pieces pretty much in place in terms of code, I didn’t finish the implementation it by the end of the week.

So, expect to see it next week.

I got straight As for the first time!

On a side note, while playing the game myself, I’ve been struggling with balancing the first training level in a way that allows a player to actually ace it.

I had updated the grading criteria in the previous sprint, and I updated the level’s configuration to try to make it possible to not only ship all possible toys but also do so within a target number of turns and get a great Return on Investment.

And a few days ago, I got close to a perfect level:

I know I missed those last few toys because it was impossible to get all of them with the workers I had hired and their placement. A player would not be happy to realize that it wasn’t possible, so as a developer, I need to tweak it so it isn’t impossible.

But I did recognize that I wanted to replay the level to try to get all A+ grades, which was a nudge telling me that this aspect of the game is important.

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!