Category: Geek / Technical

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!

—

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!

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!

—

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!

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!

—

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!

Last week’s sprint report talked about getting workers into the game, as well as my focus on getting something playable as quickly as I can.

Sprint 8: main game loop

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

Last week I managed to get the workers to pull a Bad Toy off of the conveyor belt, then spend a few turns working on separating the pieces.

I tried to focus on fast implementation, but I also thought it would be good to make it obvious what state everything was. I found rotating the toy to be on its side when being worked upon and showing the worker’s progress in the form of stitches were quick ways to make it clear what was happening.

I also implemented an inventory of toy parts. There are currently two types of toys, dolls and bears, and each has a head and a body. I’m not a user experience expert, but I thought it would be helpful to group the inventory parts so it is clear when you have at least of each part to create a particular toy.

I did not get to the point of actually telling workers to craft Good Toys out of parts, so there are still no Good Toys in the game or a way to win.

I think some of the work went more smoothly this week. I had vague ideas of how the toy separating and putting together would operate, but I finally managed to get the details hashed out mentally.

But it also means that there was a lot more to do than I originally anticipated. It seems straightforward to separate toy parts across turns, but there are multiple steps to implement. Just collecting the toy off of the belt means first finding idle workers, figuring out if there is a toy adjacent to them, then kicking off animations to make it clear that the worker is picking up the toy.

And then of course testing it. What happens if there are two workers next to each other? I had a humorous bug in which a worker would steal the toy from an adjacent worker because I did not mark the toy as being worked upon.

But I’m finally playtesting a bit. Even though the core of the game is still incomplete, I found myself experimenting with changing the order of operations for a single turn. Does the worker collect a Bad Toy off the conveyor belt first, or do the toys move first? Should a worker be able to pick up a toy immediately after separating a toy, or should they wait until the next turn?

Putting together a Good Toy is next up, and I think I can really get into playtesting. I am pretty excited.

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!

In last week’s sprint report for my new game project Toy Factory Fixer, I talked about moving toys down the conveyor belt and spending potentially too long creating new art for the worker in the toy factory. I also worried about the lack of progress towards getting something playable, and I wanted to renew my efforts on prioritizing work that allows me to play test the game rather than merely look at it.

Sprint 7: main game loop

• Create a way to hire and place a worker
• Create player inventory of toy parts
• Allow player to command worker to put toy parts together
• Process a single turn sequence
• End game when Bad Toy enters shipping container
• End game when last Good Toy enters shipping container

I knew I probably added too many things to this sprint when I started, but I still left them all in the plan.

It took me a couple of days to get the worker hiring menu in. It ostensibly should have been easy, but I ran into a strange Z-Ordering issue, plus a problem with the menu code that was surprisingly frustrating. Otherwise, the work was straightforward but required some thought as it was a multiple-part problem that wasn’t obvious until I started working on it, such as needing to identify what was adjacent to the conveyor belt and what was still available once you place other workers down.

Now you can select the worker to hire, place the worker next to the conveyor belt, and confirm the placement of the worker there.

The little orange buttons are meant to be available locations to place a worker, but I think there should be a more subtle way to indicate those locations if I keep the mechanic in the future.

I managed to create a game ending when a Bad Toy enters the shipping container. It’s a simple screen that merely says “GAME OVER” for with a button to restart and a button go back to the main menu. I have ideas for improving it thematically, but I just needed a way for the game to end. It was quick and easy.

I did not add a similar ending when the last Good Toy enters the shipping container because there are no Good Toys in the game yet.

And there are no Good Toys in the game because workers don’t currently create toy parts by separating Bad Toys, so there is no need for a toy part inventory.

I ended the week by figuring out what the turn sequence should look like. Right now, toys are dispensed from the dispenser, toys are moved down the conveyor belts, and now there is a check to see if a Bad Toy made it into the end of the line.

Next, I want to add the following:

• Find all unoccupied workers.
• For each unoccupied worker, find an adjacent Bad Toy as pick-up-able by this worker.
• For each tagged Bad Toy, have associated worker pick it up.

A worker who is holding a toy is “occupied” with the work of separating its parts, which also has a turn sequence.

And this is why I want to get the game play implemented as quickly as possible: I want to see whether or not this will feel as clunky as it sounds like it might turn out to be, and I want to change direction sooner if that is the case.

I am very aware that I am barely getting to the game play while I reach the end of yet another month. I’ve spent about 55 hours since the beginning of December, and while part of the work last month was spent figuring out a design and doing paper prototypes and doing some hopefully one-time setup for future Freshly Squeezed games, that’s a lot of time to go without a game to show for it. My Ludum Dare entries have been put together in less time.

There is very much a difference between 5 hours spread across an entire week and 5 contiguous hours. Besides focusing on the right work, I need to figure out how to be faster about the work I do choose to focus on.

The game ending screen above, for instance, was fast because I didn’t spend much time trying to make it look great, whereas the effort to create the worker sprite in the previous sprint was probably overkill for what basically amounts to a placeholder, even if I am proud of what I created.

But I feel like I am finally going to have something playable soon. I just hope it won’t be another month before anything interesting happens in the game.

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!

What I reported in last week’s report was that I had made little progress towards implementing anything resembling game play, and I planned to do so in the next week.

Sprint 6: main game loop

• Create shipping container
• Create broken/bad toy
• Create hire button
• Create worker

In the spirit of moving faster, I added a shipping container by merely reusing the toy dispenser art.

I added a toy doll, and then I made the dispenser create broken, “bad” toys in which the head of one is on the body of the other.

And I added a hire button, which opens up a new menu that doesn’t currently let you do anything but go back to the main in-game menu.

Then, in forgetting about the need for expediency, I spent quite a bit of time creating a worker. Or rather, the concept art for a worker.

I started by researching cartoony elves, as I want the factory workers to be somewhat magical, then I created bunch of sketches. Finally, I created a base sketch of one digitally, then experimented with its looks.

It’s amazing how different the same drawing can look when you apply different hues and patterns.

While it was enjoyable to spend time on it, and I think the art will look a bit better for it, the worker still isn’t implemented in the game, which means I still haven’t created anything to play test yet. I can’t experiment with whether or not the game play I designed will actually work well or fall on its face.

For various reasons, I’ve spent less than 5 hours a week on this project, and it’s not getting done any faster. I spent time thinking about what I need to do to get things finished faster, and the most impactful change I can make to my development process is to make things quick and ugly.

I mean, I’m not an artist by trade, and I’m sure the art you see is already ugly, but my point is that I am spending a lot of time to make art slightly less ugly rather than focusing on getting to game play and making it less broken or uninteresting.

It’s not that I think art doesn’t matter, but right now, I have a lot of unanswered questions about how the game should even work. What does it cost to hire a worker? How much currency should the player start with? How does worker placement work in terms of player user experience? Is the play area too large or too small? Should a worker automatically do work when an opportunity presents itself, or should the player control when they start working? How do I indicate that a worker is working versus waiting to work? There are many more, and more will come up as the work continues.

And I need to focus on answering those questions, because the question of “Is this game ugly?” is already answered, and my goal isn’t to make a pretty game but an entertaining one.

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!

In last week’s report, I mentioned how I accomplished very little due to transitioning into the new year, and I expected to get the work done in the next week.

Sprint 5: main game loop

• Create toy
• Create toy dispenser
• Create shipping container

I did not get all of the work done last week. I have a toy, and a created a toy dispenser that spits out toys onto the conveyor belts, which carry the toys along the line each time you press the Advance button. If the toy isn’t on a belt, it doesn’t move.

The dispenser takes a queue of toys that are initialized at the beginning of the game. Right now, the logic is to dispense a toy if there is one in the queue, but I think in the future I can see changing it to allow me to dispense a toy at a specific timing. Perhaps I can even have it dispense more than one toy at once.

The Advance button kicks off a new turn, which currently starts the following sequence:

• If a toy dispenser has a toy in the queue, dispense the toy.
• Move any toys along the conveyor belts.

And…that’s it.

I did not create the shipping container for it to fall into yet.

On the one hand, I know I only allow myself to dedicate the equivalent of at most half a day’s work across an entire week, so getting things done slow and steady is the norm for me as a very, very part-time indie game developer.

On the other hand, it feels like I should have something more playable by now, yet another week has gone by in which I don’t. By my count, I’ve already put in over 40 hours into the project, which means if it was a 48-hour game development competition on a weekend, I would not have a game ready to submit by the deadline.

Looking at this past week, I know I spent some time making the toy move along the belt smoothly and redrawing the dispenser when I realized how awful it originally looked, but it wasn’t the lion’s share of the work. I probably could have saved some time not worrying about the dispenser’s looks, opting to focus on getting an ugly shipping container into the game instead, but I still wouldn’t have anything more interesting for the player to do by now.

My goal for this coming sprint is to not only add the shipping container but to add the ability to hire a worker and place one on the factory floor next to a conveyor belt. Once the worker is there, the next step will be to get the worker to pick up a Bad Toy from the belt, then get the worker to separate the toy parts.

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!

I took a short break from development because I wanted to spend time assessing the past year and figuring out my plans for 2021. I didn’t report on my progress since my last report when I talked about the lessons learned in terms of prioritizing what gets done, so I’ll bring you up to date with what I’ve done since then.

Sprints 3 and 4: main game loop

• Create mockup for game play screen
• Create in-game menus
• Create toy
• Create toy dispenser
• Create shipping container

I changed the conveyor belts I created last time so that they were easier to see at a glance which direction a toy would go when on them. They animate now, which looks nice enough, but since the game will be turn-based, they need to be readable when static.

To help me get a sense for how to implement the next things in a game, I find useful to create a mock-up.

I used my conveyor belts, my new toy stuffed bear, and my existing buttons, but then I quickly created a toy factory worker and some buttons on the side for advancing one turn and for hiring workers.

It’s not a finished mock-up, and the finished game might look a bit different, but it does give me a sense of where things are going.

My main goal for the last week was to get a toy dispensed, get it to travel along the conveyor belts, and deposit into a shipping container. Of course, as I said above, I did very little game development.

I managed to get the toy bear in the game, but I don’t have the logic to move it down the conveyor belts yet.

I did draw a toy dispenser on paper that I really liked:

But I didn’t draw a shipping container, which I imagine will just be a box with flaps.

Considering I only put 2 hours of game development in last week, partly due to being distracted by a fascist insurrection at the Capitol Building, it’s understandable that I didn’t get everything I wanted done.

I expect that in the coming week I will get all of the above done, add another toy type, and can move on to the mechanics of hiring toy factory workers soon.

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!

Last week, my weekly sprint report detailed how much time I spent trying to create art myself that ended up looking pretty mediocre, with a promise that I wouldn’t spend so much time doing so going forward.

Sprint 2: Basic navigation for all Freshly Squeezed games

• Start new game
• Options lets player see credits
• Create menu screen background art
• Create options menu screen background art

While I had time off from the day job, I also found myself preparing for the holidays. I managed to make time to work on game development between wrapping presents, eating cookies, and preparing a meal for Christmas Eve, but my priorities were definitely not on putting together a Freshly Squeezed game.

What I did accomplish was finishing up the simple art and buttons for the main menu screens. I unfortunately did not do anything to get a playable game implemented yet.

I created the basic menu structure that all Freshly Squeezed games will use going forward. I hate second-guessing myself, though. Did I spend too much time making a menu for a game instead of a game?

It’s not as if I spent too much time making a generic menu system. I already had a menu system I coded a long time ago. And it isn’t as if I was perfecting details that didn’t need to be done.

But perhaps I could have worried about that menu once I had a game I could release, or even after release. The second Freshly Squeezed game won’t be made until this one is released, so in terms of prioritizing the work, I probably could have worried about the menu later.

But last sprint is done, and I can focus on game play in the next one.

I have already started working on creating simple conveyor belts, reminding myself that they don’t need to look beautiful so that I don’t spend too much time on them. I tried to finding conveyor belt art on sites such as OpenGameArt.org, but the few I found were very tiny or the wrong perspective.

So I made this, with four frames of animation so it is clear which direction it is going. This will actually make up two different sprites: the left and right sides of a conveyor belt, with a middle section being a third piece I still need to create.

Perhaps I could put an arrow on it to make it clearer since it is meant to be seen as a still frame most of the time due it the game being turn-based.

I don’t know how much time I will have to work on this project this week. My wife has already indicated that she wants some house projects to get done during the break. But I hope that by the next report I finally can show off some simple game play.

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!