Keeping game designs simple and accessible

Table of Contents

About this document

Note: the word "accessibility" here refers specifically to audience-intuitive (as opposed to audience-counter-intuitive) game designs—games you can just pick up and play. The related subject of accessibility for gamers with color vision impairment etc, is not addressed extensively here.

This document is part of Dave's guide to Common Lisp game development.

I wrote it to share my recommendations on keeping it simple in game design, based on what I've learned over 10 years of developing computer games. The point of this is to design intuitive, pick-up-and-play type games on a solo or small-team basis without tearing your hair out over pure design or project planning. This is achieved by using simple Emacs Org-mode techniques to radically simplify the design and development process.

The views expressed herein are drawn from my observations of user response (or lack thereof) to games having various degrees of simplicity/complication and accessibility/obscurity, as well as the closely related experiences of developing and debugging these divergent games. I will offer only anecdotal evidence to justify these recommendations: my text-heavy games with complex controls and gameplay systems were much harder to design, develop, test, and debug—by an order of magnitude in some cases—and reached a much smaller audience, regardless of genre. By far, my simplest games have been my most popular: 2x0ng, Squareball, and so on.

Why keep it simple?

Simple games are easier to develop and easier to get into, right? Simple, accessible games can be played by more people, and simple games also often have broad inherent appeal.

Keeping your designs simple is an important way to make sure projects get finished, even when your mind is bubbling over with cool new ideas. Good working criteria of simplicity can help you counteract the natural forces of feature-creep.

Besides, you shouldn't be afraid to save some good ideas for your inevitable sequel.

What does "simple" mean?

A rough working criterion of simplicity is that simpler designs have fewer parts. So you can make bullet lists and just count the parts!

As a diversion I'd like to link to a few relevant wikipages on the Portland Patterns Repository site:

Enough deep thoughts! So, how do we organize and prioritize our work on the different parts, now that we've got this goal of simplicity in mind?

Write a design document with Org

Even a simple Org outline can help structure a design and get everyone on the same page. But it's important to write a proper design document describing gameplay, controls, graphics, sound, mission structure, and so on. The level of detail doesn't have to be exhaustive in every area, but main areas should be fleshed out.

Prioritize list items with A, B, C

I've found that using three priority levels or "baskets" is most helpful in wading through the swamps.

Priority "A" means: I need it now. Use this for required elements of the design.

Priority "B" means: I want it soon. These items are still important, but have failed the crucial test of "c'mon, do you really NEED this?"

Priority "C" means: it would be nice to have. This "basket" should hold ideas and tweaks you want to remember, but don't need to focus on right now.

What this means is that you spend most of your time working on Priority A tasks, sometimes doing Priority B tasks, and only rarely working on a C task.

Be flexible: priorities can change

Don't be too reluctant to postpone something. It won't disappear if you keep good notes. Prioritize, then work only on Priority A until it is empty due to finishing/deprioritizing tasks.

Then, re-prioritize and repeat. When A is empty, you can move up C and B tasks that seemed unimportant but have suddenly assumed new urgency.

The point is to design and code freely, organizing your ideas and work together efficiently without becoming bogged down.

Use Org to manage tasks and maintain your design document

With Org you can slice and dice your entire design doc, adding and changing priorities and TODO/DONE tags as you go. With plain text you can keep the design doc in version control as it mutates.

Game design elements that tend to introduce complication and multiply workload

While these are simple examples, they do illustrate how lots of bullet items lead to complex and labor-intensive designs that may not be suited to solo or small development teams.

Elaborate weapon/magic systems with many choices

Say you have six weapon types. To justify their existence there must be gameplay situations, enemies, and/or counterattacks that interact differently with each weapon—otherwise they're just window-dressing.

Long lists of character classes/types

If you have just a few, like Gauntlet (Thief/Magician/Warrior) then it's still simple — although still more complex than just having one. If you have dozens, you have to have many (probably dozens) of interacting factors in the game design in order to justify distinguishing the character classes. Do Mage and Necromancer have totally different magic systems, and can't equip each other's weapons or armor? This means even more multiplication of parts, and many objects which must be explicitly prevented from working together meaningfully—enforced by yet more code.

Exploration as a mechanic

You have to have more places to go (and reasons to go there) otherwise it's boring. Good procedural generation can overcome this hurdle in some ways, but this is by no means a panacea.

Crafting items by combining other items

You have to carry and remember all that stuff. It can also lead to large numbers of combinations—or just tons that don't produce anything of value, which isn't good either.

You'd better have a good inventory system and a good user interface—another bunch of complications.

Alliance/guild/reputation systems

If your guild membership affects many events in the game, you have to build and test all those alternate paths. If it doesn't affect many events, then why bother with it?

What does Accessible mean? Ask the Atari 2600

I like to use the 60 second rule. Can the player pick up the gamepad/keyboard/tablet and understand the basics of gameplay in 60 seconds?

Think about the Atari 2600. One joystick and one button per player. It couldn't get any simpler, and yet the library of deep, high quality titles is vast.

The other buttons were equally important:

Game Reset

Not only is it easy to keep playing after failure, it also results in less frustration for the player when the game ends suddenly. No need to go through the opening cinematic and character generation screen again! This easy, fast feedback loop can help the player "get" the game in seconds.

Game Variation Select

Variety is the spice of life. Offering selectable variations on your gameplay like the old days of the Atari, if done carefully, can greatly expand the fun. The 2600 "Combat" cartridge is a perfect example of this; I've tried to do something similar with Squareball.

Difficulty switches

Adjustable difficulty allows a more general audience to participate.

Multiplayer games can allow different difficulty settings per player so that different skill levels can play together. The Atari systems had this covered, with a difficulty switch for each player. This use case is especially important in family situations. (Many Atari-developed cartridges for the 2600 and 7800 used a teddy-bear icon for the child-level difficulty mode.)


Co-op and versus play make great additions, too. The Atari 7800 version of Centipede and 7800 Asteroids support both, and most of the Atari-developed 7800 games had some kind of multiplayer mode.

Playing an Atari 7800 and a good library of 2600 and 7800 cartridges is one of the best ways to study game design.

You'll have fun, too. Nothing beats an actual four-player 2600 Warlords match on a big screen. It is one of the very best games ever made.

Video discussions

How to use these ideas in writing and outlining

  • Write a paragraph or two of prose about your project.
  • Break down prose description into TODO items, then prioritize
  • Avoid long, open-ended descriptions, or laundry-lists of what might be cool someday.
  • Stick with lists of what you can do in the near-to-medium-term.
  • Use outlining tools such as Emacs OrgMode.

Author: David O'Toole

Created: 2017-04-05 Wed 17:20