Category: Geek / Technical

Freshly Squeezed Progress Report – Almost Done?

Post author By Gianfranco Berardi
Post date 3/29/2021
1 Comment on 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

Completed:

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.

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

Post author By Gianfranco Berardi
Post date 3/22/2021
1 Comment on 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

Completed:

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:

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.

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:

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!

—

Geek / Technical

Another Reason for Terminal to Freeze/Lock-up

Post author By Gianfranco Berardi
Post date 3/19/2021

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:

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.

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.

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

Post author By Gianfranco Berardi
Post date 3/16/2021
1 Comment on 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 https://gamemath.com/.

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

Remastered to be web & mobile friendly!

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.

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Production Run UI and Shipment Deadlines

Post author By Gianfranco Berardi
Post date 3/15/2021
1 Comment on Freshly Squeezed Progress Report – Production Run UI and Shipment Deadlines

I added money, a way to spend money to hire workers, and a way to schedule multiple waves of toys to get dispensed in last week’s sprint report, which helped Toy Factory Fixer feel more like a game. I continued that trend last week.

Sprint 13: create an economy

Completed:

Create dispenser queue
Create a shipping deadline
Defect: Fix crash when rendering toys

Not completed:

Allow multiple toys to occupy same belt space

The dispenser already had scheduled productions runs, but the player didn’t know when they were coming or what to expect. In the last sprint I added a simple indicator that counts down the number of turns left until the next run starts, as well as informing you how many toys there will be.

Toy Factory Fixer - Dispenser Queue UI

I might need to experiment with the UI. The frame and the text takes up quite a bit of the screen, covering up the nearby conveyor belts. Perhaps I can provide a smaller frame that only indicates the number of turns, and if the player taps on it, then it opens up into a more detailed view.

I also added a shipping deadline. That is, in a given level, you have until a specific turn to ship all of the toys you need to ship. If the shipment is late, you lose.

Toy Factory Fixer - Shipping Deadline UI

The idea is to discourage the player from waiting until after the Bad Toys are all separated to direct the workers to craft Good Toys.

Right now, it is possible to play the game with a deadline or without one. It occurred to me that I could also track the number of turns it took you to ship all of the toys and then assign the player a grade based on how well they did. So instead of merely winning or losing, the player can win or win better or win awesomely depending on how much effort they want to put into it. So that’s an idea to go into the backlog.

The game periodically crashed on me, and it turned out it was due to how I was moving toys. You can tell a worker to craft a Good Toy, which means that a new toy is added to the game’s collection of toys. It is possible to do so while a turn is still resolving, which I need to address because it causes other side-effects that I don’t like, but this crash was annoyingly disruptive so I wanted to address it immediately.

I changed how toy movement is handled so that it doesn’t depend on some state that is only set at the beginning of the turn. Not only did it fix the crash, but it also meant the code was simpler.

What I didn’t get to was ensuring toys can occupy the same space on a conveyor belt. Technically, they already can. The problem is that they occupy the exact same location, so the player can only see one of the toys at a time. I wanted to make it easier for the player to see multiple toys on the same belt, and once I do that, I want to have the dispenser place multiple toys on the belt at once.

To start, I decided to shrink the size of the toys. Initially I thought that all toys should just be 75% of their original size, but then I realized that I could have the original size as well as small toys.

Well, of course the effort went from merely making a one line change in order to render the toys at a smaller scale to modifying the inventory and dispenser and UI to handle two sizes of toy parts.

I think the smaller toys are adorable.

I still need to change the crafting menu to allow the player to create small versions of Good Toys, but I also want to change the number of stitches large and small toys have as well as changing the reward for small toys versus large toys.

It’s a bit of a detour from the original plan of allowing multiple toys to occupy the same location, but I think it helps give some needed depth to the game.

And maybe multiple smaller toys can occupy the same conveyor belt tile, but larger toys can’t. But then I need to figure out what to do if a worker tries to place a crafted toy on a belt that is already occupied. They normally try to find the first one that isn’t, but if all of the nearby spots are already filled, what should happen?

Maybe they hold onto the toy until a space opens up, which wastes precious time? Perhaps they bump off a toy onto the floor, which requires the player to tap on it to make a worker pick it up?

I don’t know, and maybe it isn’t that important to figure out yet. I have more pressing game play questions to answer.

Thanks for reading!

—

Game Development Geek / Technical

Why I Am Glad I Test-Drive My Code

Post author By Gianfranco Berardi
Post date 3/10/2021

The other day I was changing how the toy dispensers work in Toy Factory Fixer.

Instead of merely spitting out a steady stream of toys, I decided to create multiple waves of toys, separated by a number of turns.

I call these waves “Production Runs”, and I wanted to be able to set delays between them. So if a production run is scheduled to start in 5 turns, I want no toys to dispense for those 5 turns.

When a new turn starts, I need to take the next production run and decrement the number of turns left to start it.

Here’s the code:

void Dispenser::processNewTurn()
{   
    if (m_toys.size() == 0)
    {   
        if (m_runs.size() > m_currentRun)
        {
            m_runs.at(m_currentRun + 1).turnToStart--;
            if (m_runs.at(m_currentRun + 1).turnToStart <= 0)
            {   
                startRun();
            }
        }
    }
}

If I am currently dispensing toys, I don’t want to process anything, but otherwise, if there is a next run, I take the turnToStart value and decrease it by 1. When the count reaches 0, I can start that new run.

If I don’t have a next run, meaning that the current run is the last one, then one of my unit tests would crash, which is why I added the line that says:

if (m_runs.size() > m_currentRun)

But then a few other tests started to fail. I checked, and the block of code within the second if-statement never ran.

I printed out some logs, and sure enough, the size of m_runs was indeed greater than m_currentRun, which starts off at a value of -1, so of course it is smaller than a collection of 1 production run.

So what gives?

I had a vague recollection that there is a possible type conversion happening here.

I realized that the reason why the code wasn’t running in the second if block was because there was a difference between the type of integer returned by m_runs.size() and the type I am using for m_currentRun.

See, m_runs is a vector, and standard C++ collections have a function size() that returns a type size_t.

size_t is an unsigned integer.

m_currentRun is a signed integer.

Normally it is not a problem to mix and match integer types. Or maybe more accurately, it depends. I can create a for loop with a signed integer as an index and compare it to the size of the collection:

for(int i = 0; i < m_runs.size(); ++i)

And I expect that code should work.

But when comparing unsigned integers with signed integers using a binary operator such as > or <, C++ looks for a common type and automatically converts one value to it.

And in this case, the signed integer becomes an unsigned integer. In fact, it happens in the previous for loop case as well, but nothing goes wrong because i is always greater than or equal to 0, so whether it is signed or not, the value being compared doesn’t change.

In my processNewTurn() code above, however, m_currentRun is -1 to start, but it gets converted into an unsigned integer.

And -1 can’t be represented as an unsigned integer, so instead it now represents the largest possible integer.

Which means the expected logic is that m_runs.size() will always be less than that largest possible integer.

So a quick fix is to force the unsigned integer to be a signed integer instead:

if (m_runs.size() > m_currentRun)

becomes

if (static_cast<int>(m_runs.size()) > m_currentRun)

And now the code runs as I expected, with the comparison working as I expected.

And I am really glad that I not only did I have the experience to give me a vague recollection of running into this kind of issue before, but that I had tests that immediately told me that there was something wrong with my logic.

I found the issue and fixed it within minutes rather than continuing to write code ignorant of the problem and then wondering why the dispenser wasn’t working right potentially hours or even days later.

I know that a lot of game developers look at practices such as TDD as something that slows them down or that doesn’t work in games, but I don’t understand this point of view.

That fast feedback I described is key to being able to develop faster. I spend less time finding and fixing issues manually, and I am able to address issues while I am still thinking about them rather than needing to remember how the code worked at a later time.

It took me longer to write this blog post than it did to write the code, find the problem, and fix it, all because I found the bug immediately after I wrote it thanks to my unit tests that I just wrote revealing its existence.

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Money and Production Runs

Post author By Gianfranco Berardi
Post date 3/8/2021
1 Comment on Freshly Squeezed Progress Report – Money and Production Runs

In last week’s sprint report, I started adding an economy to Toy Factory Fixer. Toys can only be crafted if you have the required toy parts, and the game tracks how many Good Toys and Bad Toys you ship. Next up was adding money to the game.

Sprint 12: create an economy

Completed:

Create cost to hire worker
Create reward for shipping Good Toy

Not completed:

Create dispenser queue

I didn’t spend as much time on game development this last week as I would have liked. I did less than 5 hours, which is below my average for a week.

That said, I was able to add money to the game. Now workers cost money, so you can’t hire an infinite amount, and shipping Good Toys also gives you money.

Toy Factory Fixer - Game Play

The starting amount of money, the cost of hiring workers, and the money you can earn each time a toy ships are all numbers I need to play around with to see if I have something that can be challenging and enjoyable rather than either impossible or inevitable.

While I didn’t get the dispenser completely done, I did manage to change the way toy dispensers work. I just didn’t get around to adding the UI elements that would let the player know what they are doing.

Originally, dispensers would be provided with a bunch of toys, and each turn a new toy would get dispensed onto the conveyor belt.

Now, dispensers have multiple production runs. Each production run has a collection of toys and a turn countdown. So a dispenser will wait the specified number of turns before starting to put toys on the belt, then once all the toys for that run are dispensed, it will start counting down the turns until the next run starts.

I think this change will help to control the flow of toys so that it won’t overwhelm the player.

Coming up next

The next time I change the dispenser, I want to add ways to make it more overwhelming, such as being able to put multiple toys on the same conveyor belt space. So I can slow down the flow or I can increase it, requiring the player to figure out a better way to address it through their hiring strategy.

One of the issues threatening the enjoyment of the game is that the player could just sit back and wait for workers to get all of the toy parts possible, then start crafting only at the end. I think it sounds like it would be a bit boring, so I think adding a shipping deadline would help. You would then need to craft Good Toys while also separating Bad Toys because otherwise you will not ship all of the Good Toys by the turn deadline. And since workers can’t craft and separate toys at the same time, there will need to be decisions about when to do one or the other.

And of course, I’d like to make sure the UI is intuitive and is readable.

Thanks for reading!

—

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – UI, Tracking, and Designing

Post author By Gianfranco Berardi
Post date 3/1/2021
1 Comment on Freshly Squeezed Progress Report – UI, Tracking, and Designing

In last week’s report I not only finished all of the tasks for the sprint but also got a complete game loop that I could playtest.

So for the last week, I’ve been building upon that foundation.

Sprint 11: create an economy

Completed:

Only allow crafting when parts available
Show toys shipped indicator
Create game over screen

Not completed:

Create cost to hire worker

The core loop of hiring workers who can separate Bad Toys into parts automatically and of commanding workers to put together Good Toys from those parts is done, but there was nothing that actually connected the concept of a parts inventory to the crafting of toys.

So I made sure that toys can only be crafted when parts are available. If they aren’t available, the buttons are darkened.

Here’s the original “just get something working” worker menu:

And here’s the updated one. I added formulas, and I moved the inventory closer so that you could compare what you need to what you have more easily:

Similarly, I wanted to add something to indicate to the player how much progress has been made in terms of shipping toys:

It’s funny how a small UI element like this one can result in a bit of work under the hood to support.

Lastly, I updated the game over screen so that it showed some statistics about toys you shipped. The game used to end immediately upon shipping a Bad Toy, but now I want to allow the game to end when all toys are shipped. Currently, the “YOU WIN” or “YOU LOSE” text appears based on whether any Bad Toys have shipped, but I think if I am going to allow you to ship all toys then there should be some other win/loss criteria.

I’m thinking that you can earn money for each Good Toy shipped, so you can lose but have more money for your next try. Maybe.

Speaking of money, the one thing I didn’t get to was adding the concept of money to the game and requiring it to hire workers.

I need to remember that there is a difference between implementing something that functions and tweaking to get the balance right. I probably could have gotten the last task done if I wasn’t also worried about how to make it enjoyable right off the bat.

In this case, I could have added currency to the game, then made it cost some of your money to hire a worker. Only then should I worry about how much money to start the player out with and how much it should cost to hire a worker. And in fact, I might not even need to start worrying about it until I have more of the components of the economy implemented.

Besides worrying about balance prematurely, I was addressing some quirks I was discovering as I played the game. Due to the way the turns get resolved simultaneously, I found it was possible for two workers to place a toy on the same section of conveyor belt. Since the current implementation expects only one toy on a belt tile at a time, this is a bug that needs to be addressed.

But I am also spending time thinking about the various ways I could explore the game design space. and one of them was making it possible to have more than one toy on a belt tile. My thinking is that the dispenser can spit out more than one toy at a time in order to allow flexibility in the flow of toys to make the player deal with, but it would mean that the above bug wouldn’t be a bug anymore.

Which goes back to not wanting to prematurely balance the game before I’ve got more things implemented.

Thanks for reading!

—

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Finally, a Main Game Loop!

Post author By Gianfranco Berardi
Post date 2/22/2021
1 Comment on Freshly Squeezed Progress Report – Finally, a Main Game Loop!

For sprint 9’s report, I created a crafting menu for workers to create Good Toys from the parts of Bad Toys that were separated.

Sprint 10: main game loop

Process a single turn sequence
Allow player to command worker to put toy parts together
End game when last Good Toy enters shipping container
STRETCH: Create active pause

This past week, I actually managed to accomplish all of the tasks I wanted to!

Workers can be commanded to craft a Good Toy. Each worker now has a Crafting stat that indicates how many “stitches” they can work on per turn.

When a worker is done stitching together a new Good Toy, they will put the toy on the conveyor belt. Now, ideally they would find the “best” location to put the toys down on, but in the interest of speed, I basically used the heuristic of finding a free space on the conveyor belts that are lowest and to the right. It works well enough, but I can see revisiting it in the future to ensure that the chosen spot is the one that is the latest in the belt line.

Finally, the game ends when the last Good Toy enters the chute for the shipping container. I needed to essentially figure out how many toys total are in the game, and it is basically a function of how many toys are dispensed.

I also spent some time speeding up the movement of the conveyor belts, and I added what I refer to as “active” pause.

Basically, instead of pressing the Advance button to move the game ahead one turn, and then requiring the player to do so repeatedly, the player can now press the Go button, which turns into a Stop button. So now turns will continue until the player stops them by either hitting the Stop button or selecting a worker. In truth, any of the actions available while the Stop button is active will stop turns from advancing once the current turn finishes.

So what’s exciting is that I now (finally!) have the core of a game that I can playtest. There are things that aren’t implemented yet that I plan to get to in the coming week or two, such as adding a cost to hiring workers which requires a currency. In fact, crafting Good Toys should take away from your inventory of parts but doesn’t at the moment.

It might seem like the game is broken, but it just means I need to self-enforce any new rules I come up with before I implement them, similar to what you would do with a paper prototype.

And of course, the game’s graphics need work. At the very least I need some indicators to let the player know they can select a worker, but I also want to make it clearer when a worker is idle, when a worker is done crafting a toy, when a toy ships, and things like that.

Thanks for reading!

—

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Inventory and Worker Menu

Post author By Gianfranco Berardi
Post date 2/16/2021

In the previous week’s sprint report, I got workers to pull apart Bad Toys that they pulled off the conveyor belts.

Sprint 9: main game loop

Process a single turn sequence
Allow player to command worker to put toy parts together
End game when last Good Toy enters shipping container

I managed to make it clear that separated toy parts get added to the player’s inventory instead of just disappearing. I’m not completely happy with how the toy parts merely fall to the bottom of the screen in a straight line, but it’s functional.

I started the process of making it possible for the player to direct a worker to put together toy parts. My initial attempt was fairly minimal, but then I went back to my notebook and sketched out a few attempts at some modal dialogs. My current approach gives the player the information needed to make a decision, and it is a lot clearer for me to implement.

It’s basically a crafting menu, showing you which Good Toys you could create based on what inventory you have.

I managed to do a lot more game development than usual in the earliest part of the week, but then long meetings at the day job on multiple days prevented me from getting much done in the latter part of the week, so I need to finish the implementation this coming week.

I also sketched out a rough idea of a new game, but I don’t plan to work on it until Toy Factory Fixer is released. Still, feel free to sign up for my newsletter below if you want to get a sneak peak at it when I do finally share it.

Thanks for reading!

—