Freshly Squeezed Progress Report – Worker Polish and Training Levels

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!