Are you designing a game, or throwing one together?:  You can’t design a game as though you were playing a video game

This is a vital topic in game design: are you designing a game or you throwing one together? Yes, creativity is part of game design, but it only amounts to about 10% of the whole. The rest is more or less engineering: you identify problems and propose solutions, implement the solutions, test the results of those solutions, and so on. Scientific method is involved in your testing, and engineering is involved in your solutions. Occasionally inspiration and creativity are involved.

Just Say No to Guessing

What game design definitely is not, or at least should not be, is trial and error. I'm using the meaning that was prevalent when I was young: guessing what might work, and then checking to see if it does. I now call it "guess and check", because there seems to be a notion today that trial and error is a form of scientific method. No, it's guessing. Game design is not a guessing game (though as in all other creative or engineering endeavors, sometimes you get a lucky guess).

Let me use an example from a beginning programming class to illustrate. While I was a college teacher I substituted for a teacher who was ill, in a programming class for beginners. Many the people were not going to become programmers, but everybody was required to learn some programming, which made good sense in a computer department. The students in the class already had a program to work on, a simple one, so I walked around trying to help in general, as their programs didn't work. 

This is not surprising. Programming is very logical, and people often are not taught logical methods in K12. The proper response when the program isn't working is to figure out the program flow, identify where it went wrong, change the program, and test the solution. It works the same way in game design. Much of the purpose of playing a prototype is to identify problems and test solutions. This includes some intuition, and the solution might involve some creativity, but mostly it is logic. 

But what did the students do rather than try to figure out why it wasn't working? They just guessed, changed the program in accordance with their guesses, and compiled/ran it again to see what happened. If that didn't work, they guessed something else. They were using traditional trial and error, guess and check, and they were frustrated, of course, because it wasn't working. I tried to show them how to figure out the logic and flow of the program rather than just guess. 

Game design ought to be the same way; some people won't do it that way but I think it's the most efficient way, and it's the way that I like to teach people. Certainly different people have different design methods. Some design more from the gut than from logic. But it still involves hypotheses and tests: if you're actually designing something you are primarily using your brain in an organized way, I hope, and not just relying on inspiration. 

Inspiration? Not Reliable

Inspiration is not very reliable.  “Inspiration is wonderful when it happens, but the writer must develop an approach for the rest of the time  . . . the wait is too long.”  (Leonard Bernstein, the composer and conductor - and writer.)  Inspiration comes and goes. The more you treat the modifications of your game as an engineering problem, the more efficient you're going to be.

Some people may think of a game as art, rather than craft, and the more that you think of it as art, the more you might be inclined to rely on inspiration and intuition. So we might say that you're not designing a game, you're creating a game, though it's mostly craft once you have a playable prototype. A playable prototype is going to change a lot if you're doing a good job. Game design is not throwing things against the wall to see if they stick, which is what trial and error and error amounts to. It's "try this and see what happens. Then let's try that and see what happens." Some things might happen better than others, but it's a terrible way to solve a problem. 

Why Do People Design This Way?

When I did the video version of this piece, I had not realized why this guess-and-check method might be common. Unfortunately, changes in game playing have led to much greater use of trial-and-error (guess-and-check) than in the past, and to puzzle-solving rather than problem-solving.

When I was a kid (more than 50 years ago) I searched for games that required you to think to succeed, but which were not abstract. The classic games such as chess and checkers were just too abstract, I wanted something that represented, modeled, some (possibly fictional) reality. Avalon Hill's wargames finally filled the bill for me, followed by Diplomacy (for more than two players).

With the advent of video games, gaming became a matter of athletic skills more than brainwork. No matter how well you could think, if you didn't have the reflexes and hand-eye coordination needed, you'd not be good at most video games. Video games were athleticware, not brainware.

Moreover, video games tended to be single-player puzzles, where there was an always-correct solution, owing to the inadequacy of the computer opponent. There was no substitute for human opposition.

When you play an opposed game of strategy, a game you can lose - which is usually a tabletop game - you cannot afford to simply guess at what to do. That's the road to Loserville. But now we have so many single-player and co-op video games, games where you can save the game at will. Many players try lots of different choices to see what works best, saving each one, and then use the best to move on to the next challenge. They don't have to figure out anything, they can just guess-and-check. In the extreme I know of someone who, finding a chest with random contents, will open it, save it, open it again, save it, and so forth, dozens of times, in order to get the best result. Ridiculous! Alternatively, some play games with online help open. If something isn't working well, the player will look up the best way to "beat" it, and continue. But it's these kinds of mentality that are the opposite of what you should be doing when you design a game. These mentalities amount to "throwing things against the wall to see what sticks."

Further, with the advent of Eurostyle games in the latter 90s, we entered the era of parallel competitions (which I called "contests" in my book Game Design), players all trying to solve the same puzzle. Even though there were usually several different solutions ("paths to victory"), they were still always-correct solutions. Many tabletop gamers became puzzle-solvers. People learned to look for the solutions, because they didn't need to worry about the opposition. Some games coming out of the Euro style transcended this, but most have not.

In designing a game, you do have, in effect, a "Save Game" option. Because you can try a solution you've devised, and if you decide it doesn't work, you can go back to the old way of doing it. But this takes a lot of time (one playtest often isn't enough to determine the success of a modification). Maybe you have lots of time to waste guessing at changes, but I certainly don't, nor does anyone who wants to design for a living.

Furthermore, knowing that there's always a best move (as it true of puzzles) is quite different than having to decide among uncertain alternatives, as in a typical wargame. Game design is problem-solving far more than puzzle-solving. There is rarely an always-correct solution in game design.

As a result of these changes in how games are played, many people who want to become game designers have learned the wrong ways of doing things, learned the wrong set of skills, to design games! Obviously, not everyone plays games this way (I don't, even when I play a video game), but the majority of gamers do.

Illustration of Throwing Against the Wall

I've seen the throw-against-the-wall method dramatically illustrated. Recently a beginning tabletop designer had his simple, multiplayer, 30 minute game, which involved cards and scoring only, playtested by players new to the game. The game had already been successfully Kickstarted but clearly it was far from done. Most of the cards were handwritten (not even computer-generated) for example. He also made the error of playing the game without having any rules with him (to test the rules as well). I asked why? His response was, he played it six or seven different ways, and was also changing it to satisfy backers as well, so he didn't bring the rules! 

So here we had a game that was already Kickstarted and the rules writing wasn't being tested. When he said he was trying out a particular rule change my reaction was, how can you try a change when the rest of the game isn't stable? You're only trying to change one of those half-dozen ways to play. When you playtest, you playtest the whole game, not just the part that you're experimenting with. If the rest of it keeps changing, how can you evaluate the effect of one change?  

My next question was, how are you recording the results of the playtest? He said he usually had a notebook, but not today, but he did have a laptop and he took notes after he was eliminated. (Yes, he played in the playtest, worse, without rules at hand. Bad Idea.) I can point out here that it was a game with player elimination, which is not desirable nowadays, even in a 30 minute game, and it was a scoring game yet he hadn't bothered to bring the scoring devices, so everyone scored on their smart phones. This is just sloppy. You've got to test the actual game, not substitutes! 

I've talked about some of the obvious flaws like player elimination, but there was another one. It was a card game of direct attack on other players. There was no overall constraint on whom you could attack; the lesser constraint involved categories of who you could attack  that is, your strongest attack in your hand at any given time could only be aimed at some of the players rather than any of them, depending on their characteristics. They had about five or six players in this game. I didn't watch the game much as I was doing other things. I asked afterward if there was a strong tendency to attack the leader, and the answer from the players was, yes. The game suffered from leader-bashing. I'm not sure the designer actually recognized the term when I used it, and only had a glimmering of why it was undesirable. People then started to suggest solutions to the leader-bashing, but the first, only allowing attack on adjacent players, would have pretty drastically changed a game that's already Kickstarted! (I'm often critical of Kickstarted games because of the nature of the audience, but I'm really offended by the idea of Kickstarting a game that is so far from complete.)

As an aside, why is leader bashing undesirable? It takes the strategic decision-making out of the game, you just attack the leader. It makes people want to sandbag (if they can), they don't want to be the leader until the very end. In fact, given the nature of the game, there was virtually no decision-making involved. You picked your strongest attack that could affect someone in or near the lead, and that was it. I'm not opposed to simple, even shallow, games, but they should still give players viable choices, the "horns of a dilemma" of traditional board games. This one didn't.

To continue with this egregious example, what we have in this designer is a case of somebody throwing things against the wall to see what will stick. He tried to playtest the game in various ways to see what seemed to work better. It seems to me to be trial and error in the undesirable sense. It also helps show that Kickstarter is often about ideas and intentions rather about an actual game. He had a little bit of the art for the actual game for a small number of the cards and that looked quite good, and probably helped the Kickstarter a lot. 

"Scientific Method"/Engineering

So let me talk briefly about the proper way to go about this part of design, not just trying this and that, not throwing things against the wall. I use a fairly detailed diagram and a simpler version. This is an engineering design process. It's also something like project management, because each time in project management you're doing something that's rather different than what you've done before. I'll discuss this simpler project management diagram here. 

The Plan is about you creating the game to the point where you have a playable prototype. 

Execute is playing a prototype, first of all solo, then other people.

While a game is being played, you Monitor whether it's doing what it's supposed to do, whether it's going according to your plan, the vision you had in your head. 

Control is when you monitor something that isn't going to plan, you do something to fix it, to make it work the way you want to. 

Successful changes go into the Replan, where you modify your prototype. Then you go back to Execute and you play it again, and you keep going round and round on that, gradually making your game better. 

I despise the word "iterate". Yes, this is an iterative (repetitive) process, but the word iterate, which is often used in video games, must be one of the ugliest words in the world, yet only covers half of what you're doing. You are modifying and testing, not just playing again and again. The scientific method is involved.  To be termed scientific, a method of inquiry must be based on gathering observable, empirical and measurable evidence subject to specific principles of reasoning. A scientific method consists of the collection of data through observation and experimentation and the formulation and testing of hypotheses. (Wikipedia) 

Game design is lot more than that, though. Unlike scientists, in most cases you have to rely on relatively few tests. (Nowadays in video games we see "open beta" testing, and testing after release, in order to increase the sample size and use statistical methods of analysis.) Unlike the scientist you're making changes in the design, an actual product, as well as experimenting to see what happens. Fortunately, this is usability testing, not scientific testing, and usability testing does not require a large number of trials. I strongly recommend that you check out the Nielsen Norman Group's website at alertbox.com, and read their articles. They are talking about web design usability, but most of what they say applies to game design, especially video game design where user interface is very important. We have user interfaces in tabletop games, but they have over many centuries settled down and don't change rapidly.

An Analogy

Being a literal-minded person, I don't venture into analogies much, but I'll try one here. This question of engineering versus trial and error (guess and check) is comparable to how people learn software or home appliances or electronics. Unlike most people I read the manual. It's amazing how much you can learn that way and it's far more efficient. But what most people do is a just dive in and try things, or they simply remain ignorant. I read the manual and find out all you can do (if it's a good manual) that most people who just dive in and try things are not going to figure out. 

The engineering style of game design is like reading the manual, the trial and error style is like diving in and trying things. It's much less efficient, but it is easier, just like not reading the manual is easier, and we can apply this to games. I would rather read the rules to a tabletop game in order to learn it, unlike most people who would rather be taught. It may take longer, but I miss less when I read the rules and understand the game better when I read the rules, if they're good set of rules, than when somebody teaches me. 

I've discussed the whole cycle of testing and modification in my "Learning Game Design" course on Udemy.com, and there's also a course just about Playtesting. The major point to make here is that you follow a process that relies on solving problems you've identified. You also have to know what kinds of problems might occur, like leader bashing in a card game, and that's why I make so many of my videos to educate people about those possible problems. 

Method is important, and trial and error (guess and check) is poison unless you have no choice but to use it. If you rely heavily on intuition or inspiration, more power to you, but that's not something that I want to teach aspiring game designers. If you think it's all about inspiration, I think you're dead wrong, any more than getting ideas is all about inspiration. You have to work at something to do it well on a consistent basis. You can't hope to be bailed out by random flashes of brilliance. 

As a teacher I want people to understand a good, efficient method: "inspiration," "intuition," and especially trial and error (guess and check) are not good, efficient methods. 

Design a game, don't guess at it!

Lewis Pulsipher

For the video screencast this derives from, see Youtube: 
Part 1   https://youtu.be/USZQipf4GLM
Part 2   https://youtu.be/UOUItO3uCSk

Patreon:  https://www.patreon.com/LewisPulsipher

Twitter @lewpuls
Pulsiphergames.com
Online courses: https://www.udemy.com/user/drlewispulsipher/
Free "Game Design" channel: http://www.youtube.com/user/LewGameDesign
google.com/+Pulsiphergames