Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – New Training Level and Fixed Defect

In the last sprint report, I reported that I had made strong workers more valuable by giving them the ability to separate two toys at once, which was a more interesting way of balancing them against normal workers than merely modifying some stats.

I continued to work on creating the level that introduces them in this past sprint.

Sprint 41: Training levels

Unplanned and Completed:

  • Defect: Workers seem to hold onto toys long after they should have been separated, eventually letting them go

Planned and Incomplete:

  • Show tooltips during game based on triggers
  • Create floor training levels/tutorial

I spent less time on game development last week than I have since May, and it was one of my top four least productive weeks of the year according to my records.

And since I needed to spend time actually figuring out what tooltips will look like and how they will function, and I needed to figure out how the third worker type will be unique, the lack of time dedicated to it wasn’t great.

That said, I did manage to finish creating the third training level, which introduces the strong worker, and while play testing it, I discovered a serious bug that had a silly cause.

Investigating and resolving a major defect

At one point I noticed that some of the workers would hold on to a Bad Toy they’ve separated. They should immediately toss the parts into your inventory, but they wouldn’t.

I added some debugging text to figure out if it was a weird issue with the health of the bear or the type of worker or something, but eventually I figured out that it was due to the fact that toys now have unique IDs.

Since workers can now work on separating multiple toys, I needed a way to tie the toys they were working on to the worker and vice versa, mainly for rendering the correct things on the screen. Toys already knew which worker was holding them, but workers now knew which toys they were holding onto by their unique IDs.

Which is fine when those IDs are, in fact, unique, but weird things happen when two toys are on the screen with the same ID.

Which happens when I configure a level’s production runs by reusing toys that I add to the dispenser.

So basically on the third level, around production run 8, there are a set of toys that are dispensed and I wanted the same type of toys to get dispensed shortly afterwards, and basically I accidentally put toys with the same ID on the screen at the same time.

So a worker would work on, for example, a toy with ID 85, but another toy with ID 85 would be on the conveyor belt elsewhere. The worker would finish separating toy #85, but when the code looked to see which toys were finished being separated, somehow it would find the non-separated and pristine toy #85, and so the worker wouldn’t let go of the toy.

So the easy fix was to just configure the level with unique toys, but the risk is still there if I forget and do the otherwise easy-to-make mistake of re-adding toys that were already created.

Eventually I was happy with how well the third training level worked, and I started working on the fourth training level, which introduces the third worker, the sewing specialist.

Making the third worker also unique

One thing I liked about giving the strong worker the ability to work on multiple toys at once was that it made the strong worker more than a mere change in stats from the normal worker. They are truly two different types of workers.

Originally the strong worker was very strong at separating and very weak at crafting, and the sewing specialist was very strong at crafting and very weak at separating.

The obvious thing to do with the third worker was to allow them to craft two toys at once, to mirror the strong worker’s ability to separate two toys at once. It was a bit more challenging a task since I would need to change the crafting menu somehow to make it easy for the player to communicate that they want two toys to be crafted, and I would need to figure out what UI challenges to overcome there.

But the more I thought about it, the more I wanted to make this worker type similarly unique and not a mere mirror of another worker type. It just wasn’t compelling enough to me to have a worker that can merely craft two toys at once.

Toy Factory Fixer - notes for designing the third worker

I thought about how crafting serves a very different purpose from separating, and how important it gets towards the end of a level when you are no longer getting more parts in your inventory but are instead trying to get as many toys put together as possible.

Maybe the sewing specialist can take two compatible Bad Toys and instantaneously turn them into Good Toys? I liked this idea, but the problem was that the toys coming down the conveyor belt wouldn’t always be compatible. So should this worker pick up two incompatible Bad Toys and try to separate them? Or should they only pick up one Bad Toy at a time unless they can pick up two compatible toys? There was a lot of complexity here.

Then I reflected on how tedious it can be to tap on a worker, tap on a button to tell that worker to craft, and repeat.

I thought about having the worker instantly craft an arbitrary number of Good Toys at once, based on parts in inventory and the worker’s capacity (2, 3, or even 10?), with a potentially long cooldown period in which that worker couldn’t do anything. I still like this idea, but then I thought of another.

What if the sewing specialist’s unique ability is to be told to craft a certain toy type once, and they will continue to craft until the parts inventory is empty for that type, and will continue once those parts are available again?

It kind of reminds me of games like Cookie Clicker, in which you manually do some tasks, but eventually you can earn enough to purchase things that automate those tasks for you. Maybe there is value in giving an option to avoid the otherwise tedious activity? Which makes the tedious activity less of a design defect and more of a purposeful part of the game?

So what’s the downside to having this worker automatically crafting toys? Maybe you would prefer to choose a different worker in a different location to craft a particular toy, but you can’t stop this worker from doing so first, which might mess with your strategy if you were trying to finish a level in the fewest turns.

More obviously this worker can’t pick up and separate Bad Toys when crafting, but should this worker not have the ability to do it at all? Is there no such thing as this worker being idle, or can the worker be idle if there are no parts to craft and so is available to collect Bad Toys on the conveyor belt?

And if the worker is assigned to crafting a single type of toy, what if you want to switch them to a different type? Should there be a cost to reassigning the task? Is the cost money, or a worker who can’t do anything for a few turns?

Some of the work I have ahead of me is figuring out how to communicate to the player which kind of toy this worker is trying to craft when they are otherwise looking like they are idle.

But the role of this third worker clearly needs more time to marinate.

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!

One reply on “Freshly Squeezed Progress Report – New Training Level and Fixed Defect”

Comments are closed.