Software and Records

You don't need to just get better at game design. You need to get more efficient at it.

As your game design career progresses, you should upgrade your tools and processes.

Software

I did my first games in Word or Photoshop, and printed them out. Art was hand-drawn by me, and I'm not an artist. Note even a self-taught one. The computer work was laborious. Printing and cutting cards and boards, repeatedly, was even more so.

Playtesting was originally done just with the occasional friend. Later, I would pay people I knew $50 to come to my place, and do some playtesting for two hours. That could get me a playtest every week or two. A friend would also help out sometimes, when I hosted board games at my place.

Later still, I got into the groups on Discord, got Tabletop Simulator, and joined some small groups. It was inefficient, and I wasted countless hours playing some terrible five-player games. However, it was the first time I could get relatively easy playtests. I worked with a few different amateur designers over the years: virtually anyone who wanted regular playtests, regardless of their skill or demeanour.

Since the publication of Radlands, I've been recruiting the fans of the game as playtesters. They've been generous and eager helpers, and they're not game designers, so I don't even need to playtest their games in exchange.

I strongly suggest making your game cards in a word processor, rather than a graphics program like Photoshop. Dealing with positioning things, and hundreds of layers, is mind-boggling. One of the many little problems you'll run into is trying to put icons in the middle of text.

If you have a desktop publishing program, that's far better. I use Affinity Publisher, and it's excellent for boards as well as cards. Each page can be a card, so you're not trying to cut up a larger image into cards, nor do you need dozens of separate files. I now put almost everything into one big file, except large boards. This means all tokens, cards, and resources. It's much easier.

If you're making a game that's predominantly cards, I recommend Dextrous 🔗. It's a very nice system that's specifically designed for making card games.

Uses for AI

AI can't design your game. However, it's very useful for some other things. I use it for mainly for ideas and research. Here are some ways I use AI, and some example searches.

• Research on other games. "List some exploration games that aren't cooperative."
• Mechanics research. "List resources that are found in steampunk games."
• As an advanced thesaurus. "Give me fantasy words that mean 'object'."
• Theme research. "What crops were grown in water, in medieval Europe?"
• Coding LUA for Tabletop Simulator. "Make a button that puts all the meeples back where they started."

Using AI art

I'm not going to delve into opinions on AI art in published games. However, it's highly useful and widely accepted in prototypes. I expect I'll use it in most prototypes going forwards.

I currently use Dall-E.

Don't use the standard realistic style, as it will make your images look like a generic cross between a studio photograph and a 3D render.

Specify a drawing or painting style.

To find your preferred art style, just ask for artistic images of things. When you find something in a style you like, put it back into a chatbot, and ask it what the style of the image is. Then, when you make images, you always add that art style after your description. This makes all your art look fairly consistent.

My adventure game always used variants of "very simple line drawing style." One example is " (Description of what I wanted.) Very simple line drawing style. Realistic. Colourful. Desaturated rainy forest background."

Documents are useful

Each time I do a revision, I make another copy of the entire game folder, and number it (001 etc.) I keep every revision of my games, as I often want to recover an old component, see how I did things, or even revert the whole game to a previous state. A publisher actually asked me to revert to a previous version of my game.

When I start a design, I write a document. I start brainstorming ideas as I go. It's kind of a conversation with myself. It starts turning into decisions, and tables of data and information. If I try to make another game in this genre, I'll look back at this.

Also, I write a report for each game that I abandon. These are both cathartic, and highly informative when I try a new game in this genre, much later.

I also have a spreadsheet I call my "Game Design Index". It records all the games I've made: their names, year, number of revisions, a line of notes, and a "potential". 0 is a game I'll never go back to, and 10 is something that's published and available.

Changelogs are useless

For a long time, I kept excellent notes for each revision I did. These would contain the results of my playtests, my thoughts on the revision, and comprehensive changelogs of the rules and components. After many years of doing that, I decided it wasn't worthwhile. I never really re-read my notes.

Later, I just had a spreadsheet of quick comments, and a column of major changes. That wasn't really worthwhile either. I'm only going to keep track of who did what playtests, from now on, so I don't lose track of my playtesters. Changelogs are a waste of time. Don't do them.

Changes to components are recorded anyway, as I retain a copy of every version of the game. Also, rules changes are recorded on the rules card in each version. 

I do not record the feedback of playtesters. During the game, and during their feedback, I'll make notes of what needs to change. I'll erase these notes later, as I do the work.