Marketing/Business Personal Development Politics/Government

A Review of My 2021, and Looking at 2022, Already In Progress

2021 ended weeks ago, and I’m only now getting around to having a retrospective about it.

We’re in our third year of a pandemic that a lot of us thought would be over within weeks or months at most.

Once again, my immediate family somehow managed to make it through the year unscathed as far as we know. I know a number of people who have tested positive for Covid, and we’ve lost a few people we knew.

I’m still employed and working the day job from home, and since I work in software consulting, it translates into a relatively comfortable income and life for my family.

We’re all fully vaccinated, and most of us have gotten a third vaccine. Recently with developments of variants, we’ve upgraded to KN95 and N95 masks.

And since our society in general seems interested in actually helping the pandemic, it seems like this is our foreseeable future.

That said, we’ve started venturing out of the house a bit more in the last year. My children participated in sports, and I even acted as unofficial assistant soccer coach for my daughter’s team. We’ve visited with family.

Some things felt normal, despite feeling weird, and despite knowing that some people are immunocompromised and most at risk as society prematurely decides the pandemic is over. It’s disappointing.

So with the pandemic as background music, how was 2021 for GBGames?

Goals from 2021

As I wrote last year in 2020 in Review and My 2021 Vision, my goals for 2021 were:

  • Go from ~0.146 sales per week to at least 1 sale per week by December 31st
  • Increase my newsletter audience to at least 100 subscribers by December 31st
  • Release at least 6 Freshly Squeezed Entertainment games by December 31st

Increasing sales and increasing my newsletter audience aren’t things I have direct control over. They are lagging metrics, the kinds of numbers I can look at after the fact.

The only one of those goals I had direct control over was publishing games. This is a leading metric. That is, my hypothesis is that if I quickly work on and publish playable, polished prototypes, that it will lead to people finding my games and eventually subscribing to my newsletter.

And what I hypothesize is that those subscribers have shown they like my games and are more likely than random strangers to pay for Toytles: Leaf Raking and future non-free games I publish.

So how did I do?

Sales (Target: 52) – 5

In 2020, I sold 7 copies of Toytles: Leaf Raking. So, selling less means I went backwards in terms of results.

If there’s a bright side, unlike in 2020, I only released one update for the game, and most of my focus was on my new development. So 71% of the previous year’s sales despite a near-complete lack of me talking about the game?

Maybe that’s not bad, but it was clearly not anywhere near the increase I wanted.

GBGames Curiosities Newsletter subscribers net increase (Target: 84) – 6

I went from 16 subscribers to 22, about a 38% increase. Considering how the next goal’s results went, I’m taking it as a minor win, despite not hitting my goal of what now seems like a ridiculous expectation of a 525% increase.

And, no one has unsubscribed, so that’s another win in my book.

As this was probably the most important goal in terms of how much it will impact the future of GBGames, it is a bit disappointing, but again, it is a lagging metric. I can’t control it directly. Which leads me to what I could control.

Published Freshly Squeezed Games (Target: 6) – 1

Toy Factory Fixer was the only game I published last year, and it didn’t get released until mid-December.

So on the one hand, I am disappointed that I fell so far short of my original goal. Having such a late release meant that I spent most of the year not knowing how my Product Development Strategy was going to work out experimentally, which made me worry about the risk of taking so long to release something to get that feedback even more.

On the other hand, I finished and released a game I’m proud of, people are still downloading it and playing it, and I have already received some nice reviews.

And I think my regular posting about development progress has led to people signing up for the newsletter, so there is a direct connection happening there.


Now, I think much like my arbitrary one month deadline for Toy Factory Fixer, these goals were more wishes than anything. I had no solid plan in place to make them happen, and any plan I did have was a bit vague and untested.

Literally, my plan was to release free games, hope some of the players signed up for my newsletter, and hope those subscribers eventually became paying customers.

And I think it isn’t a bad strategy overall, but in retrospect I was deluding myself with the fixed numbers I made up without anything to justify them.

I mean, I’ve made games in a weekend before, so taking two months instead of one month to make a game sounded like I was right-sizing that goal, but my experience with Toy Factory Fixer showed me that I was going to need to do something different if I wanted to make games anywhere near that fast that I would still feel good about releasing to the public. And everything else hinged one me releasing Freshly Squeezed Entertainment.

I wrote a post-mortem for Toy Factory Fixer, so you can read that post if you want to see my analysis of what I think went well and what went wrong and what I learned from it.

Otherwise, I think in general my specific goals were unrealistic. Which is frustrating because they feel like they shouldn’t be. In fact, I thought 100 subscribers was something I would hit much earlier in the year, and that what I was really hoping for was 12 games in a year.

Imagine if I made a game of the quality of Toy Factory Fixer every two or three months. Is it so unrealistic that I would have had 100 subscribers to my mailing list by the end of the year?

By my math, if I only gain 6 subscribers a year for some reason, am I really looking at 13 more years before I hit that number? That’s ridiculous.

But clearly something has to change if I want different results.

What else?

Well, I tracked 299 hours of game development, which is pretty close to almost twice what I did the previous year. 300 hours in a year might not sound like much, as it amounts to a little less than two months of full-time effort, but since I am part-time and have a family and other obligations, it represents the fact that I made it a priority to put in effort week after week.

I published 60 blog posts, slightly more than the 58 from the year before, and it was mostly weekly sprint reports. Those reports functioned almost like a combination sprint retro and demo, in which I demonstrated what I got accomplished. I got into the habit of writing the report, then planning the next sprint once I had taken time to think about how things went. Plus, people responded positively, especially when I had animated GIFs or videos to share, and since I love reading about behind-the-scenes of games, I thought others might, too.

I created an update for Toytles: Leaf Raking. It’s more compatible with modern Android and iOS systems. Otherwise, I haven’t changed anything about the game since the previous year. My expectation was that I would work on a Freshly Squeezed game, then work on a Toytles: Leaf Raking update, then work on another Freshly Squeezed game, but obviously I had no concept about how I was going to make that work.

Without contract work and with very few sales, it was very easy to have a lot more expenses than revenue. I can’t control my income, but I can manage my expenses a lot better going forward.

My personal goals for the last year were similar to the year before:

  • Do a minimum number of walking hours, push-ups, squats, and planking
  • Read a book per week
  • Create at least one doodle per day
  • Do 15 minutes of focused learning a day

I successfully did 15 push-ups, 15 squats, and 30 seconds of planks every day of 2021. Look at all that green in those columns!

Morning Exercise Routine In 2021

Technically, my daily exercise streak goes back to October 19th of the previous year.

I also did yoga on most weekends, and I think my body feels more physically capable than it has in a long time. In the past I would sometimes hurt my back or side, but I’ve been able to avoid seeing a medical professional for a long time.

Unfortunately, I rarely did anything cardio-related. Once again, the best of intentions doesn’t mean much, and my goal of walking everyday was hampered by the lack of habit, the broken treadmill I’ve been meaning to repair, and a lack of commitment. I sit too much, especially since I have my day job work and then put in even more time for my business.

I read a total of 33 books last year, the most in a given year since I stopped listening to audiobooks and switched to podcasts in my car a few years ago. I count 11 books related to games, including a bunch from Ian Bogost and a couple about making games with deeper meaning. Another 10 books were productivity or business-related.

I only read four fiction books, including Seveneves and A Game of Thrones, each of which took up a significant amount of my before-bedtime reading. I also greatly enjoyed Redwall, which was seemingly even more brutal than A Game of Thrones was.

Other books were related to history, parenting, comics, or DIY renewable energy.

I continued to do a daily doodle, alternating between drawing faces, drawing objects, and body parts like hands, legs, and feet. Sometimes I did cartoony drawings, and sometimes I tried to make it as realistic as I could. Once in a great while, I would look up a tutorial online, but I felt like I was in a holding pattern of putting in the time to make the doodle but not really growing in skill.

The new thing I tried to do was make explicit time for learning. I value learning and growth, and in the past I have invested in books, conferences, online courses, and such, but I never made an explicit plan to take advantage of those investments. So I made it a daily habit. 15 minutes a day adds up over time. I tracked 137.75 hours of learning, on topics as varied as game programming, game art, game production, creativity, and various personal development and technical things. I have had a Pluralsight subscription for the past couple of years, and this goal allowed me to take advantage of it more than I have in the past.

Goals for 2022

If the last year has shown me anything, it’s that even if I were to write down all of the outcomes I would like, it means nothing without a plan and without my capacity to work on that plan.

In 2010, I quit my job and became a full-time indie game developer. After running out of cash, I went back on “corporate welfare” in 2012. My expectation then was that I would build up some savings and quit again, but I didn’t take into account how being married and having a family would affect my risk assessment (or how much my family’s risk tolerance would inform my decisions), and I have had a day job ever since.

Clearly I wasn’t going to accidentally make GBGames my main employment, so last summer I started writing a “Full-time Indie Plan.” I wrote down how much money I was currently earning from my day job and how much money our family budget currently is vs what it would look like cut to its essentials. I documented details about platforms, revenue sources, challenges, risks, what I wanted to accomplish and what I explicitly didn’t want to do (such as spy on customers or bombard them with ads) and more. And the most important part of it is answering questions about how I was going to make it happen, such as identifying exactly what needs to happen in terms of sales, marketing.

This document isn’t finished, and while I expect it to be a living document, I recognize that I am repeating mistakes I’ve made before when I’ve done similar exercises in the past. Namely, I can come up with a lot of questions or categories, but then I don’t actually address them.

So while I have documented what I value, such as privacy, encouraging curiosity, supporting creativity, and others, and while I have done a SWOT analysis (although maybe I can iterate on it some), I haven’t answered questions about who my audience is and how I can reach them. I haven’t made a solid plan for actually marketing my games besides blogging and sharing on social media. It’s a 13 page document that has a lot of TODOs and headings without content in it.

But of course, I only have so many hours in a day. Even if I could identify 100 marketing activities, if I can’t actually make time to do them or manage someone else doing them, it does me no good.

My current lack of capacity should inform my goals more than they have in the past. Any marketing I would do would be inbound in nature rather than outbound, as it is less expensive and takes advantage of doing something once, such as publishing a blog post, and distributing it multiple times for near free.

So here are my goals for 2022:

  • Release at least 2 Freshly Squeezed Entertainment games by December 31st
  • Increase my newsletter audience from 22 to at least 34 subscribers by December 31st
  • Earn at least 1 sale per month by December 31st

I still think my overall Product Development Strategy is still sound. Create free value, ask for permission to talk with people who have shown they like my games, and then use their feedback to help me make deluxe games that are more likely to sell.

Creating two games in a year should be doable if I put on my game producer hat more often. I would love to try for four games, giving each one on average about three months, but I’m already worried that I’m still overestimating my capacity with two.

My newsletter went up by 6 subscribers last year. Now that I have one Freshly Squeezed Entertainment game out and expect to have at least one more by the middle of the year, can I find 12 more fans who are interested enough in my games to sign up?

I don’t have a sales plan in place, and clearly one sale a week was too ambitious. Still, one sale a month sounds like a ridiculously small amount, but then again, it is clearly a difficult goal for me at this time. It works out to a little more than double the sales I made in 2021, which was slightly fewer than sales from 2020. Making that trend go back up will be huge.

Besides those overall goals, I do want to spend some time porting my existing games to desktop platforms, and I’ll need time for that effort that isn’t going to be going into new development. I already develop on my Ubuntu system, so creating a Linux-based release shouldn’t be difficult, but since both Windows and Mac OS are trying to be walled gardens, I need to figure out how I can create free games for them without it costing me a ridiculous amount of money.

I also want to make time to actually play games. Between all of my old consoles, Steam, Humble Bundle, GOG, and Itch, I have a lot of games, many of which I’ve paid for, that I never enjoy or even learn from. Last year I played Castles I, Sunless Sea, To the Moon, Minecraft, and Super Crate Box, and shortly after I released Toy Factory Fixer, I allowed myself to play The Legend of Zelda: The Wind Waker during my week off from the day job near the holidays.

But much like my 15 minutes of learning each day habit, I’d like to make regular time to play games, even if it isn’t daily, even if it is a dedicated part of a day once a month.

Ok, so maybe two games in a year is starting to sound ambitious…

Anyway, I hope you have a safe and healthy 2022! Happy New Year!

Game Design Game Development Geek / Technical Personal Development

Freshly Squeezed Post-mortem #1: Toy Factory Fixer

Now that my first Freshly Squeezed game has been out for a few weeks, I thought it would be a good time to look back and see what lessons could be learned for future projects.

Toy Factory Fixer, a turn-based toy factory management game in which you hire and manage workers to ship toys, was a project I started in December of 2020, the first of my Freshly Squeezed Entertainment line of games.

Freshly Squeezed
Toy Factory Fixer

As I said in the my first progress report post for this project, Freshly Squeezed games were meant to be quickly created within a month and given away for free.

The idea behind giving away free games is that I want my games to have as little friction finding their audience as possible, and if enough demand exists for a particular game, perhaps I will create a “deluxe” version for sale. In other words, rather than guess at what random strangers might want based on trends and fads, I’m trying to find and get faster feedback from the people who would be interested in playing the kinds of games I am creating.

So I’ll start by saying that Toy Factory Fixer was meant to be a one month project, with a target deadline of December 25th, 2020.


I ended up publishing the game in the Apple App Store and on Google Play on December 14th, 2021, over a year after I started.

For the mathematically inclined of you, you probably noticed that it definitely took much longer than a month.

But this is a post-mortem! Let’s talk about what went right, what went wrong, and what lessons can be learned from the experience.

What Went Right

  1. Paper prototypes helped me narrow in on the concept and game play early

    At the end of November, right after my latest published update of Toytles: Leaf Raking, I already came up with the general idea for Toy Factory Fixer. So right away, I had the concept on paper. Originally, it was a Christmas-themed game, with the idea being that the in-game shipment deadline was Christmas Eve and Santa needs those toys.

    But how would the game play? It could be anything.

    When you have the proverbial blank slate, there is a lot of potential, with many directions to go in, and it can be quite exciting.

    But you can’t stay in this amazing realm of imagination where anything is possible. At some point, you have to make decisions, which means cutting off some options as you choose others.

    Within days, I thought about a tower defense-style game, with a conveyor belt and workers (and machines, but those didn’t make it into the game).

    Toy Factory Fixer: Paper Prototype

    Toy Factory Fixer initial mechanics
    Now, I could have started coding and creating digital art, but that is an expensive thing to do upfront, especially in terms of game design. It’s faster and cheaper to use paper and markers.

    And doing so helped me to figure out the answer to some early design questions related to what the player would do within the game and how the various parts would work together.

    Should workers be able to do things automatically or require the player’s micromanagement?
    What obstacles would be in the player’s path?
    Should there be a turn limit?
    How does a worker get the parts to put together a Good Toy?
    How do toys on a belt interact with other toys?

    While not everything explored through this phase made it into the final game, it did help inform implementation details. For instance, I knew that I had to figure out what it meant to have multiple toys share the same location on the conveyor belt early on, and when it came time to actually write the code, I had already thought of a few solutions thanks to the quick paper prototypes I was able to come up with and ended up picking one that I thought made the game better than I had originally anticipated.

    I love the benefits of paper prototyping, and I wish I had done more of it, but for the amount I did, it definitely had a huge impact in terms of speeding up development and design work.

  2. Light-weight project planning helped me stay on task for the long-haul

    I’m a big fan of Agile software development, and so I am habitually used to focusing on value-delivery, working in short sprints, breaking down work into bite-sized pieces of value, baking in quality, and keeping the stakeholders/players in mind.

    I know some indie game developers work with a simple list of tasks, or maybe a list of must-haves and a list of want-to-haves, and it works for them.

    And maybe my spreadsheet is just a glorified collection of such lists.

    But from the beginning of this project, I created a backlog of features and tasks, then for a given week, I took a subset of the backlog and tried to get it finished. Then I repeated until I was done.

    Toy Factory Fixer - project backlog

    And that’s oversimplifying it, but that was the secret that kept me going for a year of very, very part-time development outside of the day job, the family time, and other obligations.

    I basically had a small set of things to do at any given time, and at the end of the week, I assessed how it went (usually by writing a sprint report blog post), took a few minutes to plan the next week’s sprint, and repeated.

    The slightly longer explanation is that I estimated how much work any given set of tasks was going to be when it is in the backlog using t-shirt sizes (Small, Medium, Large), and when I planned the sprint, I broke down those items into more detailed tasks so I knew what needed to actually be done. Then whenever I was doing game development, I’d look at the spreadsheet, pick a task, and focus on it until it was done.

    And since I usually didn’t get more than hour of game development at a time, I found great success with small and specific tasks rather than high-level, vague descriptions that leave a lot up for interpretation even though I’m the one who wrote it in the first place.

    I had a daily habit of putting in game development, and my project plan helped keep each day’s game development session connected to the previous one. Even if I went a few days without doing any game development, keeping my project plan front and center meant that it was easy to get back into it.

    I am not saying that everyone should do what I did. I’m merely saying this is what I did, and it worked well enough to keep me focused until the project was finished.

  3. Light-weight project planning helped me adapt to changes discovered mid-development

    I’m not going to pretend that games are special in terms of the need to deal with changing requirements, since so many software (and non-software) products also deal with it.

    But quite frequently I would add a feature, playtest it, take a step back, and realize that the player is going to need more feedback to know what is going on.

    That is, mechanically something might be in the game, but if the player gets no indication, it can be easy to miss.

    So sometimes I would discover partway through the work that there was more work to do.

    And no, I wouldn’t describe this as feature creep.

    Let’s take the time I added the ability to earn money when you ship a Good Toy.

    When you ship a Bad Toy, nothing happens (and maybe I should have added some negative feedback there like I’ve thought about doing for months, but ah, well). When you ship a Good Toy, it looks like nothing happens even though you earned money. If you were paying attention, you would see the money value is different.

    But as a player, you aren’t paying attention to that part! You’re trying to pay attention to everything else going on in the game!

    So I did a few things. One, I changed the value of everything by an order of magnitude. Workers used to cost 10 Money, and then they were 100 Money. Why?

    So that way I could more easily make it obvious that the player’s Money interpolated as it changed from one value to another. There is something satisfying about seeing numbers change over time instead of instantly changing at once.

    Of course, once I did so, I realized that it felt too slow when the numbers change a lot, so I even tweaked it to interpolate faster with larger changes in value.

    And I had the money the player earned fly from the shipping chute towards the Money balance at the top of the screen.

    These were small bits of polish that really helped sell what was happening to the player, and I didn’t anticipate them when I started.

    But I had a plan! Didn’t these changes get in the way of the plan? Didn’t they slow me down?

    No, that’s another thing about Agile that I like. You learn things as you work on a project, and that learning should inform the work.

    So my light-weight planning tool was easy to modify on the fly. I could be days into a given sprint, and I might realize that a given feature had a few extra unidentified tasks in it before I could say it is truly complete. I have the option to add those tasks to the sprint or create a new feature in the backlog if I decide I’ll work on it in a future sprint.

    Toy Factory Fixer - Sprint Plan Change

    It’s mere seconds of work to update the plan, and I can get back to work.

    Now, I could argue that the downside is that I allowed for scope to balloon for any given task, but I’m alone in this project. I didn’t need to argue or justify or push back against someone else’s requests. I just had to make a judgment call on whether or not I should add work. And while I often did, which led to the year-long project, I also had quite the backlog of new ideas that never made it into this initial release because I was trying to keep scope down.

    I think it is easy to let the light-weight part mean that I didn’t put on my producer’s hat often enough, but it did let me make changes on the fly fairly easily while keeping on top of it all, and I think the game is much better for it.

  4. Having testers meant finding major issues and getting feedback right away

    At one point, I put out a call for testers, and two people replied.

    And they made a huge impact, both in terms of game play and in terms of basic functionality.

    When you are targeting mobile platforms, you have to deal with regular cycles of sometimes seemingly-arbitrary changes to those platforms. They aren’t changes I care about other than the fact that they might break how my games work on those platforms.

    So imagine my surprise when I was regularly testing my game on my Android device only to find that a tester couldn’t get past the main menu on his Android device. He said it looked like the game was frozen. And after adding some debug code, we verified the game was not frozen but was, in fact, working quite well except for the tiny detail of touch inputs not getting processed.


    Weeks later, I finally figured out that the major culprit was that Android 10 somehow handled touch input differently from my much older Android device, or at least differently enough that libSDL2 wasn’t really behaving the same way. My workaround was to exit out of a message pump any time I process any input, which allowed my code to detect when a player pressed and released a button. It otherwise wouldn’t notice because the press and release happened at the same time and so the before and after input state would look the same.

    Separately, the testers frequently told me what was confusing or what worked well, and a lot of their feedback made it into the game in one form or another (further adding to the scope, but I think for the better). Some of their feedback is still in my backlog as things I want to add to the game but that didn’t make it into this initial release.

    Also, it is quite gratifying to have testers tell you that the game is fun. When you’ve been doing your own testing of an in-development level over and over and over again, falling asleep at the computer (and worrying that the game is boring enough to make players also fall asleep?!), it is so great to hear that someone else is enjoying what you’re making.

    I probably could have been in more frequent contact with the testers, but I was also trying to be mindful of the fact that they were volunteering and had their own obligations and time constraints. As things stand, though, I am really thankful for their efforts.

  5. Little bits of polish went a long way towards making the game look interesting

    I already talked about the money interpolation thing above, but at some point I realized that the game has a lot going on but looked like nothing was going on.

    Still frames and screenshots are fine, but animated GIFs and video tell quite the story. Except they were boring-looking stories.

    And at some point, I had accepted that this project was taking a lot longer than a month, and I wanted to give it the best chance to find an audience, so I thought it was important to add some “juiciness” to the game.

    I added animations, such as having the toys lean back as they are moved forward on the conveyor belt, or having the workers move their arms when they are finished separating a Bad Toy, or having the worker’s eyes look at a nearby Bad Toy.

    Here’s what it looked like in January:

    Toy Factory Fixer -Dispensing Toys

    And here’s what it looked like in September:

    Toy Factory Fixer - Strong Workers separating two toys at once

    My favorite animation is a toy arcing into the air and back down to land on the conveyor belt with a thud. There’s a small dust ring that appears, and the squash/stretch of the toy as it moves it subtle yet works really, really well. And the sound effects really sell it.

    Most of this work didn’t feel like it took too much time to implement, and some of the effects were purely aesthetic, but a lot helped communicate to the player what was happening. Seeing floating numbers appear as toy parts were added or taken away from the inventory worked way better to let the player know that the quantities changed.

    And it made the animated GIFs look way, way more entertaining.

What Went Wrong

  1. I stressed myself out with my arbitrary one month deadline…for months

    Freshly Squeezed games were supposed to be quick. I wanted to create one-month prototypes. But I also wanted them to be polished and finished enough that someone could say “Yeah, that was a complete experience…and I want more.”

    And every week after the one-month mark was another week that my game was overdue and in which I failed to do the “simple” task of creating and releasing a game.

    I especially felt bad after three months had passed. That’s 90 days! I should have had a Minimum Viable Product by then!

    No one was promised this game in one month. I had no customers or stakeholders who paid for it. And yet, I felt pressure to get it done.

    I mean, the longer this one game took to make, the fewer games I could make for the remainder of the year. And without even one published game, I couldn’t find out if the Freshly Squeezed “give away polished prototype, hope people subscribe to learn about future games” idea was likely to work. The entire product development strategy felt like it was in jeopardy! I needed to ship!

    Now, it turned out that I had underestimated the amount of work it would take to make something I would feel proud of releasing. A key part of Freshly Squeezed games was that they were not going to be shoddily-made, and it turns out that quality takes time.

    And as I wrote throughout the year, game development time was not something I had in abundance.

    The game ended up taking as long as it did. I don’t like saying “It’ll be done when it is done” because, you know, I did want people to play the game before I turned 80-years-old. I don’t have the luxury of working on games forever.

    In a well-run Agile project, if there is an arbitrary deadline, you work on the most valuable thing and have something to ship as soon as possible, and you build on it so you always have something functioning and ready to ship. And you expect that a lot of items in your backlog won’t make it into the final product by the deadline, but you know you got the key things in, AND that there is no other optimal way to do it that wouldn’t require inhumane working hours.

    I wanted to have both that arbitrary deadline AND the ability to keep expanding the scope of the work, and it doesn’t work that way. I probably should have realized early on that, no, this project was going to take longer than a month, then figure out what my minimum release criteria was as early as possible.

    Of course, the version that did get released feels like it is already fairly small in scope. Anything smaller, anything I would have released earlier feels like it would have been a much lesser game for it.

    Perhaps going forward, I limit myself to a maximum of 90 days for any one project, and I hold myself honestly to that deadline. It would require me to spend more of my time upfront exploring the basic game play, and only then can I polish it up.

    But it definitely requires me to rethink my product development strategy going forward.

  2. No real design document meant a lot of wasted energy wondering what should and shouldn’t be in the game

    I’ve never spent time creating massive 300+ page design documents, of course.

    But in the past I have found that even a 48-hour game jam went more smoothly when I made use of a living design document.

    Unfortunately, I didn’t use one for this project.

    Instead, I had random notes on sheets of paper, random notes in my development notebook, and the random ideas and features I threw into my project backlog.

    My project plan is in a spreadsheet, and one tab had a vision for the project, but it was very much focused on the purpose it had as a Freshly Squeezed game, as well as some guiding principles such as a desire to make the game family-friendly.

    So, when it came to making decisions about what to put into the game, I didn’t have much of a North Star to guide me.

    I had a lot of ideas, but they were not together in one place, which made it hard to think about them cohesively.

    I used different individual tools separately, and to great effect. For instance, to get the look of the workers in the game, I found images of Christmas elves online. I found a lot of reference art, which helped inform the creation of the sprites for the elves (hey, that’s almost a pun…).

    I doodled and sketched out ideas, and some ideas made it into the game partly because that prework helped me figure out how to make it real.

    But it definitely felt like I was randomly deciding what features were key and which were optional, and it would have been nice to codify that decision even if it was after the fact. That way, when I was revisiting an area of the game months after I last touched it, I wouldn’t have to remember why I chose not to do something or why I went in a certain direction.

  3. I spent time on polish before I spent time on nailing the game play down

    I think reading and watching videos about adding “juiciness” to games got me thinking that my game looked lifeless, and I needed to address it.

    Some of the work was quick, such as making the toys animate as they move down the conveyor belt.

    I’m very proud of the polish I put into the game, but added up, all of this polish and “juiciness” took a substantial amount of time.

    Which is fine, except that even after a lot of polish work, I kept adding major game-changing features since the game felt incomplete without them.

    Now, I’m not sure if it is necessarily wrong to polish existing features before moving on to adding another feature. After all, if I intend to ship any day, having a prototype that looks like it was hacked together is less appealing than a prototype that looks like a finished product.

    But I think the fact that I didn’t have a clear idea of what needed to be in the finished product until almost a year later made it easy to keep extending the work by adding animations, particle effects, and more.

    They were always justified, of course. The animation and sound effects act as powerful and immediate feedback for the player. They aren’t just eye-candy. They actually help the player significantly.

    But I think being more deliberate about fleshing out the core game mechanics first would mean it is cheaper to try exploring a few ideas before settling on them.

    Adding polish basically means I’m baking the features into the game, and they become harder to change.

    Toy Factory Fixer - money text floaters

    I can always iteratively add polish, revisiting things instead of trying to get it right the first try.

    My first pass at income generated from shipping Good Toys was functional and non-obvious to the player when it happened. My second pass added an animated amount that flew towards the player’s money balance at the top right, but it was hard to read as it went too fast and if it went slower it would be distracting. My third pass was to change it to floating numbers that disappeared after a short period of time.

    I think purposefully identifying potential iterative passes for polish might help balance between focusing exclusively on functionality and spending too much time on making things look and feel good before that functionality is all in.

  4. Being very, very part-time meant not a lot of time dedicated to experimenting with game design

    Rereading all of my progress report blog posts, one common theme was that I wish I could dedicate more time to game development.

    I lamented the lack of hours. A lot.

    So, I apologize if you got tired of reading it.

    But besides forward progress being slower than I would have liked, a lack of time meant I had to limit the amount of exploration of the game design space I could do.

    Game development is iterative and incremental in nature. You make something, then you build on it. And sometimes what you build is only obviously wrong after the fact, when you can experience it in motion, so you throw it away and try something else.

    If you could experiment with game play once a day, you could learn a lot about the game you are making, and you can find all of the dead ends right away, and you can find the more entertaining experience sooner. Any one option is cheap to try.

    But if your experiments only come once every few months? Now your changes are expensive to make. A choice to try something is more likely to become permanent simply because there isn’t time to replace it with something better.

    For example, at one point early on, I was worried that it was tedious to direct individual workers to craft toys. And frankly, I still am. But how much experimentation can I do with such a core part of the game, especially when I thought I was almost done for most of the lifetime of this project?

    So that mechanic stayed as it was.

    I did create the Go/Stop buttons partly as a result of tester feedback, so there were some things I thought of that eventually did get experimented with, but the point remains.

    If I wanted to release a playable game in a relatively timely manner, any game design experiments would have to be focused and quick. Maybe instead of fully exploring a design aspect, I try two proposed ideas and pick the best one. Or I try one and see if it works well enough, then move on.

    Much better would be to focus full-time on game development, but until my circumstances change to make that possible, I’ll need to figure out an approach to game design that let’s me maximize design exploration in as little time as possible.

  5. I didn’t pay attention to release criteria until near the end

    I laugh today at how optimistic I was about how soon I expected the game to be released. First, it was by Christmas. Then it was by the end of the 2nd month. Then the 3rd month. My birthday in July? Before a year of development was done. At least by the end of a year of development!

    I didn’t have game play for months, and it was almost six months into the project before I felt comfortable handing it off to testers to try. Why did I think I was almost done when I didn’t have any levels to play in?

    There is a difference between a wish (“I’d like to release this project within 30 days”) and a reality-based plan to accomplish it.

    I somehow fooled myself into believing that I was somehow going to finish the game just because there was a day I said I was going to be done. Even if that day changed every time I missed yet another deadline.

    Much of development early on was infrastructure and scaffolding. I created kind of a template for a menu system that all future Freshly Squeezed games will use. But that didn’t help me get a game done quickly.

    Later, I was solving platform-specific issues with newer Android OS versions, and then I was dealing with iOS build issues. They were important, but they delayed work on the game itself quite a bit.

    And I kept adding scope to the game. Sometimes it felt legitimate, like adding animations to help communicate what was happening in the game to the player, but sometimes it was plain old feature creep.

    I tried to separate my backlog between must-haves and would-like-to-haves, but the must-haves list kept growing in scope.

    I had 25 items in that must-have backlog when I started, and ended with about 95, with another 40 or so ideas that I decided not to include.

    At some point in late October, I decided that what was possible to do in the game good enough, and I created a hard list of things I needed to do to finish v1.0 of the game. The biggest “real” task was deciding on and creating the number of levels I would ship with, but the rest included some key areas of polish, options to toggle sound and music, and creating an in-game help.

    Having that release criteria helped me focus on finishing in the final months. What would it have been like if I had decided earlier on the nature of levels in the game? Maybe that design document above would have helped inform other features.

    But the point is that I spent quite a long time thinking I was almost done, only to identify a significant amount of work late that I could easily have seen if I was serious about releasing a publishable game as early as I would have wished for.

    I’m not saying that a plan would have been perfect, that I would have been able to predict with 100% accuracy how long the project would have taken. But I am saying that I had a plan, and I could have paid attention to it more to give me clues.

What I Learned

  1. Prioritizing the work is important enough to make time for

    Each week, I took a few minutes to plan the next week’s work. Sometimes it took more than a few minutes.

    With limited capacity in terms of hours, one might think that every minute of development counts, and I should spend less time on project planning. Simply work on game development until the project is done.

    But having limited time meant it was even more important to invest some of my time in planning. I always had a direction to go in, I always knew what I was working on next, even if that work was “figure out how to solve this particular problem.”

    My weekly planning cadence produced a lot of benefit.

    That said, I think I could stand to wear my producer hat more often. I overscoped a lot of my sprints, which meant that while I was making steady progress, I was also using any given sprint backlog less as a prioritized list of the most important tasks and more like a sub-backlog.

    Now, I’m generally fine with the work being fluid. If I learn things about a given chunk of work, if I come across defects, I throw them into mid-sprint backlog. Fine.

    But if I only get about two major features done in a given sprint, what sense did it make to add five of them to my sprint backlog? Again, wishful thinking served me poorly.

    What it did was give me permission to say “Well, any work unfinished will just carry over to the next sprint.” Which gave me permission to start work on some items without thinking through them, since, hey, I was just going to work until I thought it was done.

    Which meant I sometimes spent too much time on a given item of work. Or I allowed myself to work on a task that probably shouldn’t have been a higher priority, such as the amount of time I spent trying to create a background image for the game despite the fact that I am not an artist by trade and that all the time and effort I would put in would just result in a slightly less bad piece of art.

    Original menu screen background

    And if I really wanted to make a game quickly, even if I was going to be fine with it taking longer than a month, why didn’t I take advantage of the t-shirt sizing I did to create a rough roadmap or something similar that would help me understand just how much time might be needed to work on the game? I might still underestimate it, but I would probably be able to recognize that I wasn’t “almost done” for so many months if I could see that even the initial work I could identify upfront was going to take more than four weeks of work.

  2. A little polish and juiciness goes a long way

    I think it is safe to say that Toy Factory Fixer is my most satisfying game to play out of all of the games I’ve ever created.

    Most of the games I have worked on in the past were 48-hour game jam entries, and my efforts were focused on putting together a functioning game quickly and not necessarily on how it looks. In fact, many of those games were silent, with at most some sound effects thrown in at the last minute.

    Many years ago, I read a quote from a game developer saying that the lion’s share of game development is in the interface, and at the time I thought, “Ok, yeah, so there’s code and there’s art. Duh.”

    But then around that time while discussing how Model-View-Controller works, I had a realization that the interface to the underlying game system can itself be very complex. For example, when you click on a unit in a real-time strategy game, there is a lot of visual feedback. Sometimes the unit gets a little circle around it to make it clear which one you are currently looking at. The menu might update with the unit’s picture. A sound effect might play, like a worker’s bark. And when you click on a button to issue a command, the buttons will change to indicate which one you selected.

    And all of this isn’t strictly necessary in terms of the bare minimum to issue that command to that unit. That is, the underlying game simulation probably has no idea any of these clicks are happening.

    But the player’s experience? It is greatly enhanced. It is a lot less confusing, and it can often be a key source of the entertainment of the game on its own.

    When I added transitions to the screens of Toytles: Leaf Raking, I found that I loved how something as simple as fading in and out made the game feel better to play. The game is mostly static still, but it’s better than it was, even if only slightly.

    With Toy Factory Fixer, the toys went from merely traveling down the conveyor belt to feeling like they had actual weight and momentum. Functionally, they still moved one tile at a time, but visually and audibly, they arced into the air, landed with a heavy thump, then got pulled down the conveyor belt each time it moved. The toy parts flipped in the air as they soared towards the inventory.

    And when the toys got so much work done, I felt I needed to enhance the workers. They soon talked, blinked, looked at nearby toys, and waved their arms. You got a sense of their personality.

    And floaty numbers made it easier to see when you earned money and when you gained or used items in your inventory.

    Juiciness wasn’t just animations and particle effects, though. I had a list I created in July of various opportunities to add enhancements to the game, and some were more useful than others in terms of player feedback, and less than half of the ideas made it into the game.

    Some ideas were silly and meant just for fun. I always wanted to give the workers random names and irrelevant stats, such as “Laziness: 7” or “Disgruntled: 2”. Apophenia is a powerful thing to take advantage of, but it will have to come in a potentially future update.

    Other ideas that didn’t make it in might have helped communicate the state of workers, such as animations that indicate what they were doing, or communicate the lore of the game, such as letting the player see a description of individual toys.

    But even with the few enhancements I did implement, the game came alive, felt great to play, and seems to delight players.

    If I learned anything, it’s that I want to try to focus on adding personality to the game earlier rather than as an afterthought.

  3. The best of intentions isn’t a substitute for an actual plan

    Between assigning myself too much scope in any given sprint and allowing the game’s overall scope to grow throughout the project’s lifetime, I kept fooling myself into thinking I could do a lot more than I was demonstrating.

    I think feeling like I was supposed to be finished yesterday meant that I was mindful of keeping scope down, but I always felt like I was trying to figure out what was the actual minimum amount of scope I could feel good about.

    After one year, the game has 3 workers, 2 toys types, 2 toy sizes, 4 level layouts with 2 shifts each, and the option to play with a hard deadline or not. And a bunch of polish.

    What would this project have looked like if I was able to actually focus on game play for a month? Maybe one worker type? One level? Would the general design be quite a bit different to make up for the lack of variety of things in the game? And how little juiciness would it have? And is that fine for a short prototype?

    I think wondering about the above is fine, and in fact, it is probably what I should have been doing if I was serious about getting something out quickly. What wasn’t fine was pretending I was trying to make something quick while also not actually operating like I was.

    My original plan was to create polished prototypes, with a guess that a game might take up as much time as a 48-hour game jam entry might. After all, I have shown myself capable of creating a decent enough game in that time, and having that time spread over a month should be fine.

    But none of my games look and feel as good as Toy Factory Fixer did, which required an order of magnitude more hours to develop.

    In hindsight, I think with my current development capacity, perhaps a one month project is too short to explore the design space and develop something I’d be proud of.

    But I definitely can’t pretend my next project will only take a month if I just want it badly enough. I have to actually do the work of managing scope and/or my schedule.

    A project that I allow myself to work on until it is done is going to operate very differently from a project that that has a real deadline.

  4. Slow and steady can still cross the finish line eventually

    Looking at my records, I put in some game development time every week until the game was released.

    My best week was in May at 11.25 hours, and my least productive week was in December right before release at 1.25 hours, which makes sense as I was spending time on writing blog posts and email newsletters. My next least productive weeks were 2 hours each. Otherwise, I generally averaged 6.1 hours per week, which is a bit more than my 5 hours per week goal.

    This project took 299 hours in 2021 and another 32 hours at the end of 2020, for a total of 331 hours.

    It is about the equivalent of a little over two months of full-time effort, although when I was a full-time indie game developer I found that the most I could put in on any given day was about 5 hours, so let’s say it likely would have taken me between two months and four months if I was focused full-time.

    But I wasn’t full-time, so it took me a lot longer, which required a sustained effort over 13 months.

    Don’t get me wrong. I much preferred those days in which I was able to put in multiple hours, especially when solving a big problem. All things being equal, five hours in one day allows me to focus and work faster than five hours spread across a week. I didn’t need to leave breadcrumbs and notes for myself so I knew where to pick up the next day.

    But on the other hand, having a daily cadence of at least some game development time made it easier for me to keep each development session connected to the previous one. Those weeks in which I went multiple days without any game development made me glad I took notes about what I was doing (and curse myself if I didn’t), even if I caught up by putting in a lot more hours than usual. Otherwise, I wasted time trying to remember what I was in the middle of.

    I think that daily cadence, with a weekly goal, did two things for me to help me finish a long project part-time.

    One, I was always focused on outcomes. Whatever I was working on needed to contribute to the finished product.

    Two, so long as I was focused on outcomes, I just needed to put in the hours. Those outcomes weren’t going to happen unless I was sitting in front of my keyboard working on them. And a steady pace was better than crunching and needing to recover, both for my health and my family’s.

    Maybe 20 years ago, I once calculated that after you account for sleep, hygiene, mealtimes, and an 8 hour day job, I still had four hours with which to work on game development if I so chose.

    Today, it feels like there is a lot less time, as there is cooking, cleaning, and chasing after kids, among other things.

    I found I watched a lot of TV shows and movies with my family. I attended baseball games, helped coach soccer, and volunteered. Every so often I played video games, either alone or with someone else.

    And yet I still finished a game because I just kept working at it, day after day, week and week, until it was done.

  5. Player feedback as early as possible is huge

    I wrote about how important polish and juiciness was in terms of player feedback, but the biggest influence of my decision of what to work on came from other people playing my game and telling me how confusing it was.

    Even now, the v1.0 release of the game could probably use some more clues. I’ve seen players try to tap on things that aren’t interactive, or wonder what to do, or get frustrated when it isn’t clear how to get a better grade.

    But it was worse mid-development, and I knew because my testers informed me.

    Outside testers had access to devices that I didn’t, which helped me identify major defects with the Android version of the game early on. When it came time to actually publish the game, it was a relatively smooth review process because I already tackled the requirements earlier.

    I would periodically make time to play the game myself, preferably on a mobile device, and there is value to doing so. I sometimes noticed things that weren’t operating correctly, or weird graphical glitches, or game-breaking bugs. And sometimes I would notice when I wished I had something in the game, and then make it happen, such as the indicator that tells you which production run you are currently on.

    Toy Factory Fixer - production run indicator

    But working on the game everyday has the downside that I’m too familiar with it. I know how to play the game. I won’t run into the problem of wondering what to click on or what my goal is at any given moment because I already know.

    But reading the detailed reports from my testers helped me to see where someone who isn’t as acquainted with the game ran into trouble, and often it’s a matter of the game not providing feedback.

    Early on, the way turns worked was that they would be continuous until you either hit the Stop button or you opened a menu. Then, it stopped advancing turns until you hit Go. This made sense to me.

    But I got feedback from a tester that it was confusing that the game stopped. If you open a menu and it stops the conveyor belt, then closing the menu should start it, right?

    I didn’t initially want to change the way things worked, but as I played it and felt it was tedious, I decided to implement the suggestion.

    Which introduced a problem in that you had less control over the turns advancing. If you open up a worker’s menu and told them to craft a toy, then immediately the next turn starts. But what if you wanted to tell three workers to craft toys, and you didn’t want to waste turns?

    So I added the Stop button to every menu, which gave you the option to take a temporarily paused turn advancement into a stopped one. Once you were ready, you could hit Go.

    And in the meantime, I added a visual indicator that told you if the game was paused or stopped.

    So it was a lot of work sometimes, but the feedback I got from testers helped me see gaps in feedback from the game. Sometimes the solution I came up with was different than what was suggested, and sometimes I had to cut a suggested feature for lack of time.

    But testers helped me take this game to another level in terms of ensuring it had the best chance of delighting players.


Between Google Play and the App Store, I can see that I’ve had over 90 downloads of Toy Factory Fixer since I announced it.

I didn’t do a big launch, send the game to reviewers, or anything like that. I only announced it on my mailing list, on my blog, and on social media.

What is most interesting to me is that people are still finding it and downloading it weeks after the announcement.

I don’t know if the game or the posts I made about the game led to it, but Toytles: Leaf Raking sold a couple of copies last month after no sales for many months, which is a great outcome I am attributing to Toy Factory Fixer.

So far, even though periodically people do go to my newsletter’s signup form from my game’s menus, only one person signed up for it, and it was someone I know, so it remains to be seen if strangers will decide to subscribe.

The game took longer to make than I would have liked, but I am glad I put in the effort I did to make it understandable, entertaining, and enjoyable.

I once again validated an Agile approach to product development while also recognizing areas of production in which I could improve in the future.

It’s not exactly a complete success in terms of what I set out to do originally, but this first Freshly Squeezed game is published, getting played, and is acting as an ambassador for GBGames to the public.

Thanks for reading!

Want to learn when I release updates to Toytles: Leaf Raking, Toy Factory Fixer, 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, and eventually the Toy Factory Fixer Player’s Guide as well!

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Published! What’s Next?

Last week, I reported that I had submitted the Toy Factory Fixer builds to the app stores and was waiting for them to finish reviewing the games.

Within days, the game was approved by both, and so I published it to the world!

If you missed the announcement, you can read it and find links to the free game at

Sprint 53: Release criteria

Planned and Incomplete:

  • Create a strategy guide
  • Update Toy Factory Fixer web pages

When the game was approved by both the App Store and Google Play, I sent an email to my GBGames Curiosities subscribers first.

I then spent time updating my web pages that mention the game so that they no longer said “Coming soon” and had links to the app stores.

I also thought it would be good if the game’s main page mentioned the features and benefits of the game.

What I still need to do is create a new animated GIF. The one that is up is a bit outdated, as it features the third worker before I finalized how they functioned in the game, plus it has old art. I did not spend any time on making a replacement, though.

I announced the game primarily on social media, and one person already signed up for the newsletter, so that’s a good sign.

I had a lot of friends share it, too, which was nice of them, but I got to hear some amazing feedback from someone in the IGDA Des Moines chapter who loved the game.

The main thing I wanted to do was create a free Toy Factory Fixer Player’s Guide as a gift for signing up for the GBGames Curiosities newsletter.

My plan is for all of my Freshly Squeezed games to have a free strategy guide as a giveaway.

Aside from writing the announcements and making changes to my website, I spent almost no time on the planned work, partly because we’re heading into the holidays and I still have shopping to do, but also partly because after a year of development, I could use a small break.

I have read about how a lot of game developers don’t realize that a lot of work comes post-release, but as I didn’t have an audience I was hyping up, it has been a relatively quiet release, and I’m taking advantage of it.

What’s Next?

For the remainder of the year, I need to make some time to just be introspective and plan for 2022.

I like to write up post-mortems for my projects, and so after I finish writing the player’s guide and also see how the game’s metrics look in terms of downloads and how it impacted my newsletter subscriptions, a project post-mortem will be coming soon. In fact, I offered to present at the IGDA Des Moines chapter’s February meeting.

I’d like to create desktop ports of Toy Factory Fixer, so I’ll need to research the latest in terms of how to create a Windows and Mac release, especially since both of those platforms have some kind of signing requirements. I already develop on a Linux-based system, but I haven’t published anything for it in about a decade that wasn’t a Ludum Dare game, so I could probably stand to figure out if I need to do anything different. Perhaps I’ll use to distribute the games.

Speaking of Ludum Dare, I want to make sure I participate in Ludum Dare 50 in April. It will be the 20th anniversary, and I do not want to miss it.

I also have Toytles: Leaf Raking, and I should continue to create updates for it and port it to desktops as well.

As for my the next Freshly Squeezed project? I have some ideas.

I want to explore what persistence allows. Basically, if you can save progress, what does that open up in terms of possibilities? Toytles: Leaf Raking allows you to save your game, and yet I never implemented a way to save progress in Toy Factory Fixer even though it would have been nice to see how you rated on any given level and work shift. Perhaps a virtual pet kind of game would be a natural fit.

I just saw the movie Encanto, and it was gorgeous. A lot of the special effects looked like procedural animation. Basically, having a single flower pop up out of the ground is neat, but having thousands pop up one after another looks amazing. I am reminded of someone comparing the visuals of The Legend of Zelda: Ocarina of Time with some contemporary Playstation game, saying that while the Playstation game was big on massive spectacle, the Zelda game did a lot with a little, making the opening scene seem magical with subtle floating particles that chased each other like tiny fairies. One Ludum Dare game I never finished was about being a soldier who was sent to go find a giant, attract its attention, and then see if you could lead it back to trample the enemy’s base. I might tinker with the premise to see if there is a non-violent version I could explore, but I wondered if it would look great if the ground shook in ripples from the giant’s footsteps, and that your character could get tripped by those ripples.

In 2013, I worked on One Game a Month, and I have a lot of Ludum Dare and MiniLD projects. Many of those projects could be remade as Freshly Squeezed games.

And I could explore concepts such as randomness.

Of course, I definitely want to see if I can make a game much more quickly than one game per year.

But for now, I’m going to try to make time to play games and enjoy the holidays with friends and family, even if most of it will be virtual. Again.

Thanks for reading! And happy holidays to you and yours.

Want to learn when I release updates to Toytles: Leaf Raking, Toy Factory Fixer, 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, and eventually the Toy Factory Fixer Player’s Guide as well!


Announcing: Toy Factory Fixer, Now Available on Android and iOS 🧸

Available for free now on the Apple App Store and on Google Play, Toy Factory Fixer is a toy factory management game in which you hire and manage workers in order to ship toys by the deadline.

Toy Factory Fixer

Download on the App Store

Get it on Google Play

Bad Toys are accidentally getting created by the toy factory’s automated machines, and it is up to you to hire workers to separate those toys into parts and reassemble them together into Good Toys.

Toy Factory Fixer - game play

I have been working on this game for the past year, and I am so happy I can finally release Toy Factory Fixer to the world. I hope you enjoy it.

Toy Factory Fixer - game play

The game features four levels, each with an easy work shift and a challenging work shift. You can also choose to play without a deadline, or for an extra challenge, a hard deadline.

Toy Factory Fixer - game play

It plays much like a non-violent tower defense game, and it requires more thinking than dexterity.

In fact, you can hit the Stop button to plan your moves, then hit Go again when you’re ready, allowing you to take as much time as you need.

You can hire potentially three different worker types, each with their own unique abilities and capabilities, and you’ll need to strategically place them along the conveyor belt in order to handle the work.

And again, the game is free. For real.


Have peace of mind with a family-friendly, ad-free, safe game.

Play the game, and please let me know what you think of it!

Download on the App Store

Get it on Google Play

Part of the Freshly Squeezed Entertainment line.
Freshly Squeezed

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Submitted to App Stores…Now We Wait…

In my previous sprint report, I changed the URLs for my Call to Action buttons so I can do some simple analytics whenever someone shows an interest in signing up for my mailing list or otherwise going to my website, and I started updating the build so that the game complies with Google Play’s latest policies and requirements.

I continued the work of creating the builds to release to the app stores.

Sprint 52: Release criteria

Planned and Complete:

  • Update Android targetSdkVersion to 30
  • Create Android bundle
  • Create Google Play store entry
  • Create App Store entry

Planned and Incomplete:

  • Create a strategy guide

Unplanned and Incomplete:

  • Update Toy Factory Fixer web pages

First, let me take a moment to look harder at that number above. Sprint 52. That’s 52 weeks I’ve tracked my work on this project. An entire year’s worth of slow and steady progress. And it is finally coming to fruition.

I think I’ll have more to say about spending 52 weeks on what was supposed to be a one month project in a post-mortem.

Anyway, in my last report, I was worried about how changing the target SDK broke the game’s ability to open a web browser and get to my website, and luckily it was a relatively quick fix.

It turned out that Android is starting to require more information about what an app might do, and so there is a new thing in the manifest file called queries, in which your app expresses its intent to use things such as ACTION.VIEW with the scheme HTTP or HTTPS. Once those were in place, the app seemed to work correctly again. I plan to write up the technical details in another post.

Next up was creating a new Android bundle, and luckily there was no real difference between the bundle I submitted for an update to Toytles: Leaf Raking and the bundle needed for a new app, or at least I didn’t need to change anything on my end, so the bundle built just fine with my existing build scripts.

Then I needed to submit the bundle to the Google Play store, and it was here that I finally decided to figure out exactly what I needed in terms of screenshots and such. I re-created the app icon and the feature image since they were originally created months ago when the game looked a little different, then I spent time playing the game and taking multiple screenshots, trying to setup good looking situations that might make someone curious enough to play the game.

Toy Factory Fixer

I had to create a privacy policy, which is a little modified from the one I used for my previous app. I needed to specify details about the data I track, which isn’t much.

Otherwise, once I had the screenshots, I was able to submit the app for review.

Next, I needed to build the app for iOS, and there were no new requirements I could find, and I was able to build, test, and upload to the App Store.

I created a store page, reusing a lot of content from the Google Play side, and the only trick is that iOS requires separate screenshots for multiple form factors. As my game does scaling, it means in practice that there are black bars at the top and bottom or the left and right edges of the screen on some devices, and so I modified the existing screenshots quickly.

I similarly had to answer some questions about the data I track and how it is not personally identifiable, and then I submitted it for review.


At this point, all I can do is wait.

Toy Factory Fixer - In Review

Well, that’s not true. There is always more work to do.

In creating the privacy policy, I realized I needed to update the web pages related to Toy Factory Fixer. For instance, once the game is released, it shouldn’t say “Coming soon” anymore. The animated GIF is outdated. I need to provide links to the app stores. And so on.

And I still want to create a strategy guide as a free gift for people who subscribe to the Curiosities Newsletter (see below).

But basically, as soon as both app stores approve of the game, assuming they don’t find anything that I need to fix first, then I will be sending an email to my newsletter subscribers and telling them that the game is available.

So if you want to be one of the first to know, subscribe below!

Then you can wait with me, and I hope the wait isn’t too long. I’m really looking forward to you trying out my latest 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!

Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Android Requirements

Last week, I reported that Toy Factory Fixer was pretty much feature complete, and that all I needed to do next was package it up and submit it to the main app stores.

So how did it go? Well, I can say I anticipated needing to do extra work for compatibility with new platform requirements.

Sprint 51: Release criteria

Planned and Complete:

  • Update CTA URLs so they are more informative

Planned and Incomplete:

  • Update Android targetSdkVersion to 30
  • Create a strategy guide

I’ll start with what turned out to be the easier thing. The entire point of this game, and the Freshly Squeezed series of games I want to make, is that they are meant to be playable, relatively polished prototypes that I give away for free to make it easier for players to find them, play them, and if they enjoy them enough that they want to know more, they can sign up for the GBGames Curiosities newsletter (see below). Then, not only is it easier for me to tell fans about the games they’ve expressed interest in learning more about, but I hope that they become customers as well as collaborators who share with me what they would love to see me make so that they are more likely to be even more interested in what games I make.

For instance, I got an email from someone who is excited about Toy Factory Fixer and read that it will be available for mobile devices but would really like a PC version of the game to play with his daughter. So while I don’t have specific plans to create a desktop version of the game, I think I’ll make it a higher priority.

In the game, I have Calls to Action (CTAs) to ask people to sign up for the mailing list, and a colleague suggested that after going through all the trouble of putting this game together, I should do more to track which of the CTAs a player pressed so that I can be better informed going forward.

And that’s brilliant, so I worked on it, which involved changing the URL so that it provides URL parameters that tell me which of my games the player was playing, which OS (Android or iOS), which menu the button was on, and which variation of the button’s text was shown.

I don’t intend to add any kind of in-game tracking. As useful as it is, I would rather that the player not have to worry about my game needing permission to “phone home” with secret information, so I’m going without. But I think opening links to my website is fair game, as they player has already shown purposeful intent to go to my website.

I had to learn a bit about how my website’s analytics worked so that I could create a URL that makes sense, but I got it done.

Toy Factory Fixer - Call to Action on options screen

So, NOW I’m done with coding in the game. Let’s package things up!

Android requires new apps to target SDK 30. I expected this was either a one-liner fix in an Android manifest file to change from SDK 29 to 30, or it was going to involve figuring out what all changed on the Android side that would prevent things from just working.

When I build a debug Android apk and installed it on my Android 11 phone, I got excited that it seemed to work just fine.

But then I tried to tap on one of the CTA buttons that should open the browser and take you to this website, and it just…didn’t?

I can hear the audio feedback telling me that the game definitely knows you are trying to go to my website from within the game’s menu, but it wouldn’t.

So I checked the logs, and I can see:

AppsFilter: interaction: PackageSetting{[myApp's info]} -> PackageSetting{[Chrome's info]} BLOCKED

What the-?



Ok, so I double-checked, and before I targeted SDK 30, this functionality did work, so I think it is clear the only difference has to be related to some new requirements that Android’s SDK introduced.

It’s a little annoying that the app otherwise works correctly if I continue targeting an older SDK, but due to Google Play’s requirements, I need to target 30, which means I need to figure it out.

Unfortunately, it was late in the week when I discovered this issue, so I’m hoping it will be relatively quick work to investigate and fix it, but it is an annoying delay for an otherwise finished game.

I hope the iOS build isn’t similarly going to give me issues, but I’ll worry about that one later.

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 – Final Level, Fixed Major Defects, and…Feature Complete?

In my last sprint report, I talked about adding Calls to Action in the menus and creating easier versions of the existing levels in Toy Factory Fixer.

In the past week, I finished the work of adding an easier version of the fourth level, added level previews to the level selection screen, and fixed a bunch of defects, including one really, really big, game-breaking one.

Sprint 50: Release criteria

Planned and Complete:

  • Create training level versions of existing 4th level
  • Level Selection previews level details
  • Defect: Dispenser bonus menu can show different amount than what player is rewarded with

Not Planned and Complete:

  • Defect: In-game options CTA seems to persist despite closing the options menu
  • Defect: Main menu CTA seems to persist on How To Play Screen even if it shouldn’t be there
  • Defect: Possible to click on dispenser button after “1 turn left”, meaning the next production run to start is the next-next one, skipping toys and preventing the game from ending

Planned and Incomplete:

  • Update Android targetSdkVersion to 30

As I said last time, with the Thanksgiving holiday, I wasn’t sure if I was going to find myself with a lot of time to work on the game or hardly any, and as it turned out, I ended up doing no game development after Wednesday.

Despite putting in less than four hours of game development, I managed to get quite a bit accomplished somehow.

I finished creating easy and challenging work shifts for the four levels, essentially doubling the game’s levels to a total of eight.

I realized partway through the previous sprint that I would love it if I had an indication of what each level involved when I was selecting it, so I added a preview on the right side:

Toy Factory Fixer - Level detail preview

Toy Factory Fixer - Level detail preview

Fixing the dispenser defect was more involved than I originally anticipated. Originally, I thought the issue was that if you opened the dispenser detail menu, it would tell you that you would earn 50 pigeon coins (or whatever the amount was), but when you actually started the production run early, you would instead earn less.

And that was AN issue, but it wasn’t the only one.

Basically, once a turn starts, it must end, but it was possible to be on this menu screen and not have it update with the new turn number (and associated pigeon coin bonus). So I made sure to update it at the appropriate time (which was more involved than it might seem).

But then I discovered that you could do something even more than merely miss out on some coins.

If you opened the menu when there was one turn left, but that turn ended, then technically, the production run has already started, but the menu will now update with the NEXT production run’s data even though you shouldn’t be able to get to this menu. So if you start the production run early, you actually skip one of the production runs.

And I was able to consistently skip multiple production runs, so it was easy to reproduce the issue. But when I got to the end of the game, the dispenser thinks it still has Bad Toys it hasn’t dispensed, but it would have no way to dispense them, so the game would never end.

So I had to prevent this defect by basically checking for this special case and closing the dispenser detail menu if you somehow managed to open it and can see it when you shouldn’t.

It’s probably the ugliest, most special-case code in the entire project.

Anyway, I then discovered that my new Call to Action buttons were showing up where they shouldn’t. Or rather, they didn’t show up but acted like they had. That is, it was possible for the buttons to appear and then not exactly go away, so even if you didn’t see them, you could still accidentally tap on them.

Whoops. So I fixed it both in the main menu and in the in-game options menu, mainly by writing code that essentially says “Only handle this button when these particular menus are active and ignore it otherwise.”

And then…I was done?

The game is done?

I mean, there are a lot of other features and updates I would love to do, but for v1.0, the game is basically ready to go.

Except I have worked on it for so long that I now need to make sure I don’t need to update any SDKs or libraries or built tools in order to package it up properly for both Google Play and the App Store, each of which has updated their requirements in the last year.

But assuming I don’t get stuck figuring that part out for too long, I just need to build, package, and upload the game to the stores, create the store pages, including any pictures or videos, then wait for their reviews to tell me what I need to fix…

Well, it is hard to say how much longer it will be, but I’m hoping you’ll be able to play the game before Christmas!

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 – Creating Work Shifts for Each Level

Last week, I reported that I finished adding custom grunts/barks for the three worker types and made good progress on adding prominent Calls to Action in Toy Factory Fixer.

This past sprint I finished up the Call to Action work and started creating easier versions of the existing levels in the game.

Sprint 49: Release criteria

Planned and Complete:

  • Make mailing list CTA more prominent
  • Create training level version of existing 1st level
  • Create training level version of existing 2nd level
  • Create training level version of existing 3rd level

Planned and Incomplete:

  • Create training level version of existing 4th level

Not Planned and Incomplete:

  • Level Selection previews level details
  • Defect: Dispenser bonus menu can show different amount than what player is rewarded with

I got a bit of an early start, knocking out the Call To Action work and even getting the new first level work finished on Sunday.

Toy Factory Fixer - Call to Action on options screen

So the idea behind creating easier versions of the levels is that each of the four existing levels might be too challenging for new players. Once I finished creating the easier first training level, I realized I had a problem to solve on the level selection screen.

If I was adding four new levels, do I now have to create a way to scroll through the eight levels to choose from?

Instead, I rearranged the screen layout so that I could fit two new buttons at the top so that the player can choose a level and then choose a work shift:

Toy Factory Fixer - work shifts

Toy Factory Fixer - work shifts

After all, the level layout is the same, but the amount of money the player starts with, the target shipping deadline, and the configuration of the toys that come out of the dispenser are what is different.

I then worked on easier versions of the the remaining levels, but I ran out of time before I could finish the fourth level.

The good news is that the level design work has been straightforward and simple compared to the more challenging ones I made before. One reason is that I know the game’s systems a lot more intimately now, but another is that with the easier levels I am less concerned with providing a precise challenge for the player.

Each of these easier levels ramps up the production runs relatively slowly, and I found that trying different strategies and performing different actions can still result in different outcomes. The player should much more easily be able to get an A+ rating across all three categories at the end of the level, but it is still possible to do less well depending on how they play.

On Friday, I realized through play testing that it wasn’t clear what the difference between the two shifts could be, as all you see is a different description. Normally I am trying to avoid extra work before my 1st release, but I think adding the details on the right side of the screen is a quick task that will add a lot to the experience.

I also confirmed a defect that I wasn’t sure if I had encountered before. Basically, since turns will continue until they finish, it is possible to click on the dispenser button shortly after it appears in the middle of a turn update.

So you might see that the next production run will start in 9 turns, and the menu tells you that if you start it early, you’ll earn an extra 50 gold pigeon coins.

But when you do start it, you only earn 20, which is how much you would earn if there was 8 turns left.

So what I think is happening is that the turn updated and finished, but this particular menu didn’t get refreshed to reflect that fact. I expect it to be an easy fix, but it was also one I didn’t get to finish before the end of the week.

So this coming week, being it is Thanksgiving on Thursday, I’ll either have lots more time or hardly any time to finish these tasks. It’s hard to say because while I will have time off from the day job, that time can easily get filled with holiday and family logistics.

Once the above are done, I will work on creating the builds to submit to the App Store and Google Play for review. I don’t anticipate it taking much time, but this is a new project and not an update of an existing project, and I know each store has updated their requirements over the last year I’ve been working on Toy Factory Fixer.

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 – Finished Custom Worker Barks, Adding Calls to Action

In my last sprint report for Toy Factory Fixer, I had finished up work on the in-game help pages and made a lot of progress towards updating the worker barks/grunts so that they were more varied and specific to one of the three worker types.

I continued the audio updates this past week.

Sprint 48: Release criteria

Planned and Complete:

  • Update worker grunts

Planned and Incomplete:

  • Make mailing list CTA more prominent

I managed to put in more game development time than usual, which allowed me to finish the worker barks for all three worker types.

The Strong Worker has a deeper voice, the Normal Worker has a squeaky voice, and the Sewing Specialist sounds kind of weird with an echo-y, gruff voice, as if they might be a machine or otherwise augmented.

In summary, I went from having three barks for “attention” (when you click on the worker and they effectively say, “Yes?”) and three barks for “affirmation” (when you command the worker to do something and they say “Yes!”) that played randomly no matter which worker was involved, to having each worker personalized with five attention and five affirmation barks, for a total of 30 audio files.

For those who are interested, I saved them as mono Ogg Vorbis files to keep the download size down, as stereo would have effectively doubled the size of the files for no real gain.

Now, as Toy Factory Fixer is the first of my Freshly Squeezed line of games, which are meant to be freely given away in the interest of finding my audience more easily, I wanted to make sure that that audience knows how to connect with me.

So at the suggestion of a colleague, I wanted to add more prominent Calls to Action asking the player to sign up for the GBGames Curiosities newsletter.

I already had one on the Quit Verification screen, but I wanted to add some to the main menus and to the in-game options menu, and potentially at the level end menu, but I don’t know if there is room for the widget I came up with.

Toy Factory Fixer - animated Call To Action widget

As you can see, the giant orange button has some text (really, an image of text) floating above it that animates by scaling up and down repeatedly. There are four variations on that text, so hopefully it captures the player’s attention each time they see it.

Is it obnoxious? Maybe. You can’t miss it, as it is the main thing animating on the screen, and the point of it is to make it clear that there is a mailing list and you want to sign up for it.

And the point of giving away the game for free is to attract players, and if they like my game enough, I want them to want to hear from me to know when my next games are coming out.

I’ve also considered adding more calls to action asking people to follow me on Twitter or like my Facebook page. Maybe either of those is a lower-barrier-to-entry ask, but I think the mailing list is better in terms of the kind of engagement I want with my players.

Unfortunately, I didn’t get to finish up the Call to Action work when it comes to the in-game options menu, as it overlaps the existing modal dialog that is there, so I need to rearrange some UI elements, but it’s almost finished and I expect to get it done early this week.

In the coming sprint, I’m going to be creating “easier” versions of the game levels already in the game, and I’ll need to finish up packaging for both Google Play and the App Store.

Then, the last thing I will want to do before the game is released is create a strategy guide PDF, much like the Toytles: Leaf Raking one you can currently get (see below!) as a free extra incentive for people to sign up for my newsletter. I can write the copy quickly enough, but taking screenshots, cropping the images, and placing them in the text can be annoyingly tedious if my past experience will be any indication.

So I anticipate between two and four weeks left, depending on how smoothly the level-design work goes.

This is it. Don’t get scared now.

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 – Finished Help Pages, Custom Worker Barks

Last week, I reported that I was making decent progress towards the last tasks before Toy Factory Fixer was ready for a v1.0 release, starting with adding music to the menus, allowing the player to mute and unmute the audio as they please, and starting work on the in-game help menus.

I continued my work this past sprint.

Sprint 47: Release criteria

Planned and Complete:

  • Create How To Play menu

Planned and Incomplete:

  • Update worker grunts

I did not get as much game development in the last week as I usually do. That said, I finished the in-game help, including giving the player an indication of which page and how many pages they are currently viewing.

Toy Factory Fixer - help page

Toy Factory Fixer - help page

As for the worker grunts/barks, the current audio that plays comes from a royalty-free collection of audio I got either from a GDC giveaway from Sonniss or a Humble Bundle. Unfortunately, there wasn’t enough variety in those collections, so I decided to make my own.

I spent part of an evening in a room recording myself saying various phrases that I want the workers to say. My USB microphone and laptop weren’t giving me the quality I needed, so I used a Sony IC Recorder I bought in 2012 for a conference I was helping to run as I was recording the presentations.

When I felt I had recorded enough options, I used Audacity and sorted the phrases into tracks so I could choose from among the best options.

Toy Factory Fixer - Audacity with multiple worker audio tracks

I cleaned up the noise, lowered the pitch down on a few clips, and ended up with a bunch of barks for the Strong Worker to say.

Unfortunately, since I didn’t get as much time in for game development, I didn’t get to repeat the same kind of work for the other two worker types.

I expect I will be able to finish it early this coming week, and despite having a relatively slow week, I think I’m still on track to get this game out later this month.

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!