Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

my collected notes on "Keeping Game Designs Simple and Accessible" Sticky

A topic by dto created Jan 01, 2016 Views: 1,465 Replies: 1
Viewing posts 1 to 2
Host (8 edits)

Here is an outline I put together to share my recommendations on keeping it simple in game design, based on what I've learned over the years. I've kept it simple in the presentation here, too, as it was originally intended to be a live talk. Consider it a giant post-mortem for my personal 2008-2015 game jam. ---Dave O'Toole

Why keep it simple?

Simple games are easier to develop, right? Accessible games can be played by more people, and simple games also often have wider inherent appeal.

What does Simple mean?

Rough working criterion of simplicity: "simpler designs have fewer parts"

Make bullet lists and just count the parts!

Prioritize list items with A, B, C

  • Category A: need it now
  • Category B: want it soon
  • Category C: would be nice someday

Be a ruthless overlord in postponing/deprioritizing stuff you don't really need

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 Category A until it is empty due to finishing/deprioritizing tasks.

  • Then, re-prioritize and repeat.

Game design elements that tend to introduce complication and multiply workload

Elaborate weapon/magic systems with many choices

  • Say you have six weapons, so justifying their existence must be gameplay situations / enemies that are more susceptible to each weapon
  • If you had 12 weapons, that'd be twice the work to make the new objects relevant

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? Even more multiplication, and many objects which must be explicitly prevented from working together 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.

Crafting items by combining other items

  • Needing to carry and remember all that stuff
  • Can lead to large numbers of combinations (or just tons that don't produce anything of value, which isn't good either)

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?

"Can the player pick up the gamepad/keyboard/tablet and understand the basics of gameplay in 60 seconds?"

Measurement of accessibility: interface between player and game is simple and obvious (or ALMOST obvious)

  • Surface area: how many buttons does the user need to learn/remember?
  • Are there a lot of screens or menus, or does the action mostly focus on the player-character?
  • Player can see/hear/reason about what is going on directly, not by reading text descriptions or parsing statistics tables.

A simple game design is already well on its way to being accessible too

Adjustable difficulty

  • allow a more general audience to participate
  • multiplayer games can allow different difficulty settings per player so that different skill levels can play together

PC keyboard limitations: you can only rely on arrows+shift being simultaneously registered as pressed

  • Design for arrows/shift/spacebar/gamepad+2buttons

Users with special needs

Much more info at

Game design elements that aren't very accessible

  • Complicated user interfaces with many screens
  • Text-heavy games (I learned this the hard way!)
  • Requiring user distinguish many colors
  • Consistent story/world setting
  • Requiring a mouse
  • Multi-level menus
  • Presenting vital information through color or sound alone

Learning from Atari 2600/7800 designs

Undeniably simple controls—8 directions and one fire button.

Limited RAM/CPU led to simpler, more focused designs

Game Reset

  • easy testing for developer, less frustration for player when game ends suddenly.
  • no need to go through the opening cinematic and character generation screen again!
  • easy feedback loop to help the player "get" the new game more quickly.. die a few times etc

Game Variation Select

  • variety is the spice of life
  • co-op and/or versus play

Difficulty adjustment switches

BW/Color switch

  • Metaphor for accessibility to everyone
  • Color vision impairment

Consider your audience

The notions of accessibility and simplicity can be different from one audience to another; what is complex for a Strategy JRPG is different from a sci-fi FPS. None of the examples above should be taken as applicable to every audience.

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.
  • Outlining tools
Host (1 edit)

The views expressed above 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, 3x0ng, and so on.