Last time, I reported that I had created some backgrounds and menus for my next Freshly Squeezed Entertainment project called Clown Alley Creator, a creativity tool about creating your own fun clowns.
I had fixed a defect in some of my oldest code and continued to work on the initial in-game menus this past week.
Sprint 2024-3: In-game Menus
Completed:
Create Gallery View menu
Create Clown Creator Mode general navigation button icons
Create Clown Creator mode general navigation menu
Started and incomplete:
Create clown preview cut-outs
Create clown preview in Creator mode
I mentioned the ButtonControl defect last time, but buttons now work in a much more intuitive and correct way:
Then I started creating the in-game menus. The Gallery View is currently very simple because there is nothing to put in the gallery yet. So I created a button to return to the Main Menu, and I created a button to start creating a new clown in the Clown Creator Mode.
I worked on some infrastructure code related to menus and widgets, mainly so that the animated button widget I had created would function properly. Basically, I wanted any interactive buttons to periodically let the player know that they are interactive, so every few seconds they will grow and shrink.
Then I created the Clown Creator Mode navigation menus. Basically, creating a clown will involve going through a sequence of menus to choose options related to the head and body shape, wardrobe, shoes, and make-up and hair. When you get to the last menu, you can choose to finish the clown, which will allow you to name the clown and save it to your clown alley and see the clown in the Gallery View.
Eventually. For now, the menus are navigable, either by hitting the previous and next buttons at the bottom or by picking one of the menus along the right side:
I finished the week by starting to work on creating a Clown preview in the Creator Mode. The idea would be create a bunch of sprites that, when composed together, create a clown that might eventually be animated.
Saturday night I went to bed feeling good about how productive the week was.
Sunday morning I woke up and realized that I wasn’t approaching this project in a very Agile way.
What Do I Mean by “Agile”?
Agile has become one of those terms that mean wildly different things to different people, so I want to clarify what I mean.
Some people think “Agile” means some form of dysfunctional approach to running a software project in which certain awkward practices and processes take primacy over everything else, no matter how painful it is.
If it wasn’t clear, that is NOT what I am talking about. You might hear people call it Agile where you work, but it isn’t really Agile. It’s just your probably-large organization not actually figuring out how to apply Agile to their existing processes so they keep a lot of baggage and then blame Agile for it.
But I can complain about dysfunctional work practices all day. For now, I want to talk about how my own approach to this project might be a problem, and I’m kicking myself for not recognizing it sooner, but I’m also patting myself on the head because I saw it early enough in the project to make some changes that I can still benefit from.
When I think about “Agile” I like to think of it as approaching the work in a way that acknowledges that we don’t know what might happen in the future, in a way that allows us to change, add, or cut anything based on what we learn as we go.
I don’t know how long a feature might take to work on and complete. Taken to the extreme, it also means I don’t know how long the entire project might take to work on and complete. I may or may not get sick, or have someone in my family get hurt, and so I end up with a lot less capacity to work on the project.
What does all of that have to do with being “Agile”?
Well, imagine that I continue the work as I have been. Here is a sample of my current backlog of identified work items:
Create Clown Creator Mode general navigation button icons
Create Clown Creator mode general navigation menu
Create skin color menu options
Create Head option and submenu
Create Body option and submenu
Create Wardrobe menu
Update Clown Preview to display clothing in layers and colors
Create clown preview wardrobe cut-outs
Create Shoes menu
Create clown preview shoes cut-outs
Create Hair & Make-up menu
Create hair option and submenu
Create make-up option and submenu
Create clown preview hair cut-outs
Create clown preview make-up cut-outs
Create nose option and submenu
Create clown preview nose cut-outs
Create Finish modal
Save/Load individual clowns
Update Gallery View to show all loaded clowns
If I were to work on these items in this order, it would make sense in terms of the order of the menus. I would work on creating the skin color and head and body submenus in the Head & Body Menu, then I would work on the Wardrobe Menu, and so on.
And this might work out fine, but it introduces some risks. This is supposed to be a six month project, which means that new development needs to stop before that sixth month, so really I only have a handful of months to implement everything.
Let’s say hypothetically either I take too long to make the Shoes menu or otherwise need to stop working on the project shortly after that point. If I absolutely had to publish the game at that point, what would be the state of the project?
Well, it would be unfinished! There is an entire set of menus related to hair and make-up that would be completely missing, and to make it worse, you could still navigate to that empty menu!
In fact, you couldn’t save or load anything, so the Gallery is perpetually going to be empty even though it is the first place you go after hitting Play on the main menu. How confusing and awkward for the player!
Even if you think it would be fun to just create clowns that you couldn’t save or load, how fun could it be to create clowns without being able to do their make-up? When you think of clowns, you probably think of clown noses, hair, and make-up before you think about their clothing. And yet this game would ask you to make clowns and ask you to ignore the hair and face entirely.
In short, approaching the project in this way would limit how adaptable I could be in the future.
A more Agile approach?
Imagine if I approached the work differently.
There are many valid ways to do so, but let’s pretend that last week I didn’t work on the Creator Mode navigation menus but instead focused on the Hair & Make-up menu as the sole menu. That is, when the player enters Creator Mode, they are exclusively working on hair and make-up.
Create Hair & Make-up menu
Create hair option and submenu
Create make-up option and submenu
Create clown preview hair cut-outs
Create clown preview make-up cut-outs
Create nose option and submenu
Create clown preview nose cut-outs
Create Finish modal
Save/Load individual clowns
Update Gallery View to show all loaded clowns
With just this smaller subset of the backlog completed, what would the project look like?
Well, it would be more or less complete as a game. It wouldn’t have everything I wanted, obviously. Clown faces aren’t the same things as entire clowns. I would want to continue working on the project.
But there would be a strong spine in place: you could create clown faces, save them, and see them in the Gallery.
In fact, rather than have “Save/Load individual clowns” as a separate work item, I would instead make it part of the work of each menu. That is, “Create the hair option and submenu” would also have an associated “Save/Load player’s hair option” task. Each menu wouldn’t be considered done until I could make something real happen by using it.
And that’s a much more Agile approach. Instead of merely splitting up the work, I am thinking through how to ensure that whenever I finish some piece of work that the project as a whole is more finished.
I’ll repeat that, because I think the core reason for some of the dysfunctional approaches to work I’ve seen is that people don’t seem to understand this concept.
Instead of just splitting up a project into pieces and then working on those pieces, instead of hoping that by putting enough finished pieces together that they will eventually become an integrated whole (and more likely have extra work trying to make it actually integrated as a whole), I could approach each piece of work as contributing to the whole in an incremental and iterative way. I could create the spine of the project, then continually add more and more to the bones while both maintaining and building a functional whole the entire time.
You know, how Agile is supposed to be.
I can’t go back and change how I worked last week, and it would be silly to completely rip out the menus I already created, but I am going to take some time to rearrange my backlog so that I can build that spine sooner.
Thanks for reading, and stay curious!
—
Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!
Now I’ve created a presentation based on that post-mortem, so if you prefer videos, you’re welcome:
—
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 full color PDFs of the Toytles: Leaf Raking and Toy Factory Fixer Player’s Guides for free!
After 20 months of development, I’ve decided to put on hold further work on my non-violent, first-person role-playing game The Dungeon Under My House, what was supposed to be my second Freshly Squeezed Entertainment project.
It’s a decision that makes me both sad and glad. I really liked this project and I enjoyed working on it and the idea of what it could become when it is finished, but as a solo indie game developer who is working very, very part-time, it is taking me too long, and from my very rough estimates that are probably very optimistic, I’d have at least a year of work left.
That’s a long time, and I need to be more prolific if I want to succeed. Maybe in the future if my capacity increases, I’ll return to it. I hope so. I think it was going to be a neat game.
Still, just because the project isn’t going to be finished and released (for now), it doesn’t mean there aren’t lessons that could be learned from it, which is why I’ve decided to write this post-mortem for it!
I hope one day in the not-too-distant future a second post-mortem of the project links back to this one.
The Dungeon Under My House started out as just an idea that I had at the end of October 2022. Now, ideas are a dime a dozen and all, but this idea wouldn’t let me go. I got excited about making a non-violent Wizardry-like first-person dungeon crawler in which you are a child hanging out with friends in your modern day home, only to discover a secret door in your basement that leads to a multilevel dungeon. It turns out that your family comes from a long line of explorers and adventurers.
So each day after school, you pick a subset of your friends (with unique strengths/weaknesses) to go into the dungeon for adventures. Adventures might take multiple days (you are children with bedtimes, after all, so you can only explore for so long), and you can prepare for adventures by raiding the house for supplies.
Encounters require you to use your skills and tools to distract, befriend, scare away, bribe, help, etc the creatures, monsters, or other adventurers you find in the dungeons.
In my head, The Dungeon Under My House would be a cross between Wizardry and The Goonies, in which your friends and your friendships play a huge role. It would also be a Freshly Squeezed Entertainment project, which as a reminder are games meant to be quickly created 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.
I started working on the project in earnest in November of 2022, with the hope that it would be a six month project, but anticipating that it might take me as long as a year.
Ha. Haha.
I don’t know why I was so optimistic. This was a big project, and I’ve never worked on and completed an RPG before, nor did I sit down to scope out the project to figure out how to fit it all within six to 12 months. But more on that later.
What Went Right
Creating a design document gave the project a North Star
I found it very helpful to identify the core design pillars, the theme and mood I was looking for, and general activities the player would participate in.
I anticipated that the design might change a bit. For instance, I originally thought the idea of designing your own adventure plans and then executing them was going to be a key part of the game play. I envisioned being at the titular house marking up the map with objectives, then entering the dungeon trying to achieve those objectives. As the project progressed, I could drop this set of features easily as it wasn’t strictly core to what the game needed to be.
But other things stayed the same. The game was always set in a sleepy modern-day suburb, so I never had to waste any time wondering about medieval or fantasy themes fitting in.
And the core pillar of non-violence helped me steer away from having any sense of a threat to the physical safety of the characters in the game. In my document, I wrote:
There should be no attacking or threat of attacks, no abuse, no physical or psychological danger, and no killing.
– So can there be threats that aren’t related to physical/bodily harm?
And then I listed out ideas of threats to property (theft, vandalism, etc), relationships (break-ups, loneliness, hurt feelings), and information (secrets, lies, incomplete knowledge).
The document got updated periodically as I needed to jot down parts of the design I hadn’t anticipated, so it wasn’t like I wrote the design once and forgot about it or pretended that I needed to stick strictly to it. It was a living document that I kept open on my computer any time I was working on the game.
And having all of my design notes and decisions in one place definitely helped me know what forward progress looked like.
Creating cheap prototypes and mock-ups sped up decision-making
The beginning of a project is always exciting, when anything and everything can be possible, but at some point I need to make decisions that take the project in a certain direction and necessarily cut off other options.
The design doc helped make some decisions quite easy as mentioned above, but other decisions involved choices that weren’t necessarily right or wrong for the project.
For instance, knowing that I wanted the game to have a 1st-person view in the dungeon, the question came up: what angle should the camera be at?
A simple solution is: centered! It would be simple, but it might look boring and uninteresting. Having the imaginary camera higher up and looking down more would show more of the current dungeon tile while also giving the impression that the ceiling is lower or that the player is taller. And having the camera lower would maybe be a more appropriate vantage point for the young children who would be the main characters in the game, but it might prevent the player from being able to see as much.
At the time, I was planning on using old-style tiles to simulate the three-dimensionality of the dungeon, so creating mock-up art for each angle sounded quite tedious.
Instead, I used a physical prototype. I took an old shoe box, printed out some dungeon wall image and taped it to the back of the box, then placed some wooden figures in it. Then I took pictures from various angles to get a sense of how it would feel.
It took me only a few minutes to create, and I learned right away which one I liked best.
There were also many ways I could show things on the screen, and even if I didn’t know what might be eventually on the screen in the end, I could at least start somewhere. So I created this mockup:
And I found that doing so helped me figure out where I thought some UI elements would work best. The downside is that I realized very quickly that my mock-up didn’t anticipate the on-screen controls that would be necessary for the mobile version, so I tried another mock-up:
The latest actual in-game shot shows that I tried a combination approach in the end:
One of the next features I would have worked on would have been the in-game map on the HUD, and so I was already anticipating needing to rearrange and resize various controls, but I know exactly where I want that map to live.
Looking for reference art helped me create a cohesive, “real” world.
I knew I wanted the game to feel light-hearted and family-friendly. I wanted to have stylized, cartoony art, so photorealistic art wasn’t what I wanted at all, nor did I want a gritty and dark theme.
I’m primarily a software developer, but I know enough about art that having good reference material helps a lot.
So I spent time looking into dungeons, sewers, caves, coal mines, and all sorts of things that could act as a dungeon hidden under a sleepy suburb.
I was disappointed to learn that most real world dungeons were not much more than pits to keep prisoners in, but I was delighted to learn that the Paris has a sewer museum! I even learned that here in Iowa the Wastewater Reclamation Authority has a website that describes how their facilities work AND THAT YOU CAN REQUEST A TOUR!
And I was very interested to learn of Derinkuyu, Türkiye’s underground city that was rediscovered when someone found a tunnel behind a wall in his home a few decades ago.
Meanwhile, the other part of the game would take place in the house, so I tried finding art related to various rooms: bathrooms, dining rooms, living rooms. A website about the living rooms of various 90s television sitcoms helped. The living room in my game has a staircase leading up because of course it did: that’s how the rooms on TV look!
When I found a neat cross-view of a house that had a dollhouse look to it, I knew that I wanted that look for my game.
Besides looking for environment art references, I also spent time looking for character art references. Various cartoons, comics, anime, video games, and even clipart examples of children that I thought seemed promising ended up in a large document. I even had some animals, because I hadn’t quite figured out whether or not all of the characters in the game would be human.
And with a game featuring people, I needed them to look distinct. Clothing store websites feature all sorts of child models, so I found quite a few neat looking outfits, which helped inform the clothing customization options that I added to the game.
Now, I could have done whatever I wanted. The existence of games featuring sprawling dungeons despite the lack of a real-world equivalent means that it is already OK not to stick to reality. But having a basis for the “reality” of my game’s environments and characters helps sell the reality better than if I used my untrained artistic abilities to freehand everything with no good rhyme or reason.
Something non-artists might not know: it’s not cheating to use references to inform your art. Use them!
Planning only one thing upfront to work on each week
This one is kind of a mental health thing for me, but it is a deliberate change from how I ran my previous projects that I think worked out well.
I ran my project on a weekly cadence. Each Sunday, I would write a blog post about the previous week as a development update, then I would plan the coming week’s sprint.
In the past, I would kind of mix up my sprint plan with my larger planning, and so I would pick a collection of features to work on, usually features that I think go well together. That is, once all of these are done, I would feel like a significant piece of the game would be done.
The problem was that sometimes one of those features big quite a lot to work on. Breaking it down into tasks, I’d maybe get a small subset of the tasks done.
Imagine weeks of saying “I planned to do X, Y, and Z, and I only did X” and you can see why I said it was kind of a mental health thing for me.
Even if I didn’t mean to say I would get all of these things done in a single week, it still looked like I wasn’t getting things done, and it can be demoralizing.
And of course, it is hard to predict when things would get done if I kept lying to myself. Not finishing these items means I can’t start working on the next items, and if I do this for weeks in a row, then if I was hoping to get the next item after Z finished by a certain date, well, I can’t even promise I’ll have capacity to start it by then.
So for this project, I made sure to only plan one feature. Then, I either finish the feature and start unplanned work next before the end of the sprint, or I have only the planned work that is incomplete.
By and large, it felt better. I no longer felt like I was behind, which is weird because I am my own boss and the feeling came from the accidental promise I was making by listing a bunch of planned work that I wasn’t actually trying to meet. It also helped me avoid deluding myself that a bunch of work would suddenly occur in a single week.
Creating devlog videos to attract more potential fans
I’ve always written about my game development. This blog started in 2005, after all.
But sharing my weekly devlog blog posts on social media only gets so much traction these days. Adding devlog videos might increase the likelihood that someone finds out about the games I am working on. It’s another opportunity for someone to discover GBGames and TDUMH.
So I started making a weekly devlog video. Here’s my first one, published on October 3rd of 2023:
Oh, that’s rough. You don’t have to watch it.
YouTube said it has 20 views total.
In fact, for the next few months, my videos would get about 6 to 35 views each. That’s not a lot, but you know, YouTube is very algorithm-heavy, there’s a lot of other videos being made continuously, my own videos don’t have amazing production values, etc.
So I spent some time looking into best practices. I started creating custom thumbnails instead of using a random frame from the video that YouTube chose, and I even bought a new microphone to replace the ancient one I’ve had since forever (I think I got it when Windows 95 was the latest thing).
With catchier thumbnails (I refuse to do a “stupid YouTube face” thumbnail no matter how effective) and a less tinny, much sexier voice, my videos started getting a couple hundred views as well as regular comments.
Creating the videos each and every week was hard work, even with the low production values. I would write a script, create some video clips of various new features or progress I’ve made on the project, then record myself talking through the update. In the end, I would produce a video that is only a few minutes long.
While I always tracked how long it took to write a blog post, one day I decided to track how long it took me to create a video from start to end, and I realized that it could take me about 1.5 hours.
Remember how I said that I am working very, very part-time? I don’t have 1.5 hours to create a video each week! It eats into the time to actually make something for me to show off in the video in the first place!
So I cut back to only creating a video once a month or two. One benefit is that I have more to show in a given video. Here’s the most recent one that I published at the beginning of this month, and you can tell that is definitely smoother, as I have gotten into a groove creating them in a consistent way:
And another benefit is that while it takes me longer to make each new video, I feel more comfortable with batching all of that time together once in awhile.
Obviously the videos are not bringing in thousands of customers, but I do think that it has helped me to increase awareness with a few people about what I am doing, much more than my blog and social media posts alone. As a bonus, it gives me practice with using tools such as OBS Studio, and I can also create animated GIFs more easily.
What Went Wrong
Not creating a real schedule resulted in a non-stop treadmill of development.
Definitely my biggest mistake was not creating a schedule for this project.
When I made Toytles: Leaf Raking, I created a road map. It was an optimistic road map in that I anticipated creating the initial release of the game in three months but the actual release didn’t occur until the eighth month of development.
But the road map was still helpful to create as it helped me nail down as much of the project as I could upfront. I knew that estimates are likely to be way off, but I don’t think I appreciated knowing as much as I did about my project.
When I worked on Toy Factory Fixer, I didn’t create a road map. I think I had read something about how road maps are awkward in modern development because it implies being able to believe in accurate estimates and also believing that you could know exactly what a project would look like at the end from the beginning.
In Agile software development, you expect to be able to adapt to changing market conditions, changing stakeholder demands, and changing realities. The road map is a relic of old-style plans that presume you can nail down requirements up front.
So I skipped the roadmap, and that project lasted a year. What I remember was that it was supposed to be a one month project, and each month I “hoped” that I would finally be finished with it.
In hindsight, I don’t know why I ever expected to be finished each month because I do not remember doing any work to figure out the full scope of the project until near the end. Maybe it was because I believed my feature backlog was exhaustive and was always surprised as I added to it?
For TDUMH, I once again skipped the road map, and I didn’t even pretend my backlog was complete. I basically came up with what I thought was a good first pass, and I fully expected that I would learn about the nature of the project as I worked on it.
I could be responsive, changing and updating my plan regularly.
And frankly? This works just fine. I could work on the project at the pace I am at indefinitely, and eventually the game would be finished.
At the same time, I did nothing to try to figure out how to fit this project into a six month period, which is what I wanted it to be. But merely wanting Toy Factory Fixer to be a one month project wasn’t enough, either.
So I had a conflict that I wasn’t addressing: my business expected me to release games more frequently, and my management of the project had me working as if I could take forever to release the project if I wanted to.
At some point in the last few months I realized that I needed to figure out how much work was left on the project, and with my very rough estimates, I’ve decided what was left was way too long.
And I think if I knew it upfront, I might have tried to make a smaller version of the game.
Not prioritizing the work well wasted my time.
Even early on I knew that by making the game non-violent, I would need to replace all of the compelling combat-related mechanics such as health, weapons, armor, attacks, etc with something equally or more compelling. My goal was to emphasize conversation and knowledge-acquisition.
The thing is, I didn’t know what it would look like.
A branching dialogue tree wasn’t going to cut it. I didn’t want to make a rigid story or a visual novel. I wanted something more dynamic and flexible, that required the player to make more interesting decisions than choosing between a handful of pre-written options.
In short, I wanted the conversations to BE the main game play.
And yet, instead of spending time prototyping conversation systems and UIs and researching existing games that do interesting things with conversation mechanics, I worked on character customization.
I justified it to myself. I really, really wanted the player to feel like they could see their friends and family, or maybe a fantasy version of who they wish their friends and family were, in the game. It seemed important at the time.
And I worked on creating the first person dungeon view, first by trying to create tiles, and then creating a raycasting renderer, and then profiling it and debugging it to see if I can get it to be performant each time I made a change that slowed it down.
In hindsight, I should have realized that the first-person aspect of the game, as nice a thrown-back as it was to the kinds of old-school RPGs I wanted to remind the player of, was not necessary or fundamental. A top-down overhead view would have been faster and easier to implement. Character customization turned out to be tedious work, which I didn’t anticipate when I started, and perhaps for this project I should have created concrete, unchangeable characters if only because it would have been faster.
And the main reason I wish I had done those parts of the game so much faster is so I could focus the bulk of my time on the more interesting game play that I was trying to create with conversations and personalities and knowledge acquisition. Instead, after 20 months, the systems in place feel clunky and limited, and I knew I still needed to expect to spend considerable time on experimenting and figuring out this core part of the game.
It would be one thing if I spent only a little time on non-core things. Spending 20 months on a project might have been more palatable if I had spent a large amount of that time coming up with new game play, but as it is, I feel like I could have used my time better.
Not quitting earlier meant missing opportunities to publish more frequently.
This one is kind of related to the previous points. If my goal is to release a game in six months, I should hear alarm bells in my head when I hit the six month point and not have a game anywhere near finished.
In fact, those alarm bells should have been heard long before six months passed, because I should have an idea how much of the game was finished versus how much is left to do and be able to figure out how confident I felt about getting the remainder of the work completed in the time left.
Instead, as I said before, I could work indefinitely on my project, inspecting and adapting as I go, and given my limited capacity, I wasn’t investing time to inspect the health of the project as a whole. I did not treat the six month deadline as a real deadline so much as a soft suggestion, which didn’t help give me a sense of urgency or a reason to worry.
Toy Factory Fixer’s initial release was in 2021. I didn’t start TDUMH until 2022 with an expectation that I would release it in 2023. Even if I had succeeded, that is already a long time between game releases, at least for my business goals. Taking longer than six months means even more delays for accomplishing those goals.
Maybe if I would have put the project on hold or canceled it in 2023, I could have used the time since then to figure out a smaller scoped game. Maybe by now I would have released at least one, perhaps two or even three more games.
Better late than never, but I should be more protective of my time. I am getting too old too fast, so it isn’t just my business goals I’m worried about.
Waiting so long to use freely available UI elements made my game look amateurish
When I started working on the project, I slapped art together to get something on the screen as quickly as possible.
The main menu’s buttons, for instance, looked like this:
Just colored rectangles. They are functional and easy to create.
I also tried to add a little bit of detail to them to make them better, but it was still very basic:
Between taking screenshots and making videos, I had a lot of footage of the game with these placeholder UI elements.
Which is unfortunate, because the entire point of publishing footage of the game was to get people interested, and I was basically saying, “Here’s this ugly amateur thing for you to not waste your time with.”
It was only recently that I decided to use buttons from the free Kenney UI Pack, and after adjusting some font colors and sizes, the buttons on the screen looked way better.
What’s weird is that I had no problem using existing UI art. I already used icons from Game-icons.net in various places, and I already knew about free assets from Kenney.
So I’m not sure what took me so long to get around to it other than a sense that other things were more important to work on.
Lessons Learned
I should take advantage of good art assets earlier.
I should definitely start my next project with great looking icons and buttons, especially if they are going to be displayed on the screen a lot and they’ll be some of the first things seen in screenshots and videos.
While I still like providing my own art in general, and I don’t think I should fill my game entirely with free sprites and icons, using fantastic, ready-made resources such the Kenney UI Pack makes the game look way better than I could on my own and in a much faster time period. I should really need to justify not using them rather than the other way around.
And if game UI icons and assets make sense to bring in early, what about sound effects and music? I usually leave those until late in the project, and perhaps it makes sense to have placeholder audio at least.
If I want to release more frequently, then I need to make a schedule.
Open ended projects are a luxury I can’t afford.
As I said above, it isn’t as if I couldn’t keep working on my project the way I have been. I know each week I make a little progress, I can inspect and adapt as I go, and one day I’ll work on the last bit of progress and call it done.
But my business strategy ostensibly requires me to release my games much, much more quickly. Until I can increase my capacity to work on my projects, my projects will need to be scoped much, much smaller so that I can get them done in a reasonable time.
I still expect that I’ll need to inspect and adapt, that I can’t possibly anticipate everything, but I’ll have a better idea of what needs to go into a project plan for a small game than a big one.
So simultaneously knowing as much about a project as I can will help me create a realistic schedule, and a schedule with deadlines should help me limit how much a project can be.
With my limited capacity, I need to ruthlessly prioritize the work.
I like to be purposeful, which means that each project I work on isn’t just a random collection of cool-sounding features. When I create a game, I like to identify some core part of it that is the reason it needs to exist now instead of some other project.
For TDUMH, I wanted to make a non-violent dungeon crawler, and what I should have done was figure out exactly what I needed to focus on to make it work. I already mentioned above that not having combat in the game isn’t enough, as I needed some compelling game play to replace it.
If I were to start again today, I think I would realize that I need to prioritize prototypes related to conversation and knowledge-acquisition mechanics as early as I could. Maybe I could have decided then that a party-based RPG would be too big of a project, but what if I applied the same focus on conversation and knowledge-acquisition to a game that consisted of nothing but a small room and two or three people, and maybe a few objects?
I might have been able to put together a game in a much shorter period of time, and I could always use it as a building block for my next project.
Since I instead worked on things that shouldn’t have been prioritized, I still need to figure out compelling game play because right now I just have customizable characters and a dungeon to traverse but not a whole lot else.
Even if I had more capacity, I still would want to prioritize my time much better, if only to make sure that I am releasing games sooner than later.
For the early stages of my next project, I should spend time trying to identify the dependencies between different features and systems. I did a light list for TDUMH, in fact, but it wasn’t something I paid much attention to, and well, here I am wishing I had done more.
I should continue to seek out opportunities to promote my work.
People have asked me why I still try to sell Toytles: Leaf Raking after all these years. Why don’t I just drop it and forget it and move on?
And my main objection to that reasoning is that it isn’t as if lots of people saw the game and thought, “Nah.”
So I try to promote it and sell it because people by and large haven’t had a chance to reject it yet.
Like most indies, obscurity is my main obstacle to success.
For TDUMH, I found that sharing screenshots, posting weekly progress reports, and publishing videos means I am giving more potential fans a chance to find out that my games exist.
Some of those people become fans who start to ask about details, but I don’t know where the next fan will come from. Maybe they’ll find my blog post because someone shared it. Maybe they will be perusing YouTube and the algorithms will manage to place my video in their feed at the right time. Maybe they’ll see one of my screenshots posted on social media.
Most of my time is spent on game development, but it doesn’t take much time at all to capture in-development screenshots that I can then easily use in blog posts, videos, and posts on social media. There’s no excuse to not tell people what I am working on more frequently and in more ways.
Plus, making games with an audience is a bit more motivating than listening to crickets.
It’s easy for me to keep my nose to the grindstone.
Each week, I plan the work for the next sprint, and then each day I succeed more often than not to make steady progress.
On average last year I worked about 7.5 hours per week, and this year I’ve been trying to hit 7 hours per week as well.
As much as I would love to make more time for development, given my life priorities and obligations, this pace is doable for me. I rarely find myself exhausted or burnt out by it.
Maybe that sounds silly, but the hours add up, and each hour I work on my game is an hour I’m not spending time with my family. Until I quit my day job and free up a significant source of hours, this pace is my reality.
That said, I have shown that if I set myself in a direction, I can continue plodding along until I’m finished. I stick with things, and I can keep focused on the same task. These are good things!
The challenge is to make sure I check in on myself to ensure that direction is still a good one and course-correct as needed.
I’m used to focusing on the current sprint’s tasks, then planning the next sprint. I’ll need to start looking at any given sprint as part of a whole, asking myself how far along do I think I am and how much more is there to do. And I’ll need to be honest. If I already have X tasks to do in Y weeks, and I discover an X+1th task, it very likely means I’m working for more than Y weeks if I think it needs to be done. Which means I’ll need to be sure that it is something that “needs” to be done and not just a really appealing nice-to-have.
These frequent project health check-ins should help me lift my nose up from the grindstone periodically, mainly to make sure I’m using the right grindstone.
Conclusion
As excited as I was about The Dungeon Under My House, it ended up being too big of a project for me at this time.
I’m not new to game development. I’ve been creating games for many years. Still, this project reminded me of my limits, and if I am honest, it humbled me a bit.
I do believe that if I kept going the way I had been going, the game would eventually be finished, but it would take me way too long to get there. At least, too long for my overall business goals.
The opportunity cost is too great when I could be releasing smaller games and building an audience during that same time. So as painful as it might be to have to part ways with this project for now (and potentially forever? I hope not), it’s not a hard decision to make.
After 20 months of development, even though I won’t be shipping this project, I am glad I can take stock and glean some insights from it.
I know this analysis will help me greatly with my next project. If I could sum up the lessons, it would be that it isn’t enough to keep moving forward because I also need to ensure the destination isn’t too far away.
I hope this post-mortem helps you, too. Let me know if it did!
Stay curious!
—
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 full color PDFs of the Toytles: Leaf Raking and Toy Factory Fixer Player’s Guides for free!
Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to Toy Factory Fixer and other games for free!
In the weeks leading up to Thanksgiving, I learned that itch.io was going to have another Creator Day sale for Black Friday, so I created a sale to join in.
While all previous itch.io sales had resulted in at least one purchase of my games, the last itch.io sale, the Halloween sale, resulted in 0 sales, which was disappointing but also led me to think that perhaps my promotion efforts have tapped out my friends and family and that I should try something different to reach even more potential customers.
So to avoid repeating that experience, I used the time leading up to the Black Friday sale to figure out a promotion plan with a goal of getting more than my friends and family to visit my game pages and buy a copy.
Since most of my game sales this year have come during a Creator Day sale on itch, it was a no brainer to participate. I get to keep 100% of any sales during the 24 hours of the Creator Day, and the publicity afterwards can result in more sales during the Black Friday weekend.
Skip below if you want to see what went wrong, what went right, and what lessons I think I’ve learned, but I think it helps to know how relevant my situation is to your own first.
Some context
I am a part-time, solo indie game developer, and I am NOT making much of anything in terms of my indie game development business. I am very much dealing with the problem of obscurity, and I am dealing with it very poorly.
I recently put together a spreadsheet with all of my sales data going back to 2011, which includes sales from three separate games across four different sales platforms, and so far my total earnings have been less than $400.
That’s total, not annual.
I’ve been operating my business formally since 2006, and while I’ve had more income from ads and from contract work in the past (but also nowhere near quit-your-day-job money), my game sales have never been where I wanted them to be.
For years, I have set annual goals of making some kind of serious income from my game sales. I’ve tried setting aggressive goals ($100,000/year) and “more realistic goals” ($1,000/year) and tried different kinds of goals ($10/month or 1 sale/week).
My intention was that these goals would push me to figure out how to accomplish them, but I didn’t really have much of a plan for making them happen. They were just aspirations that I could feel bad about getting nowhere near each year.
For 2023, my goal was to make at least one sale per month, which doesn’t sound like much, but for me, it was still something I’ve never accomplished before, and so it fit the bill as a challenging yet achievable goal. Coupled with my decision to make promotion a major priority for my business, and it seemed like a good stepping stone to bigger and better things.
If I can accomplish it, I can build on it. One sale a month can turn into one sale every two or three weeks, which can turn into one sale a week, and then one sale a day, and so on. If I just keep at it, figuring out what works, and continuing to turn the flywheel, I fully expect to be able to improve my results as I improve my efforts.
And I have actually been on track, as between itch, Google Play, and the App Store I had 10 sales so far for the year before the 2023 Black Friday Creator Day sale. It’s less than I would want. I mean, yes, the year isn’t over yet, but I was really hoping that selling one game a month would turn into one of those goals in which suddenly it became very easy to sell more than that. And it has not.
At the same time, I was clearly doing something better than I had in past years. For comparison, I’ve earned more this year from game sales than I have in the last six years combined (partly thanks to itch.io allowing people to pay more than the asking price), and I’ve sold more copies of my games this year than I have in any of the past 11 years. The majority of my sales this year were from itch.io sales.
If I could get one more sale in November, then I just needed one more in December to meet my goal for the year. And if I could get more than one sale, all the better. Meeting and surpassing my goal was something I was hoping would happen anyway.
My Tools and Tactics
My traffic and follower numbers are not great.
In a given week, my blog analytics claims I get around 100 unique visitors. I only have 9 followers for my itch.io developer profile. For my Facebook page I have 96 likes and 106 followers, and I still don’t know why those are two different things. With my Twitter account, a platform I’m using less these days, I have almost 2,000 followers, but who knows how many are active or bots or whatever. My account on Bluesky has only 37 followers, but I feel more confident those people are real. I have only 44 subscribers to my YouTube channel that I created in 2008, but that makes sense as I only really started regularly using it in the last couple of months. And my email newsletter has less than 30 people subscribed to it.
That’s not a very loud megaphone, but it is important to know what I had to work with.
What was I selling?
I have two games currently published on itch.io. My family-friendly leaf-raking business simulation, Toytles: Leaf Raking, has a price of $5.99, and I have never dropped the price for a sale, but itch.io does allow “reverse” sales, so whenever itch.io has a sale, I always increase the price by 50%. My argument is that it is still a very generous price that is less than the cost of a cup of coffee or streaming services, and if you would prefer to pay less, then you should buy it before or after the sale.
Now you might argue that I shouldn’t use a reverse sale, that no one is going to want to pay MORE for a game, but every sale of my game on itch without exception has earned me more than what I asked for even if you count past reverse sales. That is, people pay 50% more and then some each time. It’s very gratifying to know that people have been so supportive in the past. I suspect that as I reach more and more prospective customers, fewer of them will be so generous, but clearly reverse sales exist for a reason.
Plus, I really hate the idea of dropping a game’s price as your main marketing tool. I find it bizarre that Steam, for instance, allows you to wishlist a game, which is someone saying, “I want this, but not right now for whatever reason”, and the immediate notification that comes up is “Ok, we’ll tell you when you can pay less for it.”
I mean, it’s a handy feature to be notified of sales for games you expressed interest in, but it seems like a weird conflation of intent to me. I might wishlist a game just because I want to get it later, but Steam turns a wishlist into a “tell me when this game is on sale” list.
I mean, clearly this tactic of dropping your price to get attention works. I know I notice games when GOG and Humble Bundle send out newsletters saying they are on sale, but maybe I’d notice them more if they were also brought to my attention even without a sale? I’ve learned of some interesting projects from itch.io when I get the new development updates emails.
Anyway, for now, I have no interest in discounting my already pretty inexpensive game.
My other game is the family-friendly toy factory worker management game Toy Factory Fixer. As a part of my Freshly Squeezed Entertainment line of games, it is free. As such, it can’t be put into an official sale on itch.io, but again, the platform does allow for optional extra donations, and I have earned some money from this free game, which I count towards my total sales.
And so part of my promotion efforts was to highlight a “pay what you want” or “name your own price” idea for this free game. I figured that at the very least, people would pay $0, download and play the game, and maybe become a fan, potentially signing up for my newsletter, which is a separate win for me.
My plan involved sending out email newsletters, writing posts on my blog, creating videos on YouTube, posting images, videos, and text on Facebook, Twitter, Bluesky, and LinkedIn (because why not?), and sharing promotion-focused devlogs on my games on itch.io, including the devlog for my not-yet-published game The Dungeon Under My House, the family-friendly 1st person dungeon crawler RPG I’ve been working on this year.
I published posts frequently between the week leading up to the actual sale throughout the weekend and even the day after the sale ended. I was posting multiple times a day during the sale especially.
I even paid to boost a few things on Facebook, although even those ads were free because I was using a $20 ad credit. It wasn’t a lot to spend, but considering my reach is almost never in the double-digits, I figured getting a predicted 1,000-3,000 eyeballs on my promotion efforts would make a night and day difference.
It was the most effort I’ve put into promotion in such a concentrated period of time.
Results
In the end: I got roughly 50 views, 0 sales, and only 1 download of my free game.
So, quite disappointing and frustrating.
On the other hand, according to the few analytics built-in to itch.io, I saw more views for my games than I have ever seen before. As I concentrated my ads on Creator Day, I did see a lull on Sunday, which allowed me to definitely see how my own promotion efforts minus ads impacted my views on the following Monday, and it was still a noticeable spike compared to my normal traffic.
Even so, it felt like a lot of effort for very little gain. It merits some introspection and analysis, and I hope that by digging into what I did and how I did it, my future efforts can be more fruitful, and maybe it can be helpful to you.
What Went Right
Incremental planning allowed me to prioritize and use my time effectively
I built up my plan incrementally. I’m a very, very part-time indie game developer, and I don’t necessarily have a lot of time to work on games, let alone do effective promotion for them.
So the start of my plan was to ensure a sale happened at all and that people knew it existed:
Create the actual itch.io sale
Create a Facebook event linking to the sale
Announce the sale in my newsletter, blog, social media
Having the actual sale created means my game will get listed in itch.io’s sale page, which lots of people will be looking at over the Black Friday sale weekend, so that was done already.
And announcing the sale involved a few pieces: an email newsletter, a blog post, social media posts to share that blog post, and itch.io devlog posts on my three game projects announcing the sale. All of these were written and, if possible, scheduled to go out at the start of the Black Friday sale, which for me was 2:00am on Friday.
Well, announcing the start of the sale was the bare minimum. What else could I do?
Create the actual itch.io sale
Create a Facebook event linking to the sale
Pre-announce the sale the week prior in my newsletter, blog, social media, video
Create new sale logos for the itch.io games
Announce the sale in my newsletter, blog, social media, video
Announce end of Creator Day in my newsletter, blog, social media, video
Announce last day sale in my newsletter, blog, social media, video
Announce end of sale in my newsletter, blog, social media, video
Ok, so we’re starting to put a spine together, and it gave me a good guide for my time and efforts.
I didn’t know how much time I was going to be able to dedicate to writing, creating screenshots and videos, and such, but this plan allowed me to prioritize and drop things as I went.
For instance, all of the “Announce” items included me creating and publishing YouTube videos, but I did not make time to create many of those. I wish I could have, but I was able to write blog posts, share on social media, and do other things, and it just wasn’t possible to do everything on my list.
I had other marketing beats in my plan that I never got to. I created a post explaining Creator Day, but I never wrote one explaining my name-your-own-price idea or how important I think privacy is (my games are designed with privacy in mind and so don’t track any data or sell it to 3rd parties, something I like to emphasize). I wanted to emphasize how the cost of each of my games compares to streaming services, but instead I made a generic post about both of my games.
I even created a Black Friday sales guide, in which I highlighted not only my own games but also other family-friendly games. While it wasn’t as big of a guide as I would have liked (it only featured 5 games instead of the 10 I had intended), I was able to get something together, and I was even willing to making a mere list with links if that was all I had time to do.
My plan was ambitious, at least for my limited time, yet it was flexible and allowed me to drop or change things as I went, and I could even add things as I thought of them, such as some of the short videos I created and shared on Facebook and YouTube that I hadn’t originally planned on.
This flexibility kept things relatively low stress and allowed me to right-size my expectations of my capabilities as I went.
Canva helped me create slick materials.
I’ve heard about Canva in the past, but my sister was the one who suggested I specifically use it to create some of my marketing materials.
It aggressively wants you to sign up for their premium offering, and there is some nice looking stuff available if you do opt to pay for it, but I was impressed with how the free tier allowed me to create simple videos, perfect for Facebook Reels/Stories and YouTube Shorts.
Here’s something that took me 30 minutes using images that I already had, something I was able to upload to Facebook and YouTube and Twitter:
In contrast, when I opted to create something using the tools on my computer, it wasn’t nearly as nice.
Now I was still learning how the website works, so I was a little slower to create things leading up to the sale. I wanted to create a vertical/portrait video but had selected the preset for a landscape view video, and apparently it won’t let you resize the canvas after you start, but I quickly learned to use the Custom Size button and avoid that problem.
Otherwise, I liked how the animation tooling was intuitive, how it allowed you to select colors already present in your image so it was easier to create matching elements, and how you can save multiple pages or each page separately to make variations faster.
I’ll definitely be using this tool in the future. Canva has a referral program, so if you are interested in signing up, doing so through this link supposedly gets us both some credits good for premium photos, illustrations, or icons: Canva referral link. Alternatively, you can use this non-referral link: Canva without a referral link.
I had more views of my itch.io games than ever before!
When I look at my regular, non-sale itch.io analytics, I see very low numbers. On any given day, I get anywhere from 0 to 2 views.
My biggest spikes in traffic this past year have come during sales, which makes sense since I talk about my games more during those periods of time, plus itch.io is also talking about my games (along with everyone else’s).
My best spike was in August for their Creator Day sale, when I got 19 views in one day, with 1 purchase and 4 downloads of my free game. The traffic before and after that day was fairly low, which meant the sale had very little residual effect in the days after.
To me, that was a nice baseline. If I put in some decent effort, can I do even better this time around?
Well, I could. I counted about 50 views in the days of the sale, with 23 views in the first day, 18 views on the next (almost tying the August Creator Day!), and 8 on the last day of the sale.
Now, I think (it is hard to tell based on the referrers in the analytics not being accurate) that much of those views on the first two days can probably be attributed to my Facebook ads (see below), but I did hardly anything on Sunday, and on Monday, the last day of the sale, I did a small blitz on social media, so those 8 views? I’m claiming credit for those.
Now, clearly we’re not talking big numbers here. I would have loved to have had thousands of views, or even hundreds like I had dared hope for, and I will say I was disappointed that I only did slightly better than my August sale, a sale that I didn’t do nearly as much to promote.
Actually, I’d be happy with this number of views if I had more downloads like in past sales. You might notice that it looks like I had 2 downloads on the 25th and 27th, but the first one was me testing out whether downloading a game would ask someone to sign up for an itch.io account and act as a barrier to entry (it does not).
itch.io has a LOT of games, and from what I can tell, horror games and visual novels are way more popular and trending. I do not see many games with specifically family-friendly-oriented messaging, and so maybe customers for those types of games aren’t looking for them on itch, or maybe I need to highlight some other aspect of my games that might generate more interest.
But my efforts made an impact. It may not be much better than nothing, but it wasn’t nothing.
I got more views on my games, however small of an increase, and I did it through my own efforts.
Learning to use better hashtags.
I don’t normally worry about hashtags, but there is definitely a difference between posting something on social media and getting ignored and posting something and seeing it immediately get retweeted or shared because people or bots are paying attention to particular types of conversation.
I try to participate in #ScreenshotSaturday because even though paying customers aren’t likely to be paying attention to it, it is still enjoyable to see what other developers are doing. The itch.io Discord also has a #work-in-progress channel which has a daily call for people to share what they are working on, and it’s great to support each other.
But I knew I needed better hashtags, ones that might be customer-facing. So I went searching for videos on YouTube and Facebook pages to try to find relevant ones.
I don’t know if they helped much (see below about analytics), but #itchio and #indiegame might be attracting more appropriate attention for a sale than #gamedev and #indiegamedev.
And in the case of Facebook Reels and Stories, I tried variations on #familyfriendly and #familygaming, among other hashtags.
I think experimenting here might help me find people who are looking for the kinds of things I’m making more easily.
I created a regular marketing plan.
One thing that stood out to me was that my itch.io traffic is incredibly low most of the time.
For the sale, I can focus on the spike, and I can look at past spikes for comparison, but once the sale is over, I was anticipating things getting back to a normal that I wasn’t happy with.
And as I write this and as you can see in the days following the Black Friday sale, my views have dropped back to the bottom.
My promotion efforts have been fairly spiky, since aside from creating daily posts on my Facebook page and creating a weekly devlog blog post that I also share on social media and on itch.io, I’m not really giving anyone anything to see or talk about most of the time.
So that needs to change, which means I need a plan to do things regularly and consistently.
So it wasn’t really something that helped me with this Black Friday sale, but it was the catalyst for me to actually put together a daily habit of promotion.
My plan is mostly cribbed off of the hour-a-day plan described by Michelle Lega in her 2023 Independent Games Summit talk No-Budget DIY Marketing for Indie Games, adjusting it for my own schedule preferences and my context (I don’t sell on Steam, but I can apply similar advice to my other store pages).
I already write a weekly devlog, but I publish it on Mondays. I haven’t done any kind of press list or reached out to reviewers or streamers, and so no one even knows to cover my games if they wanted to, but I can start my list with one person, knowing that each week I can grow and curate my list as I go. I can make regular time to make small changes to my website and itch.io and mobile app store pages, knowing those changes add up.
My hope is that by practicing regular daily and weekly promotion habits with a focus on content marketing, my regular organic traffic should improve over time. We’ll see how things look a year from now.
What Went Wrong
Quality Issues?
Now, I’ve gotten compliments on the art for Toy Factory Fixer, and fewer on Toytles: Leaf Raking. The latter doesn’t even have music. You could argue that the perceived quality of these games just aren’t competitive, or at the very least that my screenshots and description aren’t compelling enough for people to get curious enough to want to play the games.
And that’s…fine. My games don’t need to appeal to everyone, and there are some gorgeous, cozy-themed games out there that you would never mistake these games for.
But I guess I’m not sure if this is a real issue. There are very, very ugly games that get fans, and that ugliness is sometimes part of the charm. And I’m not talking about very popular games that merely seem like they would be considered “poor quality” when in fact they have very decent production values and are just different.
Sometimes I think about redoing the art of Toytles: Leaf Raking. When I made the game, I knew that I have gotten into trouble spending too much time on previous projects trying to create good art that in the end showed my lack of art skill. So my plan was to throw things together that are functional and move on as fast as I can. I figured that this slapdash art was perhaps going to be part of the charm, and I think some early playtesters found it refreshing in that way and told me so.
But maybe I should revisit the art. Can improving the game’s graphics turn into better-looking screenshots, which would turn into more views, which turns into more purchases?
It’s hard to guess, but maybe I can mock up some screenshots and do an A/B test somehow to see if one gets more interest than the other? It’s something to think about for next year.
Also, these two games aren’t fresh. Maybe it is worth making updates and tweaks to my older games while I also work on my next game, if only to have something else to highlight and talk about? I don’t like the idea of a development treadmill. A finished game can just be finished, right? But I suppose there is always a need for compatibility and I am sure I can find enhancements.
Even adding some music to Toytles: Leaf Raking would be something.
My understanding of the dynamics of Black Friday is waaaay out of date.
Much of my promotion around Black Friday was based on my own personal preference to avoid going out on the day after Thanksgiving.
I did not want anything to do with the crowds or the door-busters or camping outside of a store to get good deals.
So my messaging was built around insisting that you shouldn’t either. Stay home. Play indie games. Specifically, play MY indie games.
Well, it turns out that the days of people filling up stores and trampling each other to get a discount on some consumer electronics aren’t really around anymore.
Black Friday sales start earlier in the month and end later in December. People order things online.
The painful experience I was insisting that people avoid? It just isn’t a reality anymore, and, well, I was out of touch. So I imagine my appeals to get cozy, avoid the crowds, and play indie games weren’t hitting the same notes they would have if I was making such appeals maybe five or 10 years ago.
Ah, well. At least I got this very nice photo of me with my 20+-year-old cat that I tried to stage and it came out perfect.
Facebook’s estimates for boosts aren’t very accurate.
Now, I can admit that I am new to Facebook ads, and so there is a lot I could stand to learn in terms of using them effectively (see below).
I’ve generally avoided paying for traffic because I don’t know if my website does a good job of converting that traffic into sales. Why pay for people to bounce off your sales page when you can improve the sales page with organic traffic for free?
Except I have terrible organic traffic, so maybe I need to pay for traffic to find out how my sales pages do when there IS an influx of potential customers?
Well, I’d love to run experiments like that in the future, but for now what I did was boost my Facebook event for the sale.
Facebook estimated that by boosting my event with just $5, I could see a reach of about 1.3k to 3.7k accounts.
That’s WAY better than the handful of accounts my posts normally reach. This Black Friday sale was going to be a very nice experiment.
Except, the actual reach of this event was way, way less. It only reached 100 people by the end of Creator Day. And to make it worse, no one actually joined or express interest in the event.
Maybe I shouldn’t have expected the traffic to my Facebook event to do anything meaningful. Maybe my boost money should have gone to a better post.
But I was a bit frustrated that I paid (well, with free credits) for an ad with an expected amount of reach and got way less, and on top of it, Facebook kept trying to upsell me to spend more. “We didn’t show it to the number of people we said we would, but if you pay us more, we promise we’ll do it this time.”
It isn’t even that I spent a free $5, which isn’t much and so I shouldn’t expect much in results from it. It is that there was an opportunity cost here, and I wish I had spent that $5 on a different post with perhaps a better outcome. Or maybe on Google AdWords. I would have gotten more value if I had just bought someone else’s game during the sale.
I think with my current low traffic I am going to need to expect that I’ll pay for ads in the future, but I wish I knew how to predict whether or not Facebook was going to actually show my ads to the people they said they would.
I don’t have a good idea of who to target when I create posts and ads.
When I noticed that the boosted event’s reach was growing way slower than I was led to believe, I decided to use the rest of my ad credit on boosting a different post, which was a Facebook Reel version of this short video that showed off Toy Factory Fixer’s game play:
When you create an ad, Facebook lets you target people by geography, age, other demographic info, and interests.
My games were meant to appeal to people who want family-friendly media. If you watch family-friendly movies or TV shows, you probably also want family-friendly games.
People interested in creativity, in educational toys, and educational video games are also people likely to want to play my games.
So I targeted Americans (Thanksgiving and Black Friday aren’t really international) who are interested in the above, and it seemed like a good bet.
Now, perhaps boosting a video wasn’t the right move, or maybe the video that showed game play footage of Toy Factory Fixer wasn’t compelling enough. Maybe the video was too short, and even though it got played almost 2,000 times, there were only two clicks, and I don’t know if that is a good percentage or a low one. Maybe people clicking on ads get thrown off when the link takes them out of Facebook and so they bounce away quickly. Maybe there is some advanced setting for ads that would have optimized who saw it.
But the fundamental problem is that I don’t know what would be compelling to my target audience because my target audience is quite broad and vaguely defined at the moment. For an ideal customer of my games, what would they be looking for, or what would pique their interest?
I don’t know, and I should. As a solo indie game developer, I can’t depend on spending huge amounts of money on blasting ads at people in the hopes that some of them become paying customers. I need to figure out who they are first.
For me, I want to make games that are family-friendly, that are privacy-respecting, and that encourage curiosity and support creativity. What I haven’t done yet is the hard work of finding prospective customers who care about those things, too. Who are they? What else are they into?
Without that info, I’m shouting into the wind.
itch.io’s analytics are a bit opaque and limited.
Remember how I said I paid for Facebook views? I KNOW some of those turned into itch.io game page views.
But you wouldn’t know it looking at itch.io’s analytics. Facebook does not show up anywhere in the listing. Neither does Twitter, YouTube, or a few other places that I know should have shown up in the metrics.
Here’s itch.io claiming credit for all 6 views of Toytles: Leaf Raking on the 25th, a game which got 9 views that day according to a different view:
itch.io’s analytics also don’t really let me see things I want to see. I can see “Incoming visits from other sites over the last 30 days” and see what referrers I have (which, again, is clearly not an accurate picture), and I can see the “Graph by day…” option for a particular game’s traffic for the previous month, but it would be nice if I could see referrer data from arbitrary time periods.
Can I see who were the main referrers for my August Creator Day traffic? Not anymore. At least, not that I can find. If I wrote this post weeks from now, I wouldn’t be able to tell you what referrers I had during this Black Friday sale either.
I know itch.io allows Google Analytics to be embedded, but I don’t know if I’ll see better quality data or if it will similarly be filtered or missing data from referrers that I expect to be there. I suppose I can add it and find out.
I’m glad that I can view some data, but I’d be happy if I could export the data and look at it myself if that was the only thing available.
As it is, I feel like I’ve got to make decisions on where to spend my time and energy based an incomplete picture of what my previous time and energy investment produced.
What I’d also love to know is how many people clicked on the download button for my free game and abandoned once the modal popped up asking if they wanted to donate $2. Imagine the A/B test I could do to see if that modal was getting in the way of downloads. The money would be nice, but I’d rather people play Toy Factory Fixer than not. I’ve submitted the idea in the Discord’s #meta channel.
Lessons Learned
Since I only learned about the Black Friday sale on November 15th (is there an itch.io calendar of such sales so I can prepare better for them?), and I didn’t have much of a playbook for operating such a sale, I needed to create one.
I had a few late nights and lost some sleep that took me time to recover from, but I created a plan, and I executed it as best I could with the resources I had. So maybe that’s another What Went Well to add to the list: I created a Sales Promotion Plan that I can build off of for next time.
Even though I didn’t see any purchases and only one download as a result, I think my plan still seemed pretty sound: using all of the channels I had available, make sure people were aware of my games, finding any way to talk about them.
You could argue that maybe I should be on more platforms, like TikTok or whatever, but I didn’t want to spread myself too thin, and I was hoping I could leverage my existing accounts better before worrying about being elsewhere.
I think my main lessons boiled down to:
I have a small megaphone, so putting in a significant amount of my limited time for promotion efforts results in a noticeable yet still small impact.
What would my views/sales/downloads have looked like if I had 10x as many followers on Facebook? 10x as many YouTube subscribers? How much more leverage would each of my posts have had?
I’m no content creator. I blog about my game development, and recently I started creating YouTube companion devlog videos, but I’m not going to try to be some zany personality with clickbait-y thumbnails and headlines. My videos aren’t high quality, as I’m currently using my laptop’s camera and a mic that picks up way too much ambient noise, but I hope by being authentic that I appeal to the kind of people who also aren’t fans of clickbait. But obviously YouTube isn’t going to be showing my videos as often.
This past year I started to post regularly on my Facebook page, but I only recently learned about the Meta Widely Viewed Content Report, and based on one analysis I read, I’ve been limiting my potential because I was adding links to my blog posts or mailing list sign up page or a store page to each Facebook post, and Facebook basically limits how far posts with links go dramatically compared to non-links. So I’m going to try to limit how often I add a link to a post and see if Facebook shares my content more often.
It’s a chicken and egg problem in which the social media algorithms won’t show your posts if they aren’t gaining traction, but they can’t gain traction if the algorithms won’t show your posts. But they’ll gladly take your money to maybe show your posts to more people. It’s a winning combination for them, and a very annoying problem for me. But hopefully not an insurmountable one.
Years ago, blogging regularly meant you were continually building a backlog of articles and posts for people to find. Today, a lot more people are in walled gardens of social media that focus on what is new and trending, and so more often I find that my articles effectively might as well not exist to most people.
But SEO is still a thing, even if it might not be as big as before. People still search for things. I plan to make my things more likely to be what they are looking for.
In the end, I really need to focus on what kind of megaphone I want and how to build it up.
Before paying for someone’s much larger megaphone, I need to better define my target audience more and nail down my messaging better.
Otherwise, I can get a lot of eyeballs on my games but none interested in actually playing them.
I can talk about making family-friendly games, but if hardly anyone is looking for “family-friendly games” and instead are looking for “family gaming” or “kid games” or “preteen games”, then I should find that out, and then I should tailor my marketing messages accordingly.
This is basic keyword research, content marketing kind of stuff, but in my limited time, it hasn’t been a priority, and in a year in which I have relatively kicked butt in terms of how much better I have done compared to previous years, I can clearly see the lack of results from not doing this kind of market research sooner.
But if yesterday was the best time to do it, today is the next best time.
I suppose that’s something I need to remind myself of. This sale was a bust for me, just like the Halloween sale, but there will be more opportunities to participate in sales. I will make more games. I can feel bad about the result of this one, but there will be another chance to do better soon enough, another chance to share the games I make with the world.
And I can always acknowledge that one person did, in fact, download my free game. That’s fantastic. I hope they played it and enjoyed it. In the grand scheme of things, I make these games for other people to enjoy, and that’s one more opportunity for someone to do so.
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.
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.
Ha.
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
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).
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.
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.
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.
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.
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.
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.
WHAT?!
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.
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:
And here’s what it looked like in September:
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Summary
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 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!
Ludum Dare #33 is months old, and the next Ludum Dare is about to begin. It’s about time I wrote a post-mortem about the game I submitted.
The theme was “You Are the Monster”, which, as usual, caused a lot of panic among the participants who worried that it was impossible to make a game based on that theme in two days. And once again, despite such worries, there were almost 2,000 entries submitted, so people found a way to do it.
I ended up making a fairly compelling, somewhat humorous, non-violent strategy game about being an imprisoned evil using its influence to escape. I called it Free Me, You Idiots!
What Went Right
Quantity Over Quality: Fleshing Out Concepts and Designs Early
It’s easy to want to get started right away. You only have 48 hours, and every second counts. But I also knew from experience that it helps to spit out as many concepts as possible early on, then pick the one that seems most promising. You are more likely to have a good idea picking the best of a thousand ideas versus the best of ten ideas.
So I spent the first couple of hours thinking, doodling, and discussing with people on IRC.
The theme had a lot of obvious and not-so-obvious applications. The obvious choice is to harvest ideas from classic movie monsters, such as vampires, werewolves, and ghosts. It’s direct, and you could have monsters who are genuinely scary or you could have them be misunderstood by the populace.
The next-most-obvious choice is to think about metaphorical monsters, such as people who have the most evil and disturbing thoughts. It could be a psychological thriller in game form.
I thought about characters, origin stories, and settings, and I had a lot of fun thinking up ideas as varied as space aliens and beings frozen in the Arctic for centuries.
I went with the idea of the incarnation of evil imprisoned in a tree for centuries. With no previous story, I was free to write my own with no preconceptions.
I fell in love with the idea, which really helped me drive the development of the game. If I hadn’t spent time upfront thinking, I might have settled for a merely OK idea, and I might not have found myself as passionate to work on it.
I spent quite a bit of time thinking about this concept. I threw out a lot of ideas early on and managed to find the core of the game. I had originally thought about having a bunch of stones surrounding the tree that you were imprisoned in that had to be removed by the nearby villagers under your influence. I mocked them up and played with the idea for awhile.
The idea was that rock-gathering was an activity for the villagers, and the villagers would grab these forbidden rocks.
I’m glad I threw it out because I ended up having entities that did hardly anything but explore and pray. I would have run out of time without a way to remove those rocks and finish the game.
I think if I had more than two days that those rocks would still be in the game and the entities would be mining, chopping down trees, and more, but because I had a wealth of ideas to choose from, discarding some didn’t feel like I was gutting the game of its essence.
Iterate Like You Mean It
In the previous Ludum Dare, I spent a lot of my time on animations and art, but not much at all on game play. By the end of that compo, which had a theme of “An Unconventional Weapon”, I had a monster that could chase around the player when you got his attention either by shouting at him or by crossing his line of sight. I wanted the monster’s head to turn separately from the body, and there was going to be this idea that the monster can trip over itself when it is moving in the opposite direction that it was looking. I spent a too much time creating the complex animation system when I could probably have gotten away with something simpler, and as a result, what I submitted wasn’t anywhere near a finished game.
I didn’t want to make that mistake again in Ludum Dare #33. Even so, I didn’t start writing code until the compo was well underway. While I was worried that I wasn’t going to make everything I wanted by the deadline, my approach meant I was always going to have something to submit.
My first focus was on interactivity. If the player can do something, I can build upon it, even if I have to cut most features or change the direction of the game design completely.
It meant I was also playing the game frequently. I would make a change and immediately see how it felt. I can identify things that may be buggy or hard to understand, and I can fix them immediately or prioritize them.
For instance, when clicking on an entity in the game, an arrow appears over them. This was a simple bit of polish that I thought seemed important enough to add early on. With a bunch of entities moving about, this arrow meant it was easy to identify which entity you were looking at.
But moving around the world was a bit jarring. You click, and the camera centers to that location. I knew I wanted to add interpolation to smooth the camera’s movement, but I also knew that what I had was passable and could be fixed if I had time for polish later. So the working yet jarring camera movement stayed throughout the rest of the game’s development.
What was exciting was that by making small yet meaningful changes, it allowed me to add a relatively complex economy without much effort.
The game features a few variables that are interdependent and make it feel quite rich to explore. For instance, the player has Evil Energy to use to influence villagers. Evil Energy replenishes one point every second.
The number of followers influences the amount of maximum Evil Energy a player has. More followers meant more maximum Evil Energy, which opened up options for the player.
When you have followers, they will pray to you. When the total amount of prayer time exceeds 10 seconds, the player gets an extra point in Prayer Energy, which can be spent on upgrades and ultimately on the ESCAPE option, which ends the game in victory.
I originally didn’t intend to add so much because I was worried about spending too much time on balancing all these variables, but without all of these different values and their interactions with each other, the game felt very simplistic.
I’ll admit feeling worried that I might find that the whole thing was unworkable and would result in nothing but wasted time. Learning about and playing with game economies from the book Game Mechanics: Advanced Game Design by Ernest Adams and Joris Dormans gave me some confidence I could pull it off by adding pieces of it throughout development and building upon them iteratively. Each addition was relatively risk free and easy to fiddle with.
I was very pleased with the results, and so were the people who played the game. I was surprised by how many actually played it all the way to completion!
A Goal for Being Cool
I realized that back in pre-20 Ludum Dare compos, it was easy for me to play almost everyone’s games because there was less than 100 entries. There would be a burst of game development activity for a weekend, and then maybe a week of playing and rating games, and then going back to regular life. Plus, back then you didn’t need to rate games to get your game rated.
Today, with thousands of entries, it takes much more of a commitment. Your game won’t show up in the random sampling for entrants to rate if you don’t also rate other games. It’s a fair system.
After the compo, I was on vacation from the day job and so I spent the next few weeks playing games. I set myself a Coolness goal. I figured that if I played a handful of games a day consistently for the next couple of weeks, I would be able to hit it.
And when I rate games, I like to give feedback to the developer. I don’t just post “Nice!” or leave no comment at all, so I wasn’t going to allow myself to speed through reviews in order to quickly increase my Coolness. I was going to play games, give them a fair shot, and give an honest review with constructive feedback.
I only got 63% Coolness, but it was enough to earn me a bronze medal. I don’t understand how that percentage is calculated. I know I didn’t rate anywhere near 63% of the nearly 1,199 games submitted, yet it seems like I could have hit 100% with only a few more handfuls of rated games if my math was correct.
But I know that if I hadn’t set a Coolness goal, I would have either made the mistake of not rating enough games, resulting in my own game not getting rated by many participants as in past recent compos, or I would have spent a lot of my waking hours doing nothing but playing LD games, ignoring my other responsibilities. I think I had the balance mostly right.
What Went Wrong
No Polish and No Sound Effects Again
In an effort to speed development along, I did the opposite of what I did in the previous Ludum Dare compo and ignored animation and polish as much as I could. It wouldn’t matter how cool something looked if the player had nothing interesting to do.
As a result, the game lacks life. The entities move around without turning or animating, and there is no indication when a player successfully influences someone. The grass tiles had markings which were too subtle and resulted in a sea of green that made it difficult to tell if the player was actually moving the camera.
Now, it wasn’t completely bad. The prayer bubbles added a nice touch, as did the Evil Energy ball in the HUD scaling quickly when it replenishes. The flavor text had some humor and lore.
But no sounds, no animations, and no special effects left the game feeling like a lot was missing.
Buggy Engine Code
There were a few problems with the custom engine I was using. One was something I saw in the last Ludum Dare in which tiles would seem to separate as you moved the camera around. It turned out to be a floating point error that resulted in me accidentally scaling the tiles so they would sometimes be one pixel smaller in width and/or height. I must not have pulled in the fix when I was putting the project together, so I easily fixed it, but it still took me some time to figure out what exactly I was missing.
Early on I noticed that entities seemed to walk over the tree. They should look like they are in front of the tree when standing in front of it and behind the tree when they were behind it.
So why were they always appearing on top of the tree no matter where they were?
I recently ported my code from libSDL to libSDL2, and sprite rendering was done differently to accommodate scaling and rotation. Unfortunately, I introduced a Z-ordering bug which, after spending time on figuring out what was going on, I decided to ignore for this compo rather than spend more time trying to fix it.
The risks of using your own code instead of a ready-to-go engine such as Unity or Game Maker is that infrastructure bugs like this are not only likely but also might be something you feel inclined to fix immediately. If Unity had a bug, I’d work around it because I’d have no other choice. If my own code has a bug, I’d feel like I could fix it while working on my game and might underestimate the effort it would take to do so.
So while it wasn’t fatal, I had buggy infrastructure code that slowed me down and prevented me from making a better game.
Missing: Some Features and Any Challenge
One of the upgrades in the game is CAUSE FEAR. Do you know what it does?
If you guessed it caused the villagers to be afraid, you would be wrong.
It does nothing. Why?
Because I never got around to it. I had ideas for what CAUSE FEAR would do, but since so much of the game didn’t get made, such as the mining and wood cutting I mentioned earlier, there was no real reason to cause villagers to be afraid. Maybe it would make them pray harder for a bit, and so CAUSE FEAR was similar to trading Evil Energy for Prayer Energy but in an indirect way.
I had a few ideas, but none of them got implemented. Unfortunately, I left the option in even though it did nothing. Whoops. B-(
Similarly, because there was no real conflict in the game, there was no challenge. There is nothing in the game that prevents you from converting every villager, getting all of the energies you need, and winning the game.
I wanted the good villagers to try to convert back your followers. I wanted different kinds of villagers, such as priests and acolytes, and have their presence force you to change your tactics. Perhaps if your followers got numerous enough, the other villagers would go to war with them.
Something. Anything.
But instead, there’s nothing. There’s enough economy and variety that it seems to hide this lack of conflict, but without conflict, I can’t really say I have a complete game.
What I Learned
A Design Document Is Key
Throughout the compo, I set myself goals. I set an initial goal of settling on a concept within two hours. I set a goal of having interactivity early on instead of waiting until the end. I set a goal for rating games after the compo.
Each goal gave me some control over the outcome. I was able to focus on what was needed and ignore what wasn’t. While the lack of polish hurt, it wouldn’t have hurt nearly as much as having a fairly incomplete experience.
What really helped in setting goals was having a design document for the project. Now, I’m not talking about a 300 page document that no one reads. I’m talking about a living document that changed throughout the 48 hours I used it to help guide me.
Everything I thought of went into that document, which allowed me to assess what was a priority and what was nice to have and what didn’t need to be there at all.
I could see what was left and compare it to how much time I had left, and I could make intelligent decisions about feature cuts and what had to be there no matter what.
I credit Hybrid Mind’s Ludum Dare #29 timelapse for In the Black for showing me how effective a design document can be for even a short 48-hour project. Thanks, Dave!
A Game’s Economy Can Have a Big Impact on the Game’s Appeal
I was glad I decided to risk adding more to the economy of the game. Evil Energy and Prayer Energy play off each other in an intuitive way, which makes the game more compelling.
I think people kept playing because throughout the game there was always something to aim for. Converting a follower resulted in an upgrade being made available, which required Prayer Energy to attain, which in turn allowed more followers to be converted more easily, all with the aim of using ESCAPE to end the game.
I could have had a simpler economy. If I eliminated Prayer Energy and made things more directly available, it could have worked, but it might have felt too simplistic.
What I’m not happy about is that the richer economy hides a lack of challenge. I don’t want to use economic designs to act as a bandage on a fundamentally broken game.
But I did learn that doing a decent job designing an economy can result in a great return on investment.
Keep Your Nose to the Grindstone
During the 48 hours of Ludum Dare #33, I slept, I ate, I showered, I talked with my wife, and I blogged.
But most of my time during the 48 hours was spent on design and implementation.
According to my records, I did a little over 24 hours of game development between Friday and Sunday. Just over half of the time spent on the compo was spent doing actual game development, and I’m pretty sure that because I lived and breathed this project, I was even making progress while showering or eating.
Even with the failings I mentioned, I can see that this laser focus was the real reason why I was able to get a decent game finished.
I’ve done compos in which I was distracted, and they didn’t always end well. Either I was dealing with poor health, in which I couldn’t sit at my desk for long periods of time, or I was going to a party or a soccer match.
For this Ludum Dare, I made sure that I was 100% focused on the compo with no outside commitments to keep me from doing anything but game development that weekend.
It was grueling and exhausting, but that concentrated effort made things move along so much more quickly than if I had spread out the development effort with frequent and potentially long breaks.
I’m not saying breaks are bad. I took breaks.
I am merely saying that my mind was focused on game development and not on how to interact with other human beings in a social situation or how frustrating it is when your team is losing due to the same blunders they always make.
I rested when I needed to rest, but I didn’t allow myself to procrastinate or do much of anything other than participate in this compo.
Summary
The results of this compo were very encouraging to me:
Out of 1,199 entries, my game was rated in the top 36% overall and top 8% in innovation. My only rating that was in the bottom half of the group was for graphics, and even then it was at the top of the bottom half. B-)
I credit my ability to focus that weekend on game development almost exclusively, and all of the tools that allowed me to leverage that focus, such as my design document and setting milestones.
The main complaint from players is that there was a lack of music and sound, followed by the noticed lack of challenge. For future compos, I’ll want to focus on not only interactivity but also adding real conflict.
I may want to experiment with adding audio iteratively. Normally I add it at the end, and an informal survey indicated that a lot of other game developers add it at the end as well. I wouldn’t want to spend time on something that might get thrown out before the end.
Still, the idea is that if I can have a playable game early on in a compo, I can also have a playable game with audio early on in a compo, too.
October 31st came and went, and Stop That Hero! was not in a position to be sold, even as a beta or alpha project. Partway through the month I realized that even if I was able to finish the project, the work of setting up the payment systems, customer support, and even the website was going to take some time as well. According to my estimates, I’d finish the game sometime between the end of October and the beginning of December. As disappointing as it would be not to finish in time for the October Challenge deadline, I also knew that it was a “fun” deadline as opposed to a hard “must-hit-this date” for my business.
I will continue to work on Stop That Hero! because I believe in the project, but I’d also like to get better at project management. Now that the deadline has passed, I can look back on the month and think critically about how I did. Even though there was no business-related urgency in getting the game finished for the Ludum Dare challenge, I still wanted to do so, and it was demoralizing to realize that the game wasn’t going to be finished in time.
For the unfamiliar reader, Stop That Hero! was originally created for the Ludum Dare 18 Jam. The player was an evil villain in charge of a castle and a number of towers, and a hero character was trying to conquer the castle, liberating towers and collecting treasure chests along the way. The player would create minions at any of the towers, and those minions would try to kill the hero. Kill the hero three times, and you win. Lose the castle, and you lose the game.
For this project, I wanted to make Stop That Hero! a commercial-quality game that required no proprietary dependencies and ran on at least GNU/Linux (my preferred platform) and Windows, with plans for a Mac OS X port and an eye toward mobile devices. I wanted the game to be data-driven instead of hard-coded. I wanted the game to have multiple game modes and levels, and I wanted me and the players to have the ability to create our own custom levels with custom rules. I realized that it was a lot to do for a first release, so my intention was to make the game hard-coded yet easy to change so that it was using external data and scripts. Future updates would involve replacing the hard-coded bits with loadable data.
What Went Right
While it might seem strange to think that anything went right for a project that wasn’t finished, I do believe there were some good things that positively impacted the project.
Planning and Preproduction Time. Even before the October Challenge was announced, I knew I wanted to take Stop That Hero! and make a full game out of it. I spent a few weeks at the end of September looking at every aspect of the game, from resource handling to monster variety to game modes.
While I think the original LD18 game’s mechanics were marred by a lack of game balance and probably could stand on their own, I wanted to investigate every possibility for making this game the best it could be. I identified major design challenges that I wanted to focus on early on. I also speculated on how much of the game could be data-driven or scriptable. This early planning helped me visualize how I wanted the finished game to look and feel.
A Regular Work Schedule. As an indie game developer, I have no boss imposing a schedule on me. Keeping my job doesn’t require my presence during official office hours anymore. Since I determine my own schedule, I can do whatever I want, whenever I want. It’s not a license to slack off and take vacations every week, of course. My income depends on the output of my efforts.
The thing is, my time usage wasn’t very productive or balanced, and it hasn’t been for months. If I spent time on game development, I’d find that my writing would slip. If I wrote, I’d find that magazines and books would pile up in my inbox. If I read, I’d realize that I almost missed paying an important bill. Coinciding with the time I started preproduction for this project, I realized that I needed to do something to change my situation. To make my productivity a bit more predictable, I created a regular set of hours for myself. Until I had a game to sell, I wasn’t going to make any money, so production took up the lion’s share of the time I spent in a day. To ensure that there was balance between game development and everything else I wanted to get done, I gave myself regular hours for writing, reading, and organization. I use Google Calendar to setup recurring events. You can see an example of my day below:
I discovered I wasn’t very good about waking up early enough for the morning stretches part, which is something I want to work on next month, but I tried to stick to the schedule. If I missed stretches, I wasn’t making it up at the expense of being late for game development. If I was late for game development, I wasn’t going to encroach on writing time. If I did make such allowances, it would destroy the whole point. For the most part I stuck to the schedule, which meant I was doing about 4-5 hours of game development per day, an hour of writing per day, an hour of business or game development reading per day, and an hour of organization per day. While part of me wondered if I needed more time dedicated to game development, the balance allowed me the time I wanted to learn, share, and prevent things from slipping through the cracks. While I might tweak the hours going forward, I definitely prefer this self-imposed, organized, and regular schedule over letting each day’s activities be determined by whim.
Agile Scheduling As Early Warning System. Once again, I’m pleased with the knowledge I learned from using nothing more than a couple of cork boards, some index cards, and pins. Before the project started in earnest, I created an estimate of the work I needed to do as well as an estimate of how much I thought I could do per week. As the weeks passed, I realized how poorly I was doing in terms of keeping with the schedule.
I wrote about it in Agile Alert: Slow Project Progress as well as Balancing Current and Future Needs, but the point was that without using story cards and a burndown chart, I wouldn’t have any idea when this project would be finished or what I could do to improve my situation. It allowed me to make project decisions earlier rather than later as well as weighing the advantages and disadvantages of delivering the finished project later.
What Went Wrong
Not Planning Time For Art and Sound Work. The Jam version of the game features all art and sound created by me. I’m not that great of an artist, and I’m no sound designer. If this game is going to be polished, I was going to need to hire someone else to do the work. Of course, until I needed the higher quality assets, I could use my current art/sound assets as placeholders.
The thing is, I never really had a plan for how I was going to go about finding contractors to provide the replacements. For a project that was originally expected to be sold by the end of the month, I should have had a plan in place for getting all of the final polish in. It would have been hard to ask for finished art when the game itself was nowhere near playable, so it isn’t a total negative, but I could have started a search for artists and composers. At the very least, I could have looked into pre-made art and sound packages. Otherwise, I would be spending a lot of time learning how to create half-way decent art and settling for lame sound effects and no music.
Underestimating the Complexity of the Software Architecture Hacking a game together in a weekend is relatively easy because the code is prototype-quality. It’s meant to be used for a few days, and you don’t need to worry about maintenance or future updates. The future is mere minutes later, and then it is over. For the October Challenge, I wasn’t interested in a single sale. I was interested in the health of my business. When there is one sale, I expect more to come later, and so I wanted to make high-quality software that is easy to provide support for.
Unfortunately, I didn’t realize until late in the month how little experience I have with creating a full-fledged project from scratch. When all of the code is in a single, monolithic file with almost no external data driving it, it takes no work to determine what data structures should live where. When you’re working on software with flexibility and maintenance in mind, it’s a completely different mindset. Since I didn’t have much in the way of reusable code that was of the quality I desired, I was spending a lot more time working on infrastructure and scaffolding than I expected. I could write an individual piece of code well enough, but I had very little experience with knowing what individual pieces of code I needed to write in the first place.
Also, with unit testing, the code that “works” would only work in tests, whereas the actual game still needed a number of other parts of the project finished before I could see anything that looked like progress on the screen. It’s good to see the green bar as often as I do, but it’s frustrating that the actual game doesn’t do anything more than it did the week before. I now understand what the stakeholders felt like at my last day job whenever I would say “Yes, I’m making great progress. No, there’s nothing new for you to see yet.” Sometimes you just need to throw something, anything, up on the screen every once in awhile.
Not Being Decisive About What Game I Was Making. Since I wanted the game to be data-driven and scriptable, I thought that the major design work would take place with malleable data rather than rigid code. I wanted multiple game modes, and I had an idea of what each one might include. I thought that there could be single level instances as well as campaigns of levels that tie together somehow. I wanted victory and defeat conditions to be scriptable, but I also wanted some core mechanics to be as well. For instance, while the basic game might provide all of the towers up front for the player with no way to retake a tower that the hero has liberated, a different level configuration could require the player to conquer independent towers first and provide the ability to retake them if they are liberated.
The problem with the game designer’s “I want it all” approach is that it put a lot of pressure on the programmer to make the software incredibly flexible. Since the designer and the programmer positions are both filled by me, it meant that I was asking a lot of myself. I knew better than to make a game engine that could be any genre, any game, but I didn’t realize that making a Stop That Hero! engine that essentially allowed for endless variety of game modes and mechanics wasn’t any less difficult. While the previous sentence sounds like it should have been self-evident, I didn’t have 20/20 hindsight to help me write it back when this project started. It seemed to be so simple. So long as the game was driven by data and scripts, I could make any mode I wanted.
At the beginning of the project, I had supposedly made a decision to implement a particular game mode as part of the version 1.0 of the game, but I didn’t want to give up on the flexibility to do any of the others I had thought of. If I really wanted to hit the end of the month deadline, I probably could have pared down the feature requirements list. Flexibility can be retroactively coded in after 1.0 was released. Instead, I gave myself the impossible task of getting everything done and hoping it could be done in time without regard to how long it would take. It’s no wonder the schedule slipped.
Getting Into a Developer Funk. Towards the end of the month, I hit a point where I could not make forward progress no matter how much I wanted to do so. I was second-guessing myself, partly because I probably felt overwhelmed with the architecture work, and partly because I made the mistake of doing research and development on the state of the art for component-based game objects. Basically, I wanted a component-based game object system since it would help me in my quest for a flexible and data-driven game, but I learned a number of competing ideas, and I found that any new code I wanted to write had all of these new mental filters in the way. Data-driven Programming vs Object-oriented Programming, game objects vs game entities, encapsulation vs getting things done, etc. It was a lot to take in, and I had difficulty getting all of the new information to settle down in my head.
When I finally abandoned my attempt at the component-based system, I still couldn’t make progress on a less flexible entity system. How hard can this be? I did a working version in the original Jam version of the game, right? Well, once again, I wasn’t throwing all variables and data structures in the same class anymore. I couldn’t make decisions because I was paralyzed with the fear that I would make a poor one.
I experienced a smaller version of this when I was getting into unit testing for the first time. For instance, I’m not used to the need for as much Dependency Injection as I did on test-driven work, and I was losing confidence that I was doing software development “right”. Early in a project, you might think of one reference to an interface that an object needs, so you provide that reference in the constructor of the object. Weeks later, and you might have 4, 5, or 6 such references as parameters, and suddenly you’re faced with the need for another one. At this point, it starts to feel wrong, especially since it can hard to keep it all straight in my head. Since I was working alone, I didn’t feel I had anyone to discuss it with, so I would have to move forward reluctantly. Eventually, the fear that I was doing something wrong paralyzed me.
I did eventually get out of my funk and started making forward progress again, but it was only after a long phone conversation with a more software architecture-knowledgeable friend. Thanks, Larry! When you think you’re lost, sometimes all you need is some guidance and advice.
What I Learned
How Much Technology I Needed and Didn’t Have. If I didn’t care about making my game available for GNU/Linux or avoiding proprietary solutions, I could probably have used technology such as GameMaker, Unity, or Flash to make a game. They offer plenty of game development-specific support, either directly or through libraries. Instead, I had to do a lot of work myself. While libSDL provided a number of basic hardware abstraction services, I still needed to write a lot more game-specific code.
Again, I understood I wasn’t writing an end-all, be-all game engine, but I still lacked a repertoire of code to help me make the game. A lot of my time was spent laying down the basic infrastructure to allow me to work on the game. It’s odd since I can easily hack together a working game in a weekend, but when the project’s seriousness demands more, I found that I lacked the basics. While I knew what tools I would use at a fundamental level, such as which compilers and libraries I would use, I didn’t realize I needed to figure out what technology I needed to create. If I did, I probably would have planned for it in the schedule or I would have pursued a simpler project in the first place. For instance, while I knew I needed AI pathfinding, it didn’t occur to me that I’d need something more sophisticated to track all of the objects in my game than a bunch of independent collections of data.
How Much I Still Need to Learn Between software architecture and the basics of game engine requirements, I hit a number of stumbling blocks that forced me to pull books off of shelves and search online for answers. I would have thought I knew enough about game development to make a game, but I had underestimated how much more work there was to take an otherwise working game that was hacked together and writing the code in a way that made it easier to debug, fix, and change.
Working with others would help us all glean knowledge from each other, but as an indie, I’m going to need to interact with game developers in more than a social way. Also, I need to get better at project estimations. I was too optimistic this time around.
How Difficult It Is To Talk About Game Development When It Is Not a Hack Fest. Most of the people I talked to on IRC were helpful when it came to particular aspects of what I was doing, but they almost all seemed to perceive that I was hampering my efforts with the use of unit tests and the desire for high code quality. “Just finish the game” is easy to say when you’re working on an LD48 competition entry for fun, but when your business depends partly on the ability to provide customer support without introducing bugs and problems, it’s not just fun and games anymore.
Selling a copy would have been nice at the end of the month, but I also want the ability to sell more copies later. Selling a hard-to-support game isn’t a good way to improve my ability to stay an indie long term. The October Challenge wasn’t an end in itself for me. I saw it as a kick in the pants to get me focused on moving my business forward. By and large, it worked. I have a project that is still moving forward even if it is at a slower rate than I would like. Still, it was difficult at times to talk about game development as a business-related endeavor since not everyone had the same long-term goals.
As I said, I am continuing this project even though the October Challenge is over. Using the project data so far and assuming I continue to work at the same rate, I can expect to finish the game by December. It’s still just an estimate, but it is a much better informed one than the one I made at the beginning of the project. While it is disappointing that I couldn’t finish this project in the month, I am pleased with some things. My schedule helped me make consistent progress, and I have a much better understanding of the game’s design questions since I spent so much time thinking about them before the month started. Still, while I had done a simple technical feasibility assessment, I needed to do a deeper study to realize all of the things I needed for this project. Basically, as much as I tried to plan ahead, there were some things that just weren’t on my radar. I know better now. Besides having done a lot of work for this project that can be reused, future projects should benefit from pursuing a better understanding of their technology requirements.
Ludum Dare 18 was over a month ago. While I didn’t get the game finished in time for the main compo, the Ludum Dare Jam was running simultaneously and offered an extra day to let me finish and submit it.
Stop That Hero! was my most ambitious game yet. It was partially inspired by a book I was reading about artificial intelligence in games and what ended up becoming the winning theme: Enemies as Weapons. I liked the idea of a hero controlled by the computer while you sent enemies to try to stop him. My initial vision was more like Super Mario Bros. That is, the game was going to be a platformer with multiple levels, and you were going to send enemies such as Goombas and Koopa Troopas at the hero. I realized right away that learning how to implement a platformer was not going to be an efficient use of my time, especially since implementing new AI techniques was already going to be a challenge. So I switched from a “reverse Super Mario Bros.” to a “reverse Legend of Zelda” game. The hero would be trying to conquer your towers and ultimately your home castle, and you would use a variety of minions to kill him first.
What Went Right
Early Prototyping Saved Time.
During the Ludum Dare #15, I was able to leverage my newly learned rapid prototyping knowledge to good effect, as I explain in the Mineral Miner post-mortem. Even though I had an idea of what I wanted to do before this latest competition started, I still spent some time fleshing it out on paper. Doing so helped me realize requirements I didn’t know I had, such as the need for AI visibility. I also got a feel for the game play, including how the player should spawn enemies and what they’ll do. Prototypes still work well!
Simple Controls Forced Creativity. I wanted the player to do everything with the mouse for a few reasons. One, it would make the game more accessible and easier to play. Two, it would force me to make a simpler game. If the player can’t do too much, then there shouldn’t be a lot of complexity for me to implement. Since I knew that I was going to have enough difficulty implementing AI more advanced than any I’ve ever implemented before, I didn’t want to let the rest of the project’s scope get too large. With simple controls, I would have to figure out other ways to make the game compelling. While simple controls still left me with a lot of design choices and directions to go in, I was able to focus my efforts, and I think the game turned out much better for it.
A Focus on Artificial Intelligence Was Smart. Right away, I knew that most of my time would be spent working on the AI. The game depended on it. I had just finished reading AI for Game Developers shortly before the compo started, and I realized that I never did so in all the time it was on my shelf! I learned some really cool and basic techniques, and I learned that sometimes simple AI tech is better than more complex AI tech. I was also glad I had Artificial Intelligence for Games, Second Edition to act as a more in-depth, up-to-date resource. Between these two books, I was able to create a decent bit of AI. My game’s AI needs related to behavior and pathfinding. Behavior was easily handled by a state machine, but the biggest dependency was on pathfinding. My implementation of A* was somewhat flawed from the start due to the fact that my AI agents didn’t necessarily have a single target at any given time and it was possible they didn’t see anything near them in the first place, but I was pleased with the results considered how much time I had to work within. Seeing a bunch of AI monsters moving about the screen on their own, avoiding each other, and otherwise looking like they had agendas of their own was a proud moment for me.
Agile Planning Kept Me Focused and Aware of Priorities.
Since I had a good sense of what the game was going to involve, I was able to plan quite a bit up front. It’s fairly common knowledge that the waterfall model doesn’t work in software development, but I wasn’t planning down to every detail. With Agile story cards, I knew what features to implement, but the implementation details were dealt with when I assigned a story card to myself. The problem with working alone is that no one is there to act as a check against my estimates for how difficult any particular story should be, but for the most part, things worked out well enough. I got two big benefits from using an Agile process to manage my project. One was that I always had a task in front of me. I never floundered, wondering what I should work on next, so my time in front of the computer was highly focused and productive. The other big benefit was knowing what features to focus on and what to cut as the deadline loomed. I originally wanted to have animations and special effects, but as the weekend went on, I knew these tasks weren’t nearly as important as getting working AI. Out they went, and I felt good about the decision.
What Went Wrong
I Spent Too Much Time On The UI and Menus. I took time to prototype and come up with Agile story cards early in the process, but where I went wrong was not giving myself deadlines for those story cards. Ludum Dare was almost halfway through when I finally had an implementation of a window that I could close by clicking a menu item. Granted, clicking was an important aspect of the game, but I probably could have done so without worrying about how the menus would work.
I Broke My Rule About Keeping the Art Simple. In past LDs, I realized that I would spend way too much time trying to create decent-looking art. Mineral Miner benefited from low-quality art because I was able to spend my time finishing it. For this LD, I thought keeping the graphics tiny would help, and it did, but I still found myself trying to draw a decent looking dragon when it wasn’t that important to make it look good. It simply had to be functional. Again, implementing AI was supposed to be my biggest challenge, but trying to create monsters that looked somewhat like what they were supposed to be was where I spent a lot of my time.
I Missed the 48 Hour Deadline. Ludum Dare is normally a 48-hour competition, but LD 18 was a combination 48-hour compo and 72-hour game jam. I normally try to get a good night’s sleep, but I stayed up late this time around. While I was able to get a lot of work done, I found myself making mistakes and having difficulty keeping the code structure in my head. By the end of the second day, I was disappointed that I didn’t have a finished game, so I went to bed. That third day was when everything came together for me, but missing out on the 48-hour deadline meant that I missed out on feedback from other entrants. The compo has rated entries while the jam did not, so entering a compo game would guarantee some feedback in the form of ratings and comments. As I was only able to enter the Jam, my game was ignored by and large. This is the first time that the Jam format was tried for Ludum Dare, and next time there might be some changes to address these concerns, so hopefully entering a game in the Jam won’t feel like second-class LD.
The Game’s Balance Is Off. On the last day of the Ludum Dare Jam, I found I had time to actually play the game. I tried to change values such as the Hero’s strength and speed and the amount of resources you obtain. I didn’t want the player to be able to create a dragon or two right away, so I lowered the starting resources, and then I didn’t want the dragons to come out soon after the game started, so I slowed down the resource increase. While I was able to make such a dominant strategy hard to do in the beginning of the game, it can still work well for the player so long as he/she has patience. Also, it had the side-effect of slowing down the pace of the game. You can only create a handful of minions in any game session, which isn’t nearly as fun as having an entire army swarming on the map. I would have liked more time to balance the game so that it was harder to pull off dominant strategies AND was fun to play.
What I Learned
Simple AI Can Do Wonders! The AI in my game didn’t turn out nearly as complex as I originally thought it needed to be, but maybe it’s good that it didn’t. The AI boiled down to a few pathfinding algorithms and the selection of a target to move to, which isn’t very different from a game such as Pac-man. Once I fixed a number of bugs with the pathfinding, Stop That Hero! came alive. It really did feel like you were creating minions to do your bidding.
Agile Project Planning Is Quick and Useful. Creating a prioritized requirements list and a schedule estimate helped me keep tabs on my progress throughout the weekend. I always knew what task to focus on, and I was able to change my plans when I realized that things were going too slowly for me to get it all done. I received advice that I should have deadlines for my tasks since a schedule doesn’t mean much without them, and I’m inclined to agree. With deadlines/milestones, I probably would have realized how slow my progress was earlier on.
I Need Sleep. Working through the night and into the morning, I learned that my most productive spurts were soon after waking up and having breakfast. Otherwise, even if it felt like I was making progress, I was actually creating problems by inserting bugs and implementing badly thought-out designs. I was able to recover, but in general, I think getting regular sleep is still more beneficial to my project’s health (and my own!) than not.
As in previous Ludum Dare compos, I’ve found my biggest problem is deciding where to spend my time and for how long. Creating a simple menu infrastructure and twiddling with image editors to try to make good looking art took away time from implementing AI and fixing the game’s balance. Project management suffered since I didn’t give myself deadlines, but it did keep me focused. In the end, I had a complete game, with sound, and I’ve decided I liked this project so much that I’ll be updating it and polishing it up for PoV’s inspiring challenge to sell a game by the end of October.
For future projects, I’ll need to give myself milestone deadlines to ensure that I don’t spend too much time on tasks, and I’ll also need to make sure that any art assets I create are primarily functional. Alternatively, I need to dedicate the time to learn how to create quality art and how to use the Gimp.
Mini LDs are usually looser than regular Ludum Dare competitions in terms of rules enforcement, voting, time start and end times, and themes. The host can also enforce a different set of rules. For instance, one MiniLD involved using a specific palette of colors from a 64×64 image to load levels from, and it was interesting to see all of the completely different games share the same level data.
For MiniLD #20, I picked the theme “Greed”, with an optional fun theme of “Fishing”. The special rule I made: “Only one of each.”
In programming, it’s easy to make lots of copies of objects. Well, I’m putting a stop to that! For this MiniLD, you’ll need to ensure that every object in your game is unique. If you build a wall, there better be a single wall (it doesn’t matter how complex it is) and not many tiles composited together to make a wall (unless all of those tiles are completely different from each other, which might make an interesting game…) Granted, maybe everything derives from a common object, but you can’t have two objects that are exact copies of each other. If that means you can only make a few objects, then work within those constraints. B-)
While there was some griping about this rule from the participants, many of them pulled through and submitted a game. In all, 24 entries were submitted.
Unfortunately, The Old Man and the Monkey Thief, the game I was working on, wasn’t one of them.
Also, there were some complaints about how the MiniLD was handled overall, and while I wasn’t taking any of the complaints personally, I did think I let some people down. What follows is a post-mortem of both the game and the competition as a whole.
What Went Right
Participation was high.
I was very pleased to see that 24 entries were submitted. I know that there were more games being developed that weekend that weren’t finished, so overall, there were many participants, especially for a MiniLD. I was happy to see that the special rule didn’t scare off too many people. There were even a few people who have never participated in a MiniLD before. A trial by fire for them!
Simple art was quick art.
When it comes to creating art, I’m much better with a pencil than a computer program. I needed to create quite a bit of unique art, though, and I didn’t really have time to draw with a pencil much anyway. So what did I do? I took pictures with my camera and then traced those images in a separate Layer in the Gimp. That means this flask I got as a present for standing up in my sister’s wedding became a unique golden treasure in my game:
became and this spatula became this Unique Spatula .
Oh, my kingdom for an artist!
But it worked well enough, and it was relatively quick. I even did a decent job creating the main character with a pencil drawing, did the layer tracing thing in the Gimp, and came up with a digital old man who didn’t look half bad!
Overall, tracing with layers in the Gimp made quick programmer art even quicker than it usually is! I didn’t have to worry about being bogged down in getting the lines or curves right.
Being Prepared Helps Before the competition started, I did a quick MiniMiniLD for myself. I hadn’t done any code outside of a day job in many months, and my computer had been upgraded since then, so I wanted to ensure my development environment worked as expected. It would have been annoying to start the competition only to learn that my compiler or build scripts were unusable.
Also, I’ll go into more detail below, but I’m glad I had my backup plans! When a storm knocked the power out for me and apparently 30,000 other people, I’m glad I had my Uninterruptible Power Supply to keep my desktop computer from getting more damaged that it could have been. Also, my laptop let me continue work for over an hour after the power went out, and so it was lucky that I replaced the battery the week prior. When the power didn’t come back in the morning, I took my laptop to a new, powered location, and I was able to keep working even though my apartment went over a day without power. It was a horrible situation during a timed competition, but I think I responded to adversity well.
And it helps to have an encouraging girlfriend remind you that you can’t give up. B-)
What Went Wrong
The power went out.
I took a nap Saturday evening, woke up in the middle of the night, and started working on my project. I had a number of ideas I wanted to implement, and I was wide awake. Around 3AM, with a storm raging outside, I found that my laptop was providing the only illumination in my apartment. The lamps were off, the UPS was beeping, and my desktop’s monitor was dark. That’s OK. I can SSH into my desktop to shut it off…oh. Wait. The router was not plugged into the UPS either. I made a note to change that situation for next time.
I lit a few candles, one in my office, and one in the dining room so I could see when I go out to get some water out of the fridge. Maybe 50 minutes later, the smoke alarm went off. It turns out that the dining room candle was on fire.
Now, I don’t play with fire much, but it wasn’t the fire itself that scared me. It was the fact that the candle, the thing that is meant to be used to hold a flame, was on fire! Another note for next time: don’t put out candle fires with water. The flames exploded upwards before dying out, and suddenly it was dark. I could hear the heated glass and metal parts of the candle holder tinkling, and I had no idea what was going on. And of course the office candle was also out since the melted wax drowned the flame. I had enough with fire for the night, so I didn’t bother relighting them.
So I sat down at my laptop and continued to work. I lowered the brightness and shut down many unneeded applications and was able to eek out 10 more minutes of battery life. Then I had nothing else to do but go to bed. Of course, I was wide awake. I could have searched for the flashlights in the dark or tried the candles again, but I decided this was a forced break and went to bed. My DS was still charged, and I played Advance Wars: Dual Strike for a bit before sleep took me.
The next morning, there was still no power. I learned it wasn’t just my apartment. It turns out that a huge part of Des Moines was without power due to the storms. The library is closed on Sundays due to budget cuts, and I wasn’t sure where the nearest wifi-enabled cafe with power was. Luckily my cell phone still worked, so I had people I could call and a basic way to do searches. My girlfriend was out of town, but I had the key to her apartment, so if she had power, I could work there, too.
I had options, but I’ll admit that I felt a bit defeated that Sunday morning. I wasn’t as enthusiastic about getting up and running again as I’d like to be able to report. Maybe it was because I was exhausted. Maybe it’s because my home office chair is hard to sit in for days at a time. Maybe I just missed seeing people. I was a new full-time indie, and I was secluding myself in my office for way too long as it is. Maybe I just needed exercise. Maybe I assumed the power would come back within hours and I wasn’t sure if I should venture out or stay home. Whatever it was, my motivation had dipped to the point that I was dragging my feet to decide which of these options I’d use.
When I talked to my girlfriend, she was very encouraging, especially as she heard the reluctance in my voice. This weekend was MiniLD weekend, so there’s really no excuse for me to not do what I can to continue. I packed my laptop, the laptop riser, some game dev books, and some papers and notes, and I headed over to her place. I didn’t have the key to the front door, but the doorbell is linked to her cell phone, so she buzzed me in remotely. And she had power at her apartment! Glorious power! I was able to continue work.
Of course, I lost a lot of my waking hours. While I don’t like shifting blame, especially since I had options, there aren’t many options at 3AM during a storm. Now, if my life depended on it, I’d have no qualms about waking people up at 3AM, but for a MiniLD? Still, while the power outage disrupted my work, it didn’t stop me completely.
The Urgent took priority over the Important.
Some things I did other than work on my MiniLD project: called phone company tech support to find out why picture emails weren’t going through to recipients, played a video game, fight a literal fire and not just a metaphor for urgent business matters, read interesting blog posts or watched interesting YouTube videos, chatted on IRC with other MiniLD participants… Now, chatting on IRC is part of the fun of working in a Ludum Dare competition, but links get posted. I found myself distracted by links from Twitter, too. Being new to Des Moines, I spent part of my time looking up local game developers to connect with.
All of these things are fine on their own, but since I was supposed to be focusing on my game project, they were distractions, and I failed at putting them off until after the competition.
I burned myself with my own special rule.
Only one of each was meant to challenge developers to try to do as much as they could with less. Unfortunately, there was some confusion as to what was on or off limits. Could you have the same sprite displayed two times if one had a red color overlay while the other had blue? What if you just add noise so they look different?
Now, I think the idea of using noise to get around the limitation was clever, but outside of that, there were two options: do lots of unique content, or do a game involving only a few unique items. The latter would definitely be doable and be more along the lines of what I was hoping for.
So of course I ended up making a game that required lots of unique content. B-(
Now, being the host, I knew about the special rule long before anyone else did, but I didn’t think about the kind of game I would make until I started the competition. In hindsight, I should have cheated and thought my game idea through before the theme/rule announcement.
The Old Man and the Monkey Thief was supposed to be about an old man who goes to sleep one night only to wake up and find that all of the unique treasures he collected over the course of his long life were stolen by this energetic, ninja-like thief. The old man then had to go into the world, collect these unique items, and use them to save his wife. I figured he could use the fishing pole as a way to retrieve otherwise inaccessible items, and so the secondary theme was satisfied.
What I didn’t realize was how much work it is to program unique items! I spent a huge chunk of a day getting the fishing hook and the key to work. By the time they were implemented, I was afraid to add a third item because of how much work would be involved, and time was running out. Now, this is 48 hours. Imagine being a game developer on a 3 year project and learning that you need to implement another item without letting the deadline slip. I got some insight into that kind of despair.
Essentially, having only one of each item meant that they were either reusable, like the fishing hook, or one-offs, like the key. Either way, this rule encouraged feature-creep if you intended to make a game with a lot of unique content. If I could do it all over again, I’d have tried to do more with the fishing pole alone rather than try to have more than one usable item. Less is more, and I probably should have made a note that it was my original intent with the rule.
The little things.
When I decided on the themes and special rule, I wrote up a blog post and scheduled it to publish when the competition started. There’s a problem with doing so on the main LudumDare.com site. Editors can see the post before it’s published! So I wrote the theme and rules in a post on my own blog, then used the LD post to link to it. Great!
Except something went wrong. For some reason, the LD post didn’t publish, and it took some time to get it corrected. I was away at an event, but I checked in, found out about the problem, and got it working somehow. IRC participants learned about it, but people who were depending on the website being updated at the correct time were out of luck.
I didn’t request a submission form for the competition until near the end when I realized that there were so many participants. Some people had finished before the form went up, so they had to retroactively submit their games. Not a big deal, but it could have been smoother.
And the end? I could have handled the ending better.
Since it was only a MiniLD, the 48 hours is a bit flexible. While it officially started at a specific time, the usual expectation is that you could do any 48 hour period in that weekend. Since I had power issues, and other people were also hoping for a little more time, I thought I’d allow the competition to continue into Monday.
Then the fact that I’m running my own business took over, and other priorities came up. When I finally had time to dedicate to LD again, I learned that some people felt like the MiniLD had no closure. It was understood to be over, but there was no fanfare or official word. The submission form allowed for the entries to have ratings, but since voting was not enabled, participants couldn’t vote. MiniLD #20 felt like it just stopped, especially for people who weren’t in IRC and were relying on the main website for their up-to-date competition information. New LDers can’t be faulted for not understanding what was happening. I had every intention of providing a proper ending, but as the host, I dropped the ball.
What I Learned
There’s more to being a MiniLD host than announcing a theme.
Being a MiniLD host, I found I had some unexpected responsibilities. Namely, I needed to keep things going for everyone to ensure they had a good time! Now, I’m not being paid, and no one else is either, but I still feel terrible that people felt the weekend was somewhat spoiled due to my inability to prepare for those responsibilities. I plan on writing up a checklist for future MiniLD hosts. It may sound a bit formal for such a loose event, but I think it would help everyone have a better time going forward.
Feature creep is insidious.
Let’s extrapolate The Old Man and the Monkey Thief from a 48-hour project to a six month project. Thinking that I’ll add just one more item might mean I spend a few weeks to a month doing so. And if I have an item that can be used, that means creating objects and a section of the map that allows you to make use of it. For instance, I wanted the old man to find a unique tie, which he could use to tie up pieces of wood together to make a boat. Making a tie, suddenly the work is to create boat components and a boat, and why would the boat exist if not to allow you to get across water, and if you can cross water…. The point is that the scope of the project blows up quickly. I realized I was making a poor Zelda clone.
On the other hand, if a game makes use of a single mechanic, suddenly it’s much more manageable. What if the entire game involved the use of that fishing hook? I probably could have finished a game using just that one mechanic.
I need to work on my discipline.
I found myself getting distracted too easily this MiniLD. When adversity hit, I didn’t respond immediately and affirmatively, at least not right away. One of my favorite quotes is “Discipline is remembering what you want”, and I need to remember what I want and why I’m doing what I do if I want to see myself through to the end of any future projects.
All that said, I think MiniLD #20 was a success for me. The Old Man and the Monkey Thief is the first game I’ve ever created that made use of a scrolling background. Previous games used a single screen. To determine where the old man can and cannot walk, I normally would check the tiles, but since I didn’t have tiles, I did something I’ve never done before. I created a black & white version of the entire world map, which the player never sees, and one color represented where the player could walk. Once again, a 48-hour game development competition allowed me to learn some new techniques. I also learned what areas I need to work on. Discipline and project planning in 48-hours is one thing, but discipline and project planning in months or a year? I won’t last very long as a full-time indie if I don’t figure those out.