Game A Day May Post-Mortem Part 1

I wrote 32 games in as part of an experiment I’m calling Game a Day May.

The shortest games were 200 words long. I designed these to fit on a business card. The longest was more than 8000 words long.

I started on May 2nd, and barring one day (May 22), I put out at least one game per day over the rest of the month.

I’ve already made two posts detailing the games, one that covers the first few games and another that covers basically through the end of the second week. There’s some marketing spin in those posts, but I’m going to revisit them without the marketing as well for a pure post-mortem.

The games are all in a neat collection over on itch.io. Some have their own store pages, but I provide links where relevant. They will go up on DriveThruRPG once I decide how I want to do that.

I will not go into individual games today. I’ll go into more details on the games I made in a second post-mortem, which will be a collection of posts I’ll upload to itch.io and copied over here for reference and context for them.

The Inspiration for Game A Day May

I’m a huge fan of National Novel Writing Month (NaNoWriMo), which is a thing where people try to write a 50,000 word novel in a month.

I think these challenges are a great way to develop the habits and practices needed to be a productive writer. This is not always the same as a quality writer, but there are two schools of thought here.

One is to be a perfectionist and make the best thing you ever can. The other is to throw things at a wall, see what sticks, and then revise.

The strength of these challenges is that if you’re a bit of a perfectionist (as I am), you need a push to do the “go fast and break things” approach to writing. I’ll happily sit around for a week working on a project, decide I don’t like it, and toss it in the garbage.

But when you’re doing a game a day, you don’t have that option.

I’m also working on a project to write a million words this year. I hit the 500,000 word mark a few days ago, and since we’re just getting into June that means I’m well ahead of schedule.

Challenges

The obvious challenge in the Game a Day thing is just finding creative space to work. I went in with basically three requirements:

Don’t just re-skin what I’d making over and over gain.
Make games I’d actually play.
Create actual competitors to what’s out there or innovate.

The important thing for me was that if you went to my storefront and browsed it two years from now, you might legitimately not know that I made some of these games as part of a daily challenge.

It’s also worth noting that my challenge was to release a game every day, but many of my games had over one day of work, or at least had a tremendously feverish amount of work within that day. The shortest games probably took about an hour of work (NaniteD6), but the longest got closer to 40 hours’ worth of time and attention.

That second point became a major issue for the time commitment as well. If you could play a game without a character sheet, but I wouldn’t, I made a character sheet. Stuff like that adds up quickly, though I have a fairly standard-issue character sheet format which I used over the month to cut down on the work time.

I’m doing full-time writing and game design (and have the full related talent stack), which made that possible. My goal is to become self-sustaining from my work, but I’m not there yet. If you want to hire me as a freelancer, you can reach out to kyle (at) loreshapers (dot) net and I’d be more than happy to quote rates.

Tools

Over the years I’ve used a variety of tools to make games. I started in LibreOffice, moved to LibreOffice and Scribus, then wound up with a LibreOffice first workflow. I like the idea of working with FOSS, but it was a slow workflow.

Now I use Microsoft Word with a plug-in called ProWritingAid and the Affinity suite of software (Publisher, Designer, Photo).

I know writing assistant programs have a bad reputation, but when you write as much as I do they’re a lifesaver. It also helps that I have an MFA and I write prolifically, and did before I started using the assistant. This is what I would recommend to anyone trying to write well.

Learn to do it without help, then get help from software. It’ll make your writing easier and catch things the standard word processor checks won’t.

My Workflow

I have a fairly consistent workflow. After my morning routine, I start with a little graphic design if there’s something to do. If not, I might get straight into writing.

I listen to a lot of podcasts or audiobooks, and I’ll listen while I work on visual elements. Then I’ll put on some music and write. What I listen to varies from day to day and subject to subject, and I’ll often make a playlist for a game (or use a genre playlist).

I start with a cover. It doesn’t have to be the final cover for a game, but it’ll typically be a good approximation. I don’t save old revisions unless I start over from scratch, which you’ll see in the part where I talk about folder organization and share a screenshot from my working folder.

Then I’ll start writing. I aim for 30-45 minute blocks, though if I’m on a roll I’ll go longer than that. It gives a good balance between avoiding burnout and keeping active. I like to get up and drink some water between blocks, and I’ll do errands in these gaps.

By encouraging myself to break up my writing, I have built in times to stop and reflect. This is usually more helpful than staring at a page.

Once the writing’s done, I do my text layout in Publisher. I have a 20-minute recording of doing this for a simple project. After that, I make my character sheet and insert it into the PDF.

This is a pretty consistent process and worked well for me.

Lessons Learned

I promised that this would be an overall post-mortem. I want to summarize the lessons I learned, though I’ll go into specifics in later posts.

My games got a little more sophisticated over the course of the month. Some of this came from better planning. Some of it came from becoming more skilled with my tools.

Both improvements had to come from practice. I like tutorials when I can find them, but they rarely align with my use cases.

However, the biggest lessons don’t really come from the tools themselves. I found my production process grew the most over the month.

Steal (With Permission)

I would not have been able to complete the Game a Day May challenge without liberal use of stock art.

We rarely think about how much other people contribute to our work.

But making a great-looking game (or even just a tolerable looking one) involves mixing fonts, graphical elements, and rules together. You can do all of that yourself if you’re really talented across every domain, or you can rely on others.

Relying on others is the best.

The key to productivity is the Pareto principle, but we can think of this as the division of labor.

I’m not a great visual designer. I’m good with colors, fonts, and basic shapes (if I may say so myself). The rest I need to go elsewhere for.

And I do. Between purchased and public domain stock-art, I probably used 2000 work-hours worth of content with a few clicks over the month. That doesn’t even account for borrowing from past work that I’ve done.

The important thing here is to always get permission when you take work. This may involve a general license (such as things released into the public domain) or you can ask politely.

I also used various System Reference Documents, though I’ll talk about that separately. They’re great foundations to build on, if you understand them.

Cheat (With Dignity)

Cutting corners is a lifesaver, you just need to know how.

I’ve picked up a lot of little tricks to give myself 15-second solutions to problems. The page background gradient is one of them. You’ll figure out these things in your workflow as you do stuff, and I won’t go into a lot of detail here.

The key here is that you want to keep the magic.

When I was in college, I took a class on CGI and animation. The most important lesson I took away from it is that you can get away with things that are really inelegant from a creator’s perspective so long as they fool your audience.

A secret here is to look at the Pareto principle, once again. 80% of your effort gives 20% of your results, and 20% of your effort gives 80% of your results.

When you’re doing a game a day, you spend all your time in that 20% and then copy-paste, kludge, or hack everything else. For instance, by working with SRDs, I could come up with one or two unique mechanical twists for a game without needing to come up with a top-to-bottom concept.

Utilize Setbacks

One strategy that’s helpful is to keep recycling things forward. When I had something that didn’t work, I’d take what I could from it and put it toward something new.

However, this also applies to things outside the process. I’ve been having some minor health issues that disrupt my sleep.

Up late? Great time to do a map or a cover or interior elements.

Rather than staring at the ceiling trying to sleep, I’d simply get a little more work done. Once my symptoms fell off, I could sleep well and know that I had a good chunk of the next day’s game done.

This also turned out to be a perfect way to be creative. Because the time wouldn’t be good for writing either way, I had less guilt about browsing itch.io looking for jams to join or finding inspiration in weird ways without the time pressure of normal day-time browsing combined with an aggressive workload.

Organize Your Folders

My folders are a mess.

This is not something that needs a lot of discussion.

When you’re working with print output, even if you consolidate files as well as you can, you wind up with lots of loose files, and you need to organize them.

Searching and finding stuff in a large folder probably only takes 15-20 seconds each time you do it, but if you’re doing it twenty or thirty times a day it adds up to a significant cost. If you’re uploading to a file-type agnostic platform like itch.io, you might even wind up with the wrong file, which can be a major headache (or even a legal issue, depending on licensing and usage).

Cut Losses

If you look at the images above you might notice a few thumbnails that aren’t related to released projects. Some of these got started and cancelled, some are sketches, and some are current WIPs for me.

Some of these just didn’t hold interest. Others clearly had issues with their style or structure and had to be abandoned.

If you can figure out whether a branch can bear fruit, you’ll save a lot of angst and time.