Wednesday, December 14, 2016

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

(First appeared on Gamasutra.com)

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

Sunday, December 04, 2016

Triptych VIII: Three separate topics in one post

(Except this time it’s four to get to a 1,000 words. . .!)

Programming is not “Integral” to Games
Pop History
Special Powers Card Games 
Virtual Reality

Programming is not “Integral” to Games
(Originally written in 2009. And we now see, with Unity, how much easier it is to make video game software than in 2009.) I don't regard video games as fundamentally different from non-electronic games.  There are tens of thousands of non-electronic games that were never touched by a programmer.  If the video game designer had some "magic" (technologically advanced) way to create the software - and as time goes on and technology improves, this will be the case - then programmers would be unnecessary.

That's why I regard programming as a necessary evil of video games, not fundamental to games.

It is already the case that someone who isn't a programmer by training or inclination can create the equivalent of Pac-Man with Gamemaker in a fairly short time.  More and more complex video games will be made without trained/professional programmers.

Ultimately, programming is "donkey work," something that ought to be done by machines.  But I could say the same about many kinds of work.  Some of those kinds of work have already disappeared or are disappearing, some will disappear.  Programming is going to be done by machines--already is, in many cases, though the machines are using software created by programmers - long before design or art is done by machines.

***

Pop History
I read something recently about a game covering the fall of Rome in Britain, and about incorporating Arthurian stories into it.

Yes, I included Arthur in Britannia, but that was literary license, not history.

Yes, there are lots of books supposedly about Arthur, all amounting to "well, this could have meant that, and could have been about the person we call Arthur" that then transforms into "this was Arthur".  It's a big industry of speculation with virtually no foundation, much more fiction than fact. There is NO contemporary evidence for "Arthur", almost no contemporary evidence for *anything* in this time period. ("Dark Ages",  remember? Dark because of lack of information, not a comment on the standard of living.)

A big reason why history changes so much from one generation to the next, is that so much of it is malleable rather than certain. History becomes, not fact, but fiction intended to appeal to the desires or needs of contemporaries.

"Pop" history, video history as we sometimes see on the History Channel, is a reflection of this. It's history as modified by what "the masses" want it to be.

***

Special Powers Card Games
One reason why Magic:the Gathering  became successful is that it was, if not the first game, one of the first games where the main interaction is between the cards of the two players, using special powers that are exceptions to the rules. That has been generalized for many card games, it's a kind of game that's easy to make, and I know several budding designers whose first game is of this type.

I am not a fan of them because they don't have anything do with reality. Some of the people who are designing the games may think so - but there's a weak grasp on reality these days. Yu-Gi-Oh is even worse because lacks the constraint of "lands".

For me any "theme" in these games is just a gloss. It's not something that actually affects how the cards are played or how the game is designed. It doesn't help people understand how the game works, either.

My name for this kind of game is "Special Powers Card Game" (SPCG).

***

Virtual Reality
Pundits are still pontificating about whether virtual-reality games (VR) will succeed as a business, and have been since the announced release date for the Oculus VR with the anticipation that it’s Valve and Sony competitors would be not far behind.

I have not used one of these contemporary VR systems, and I read that people who do are often converted to the cause. My experience goes back some decades when (at a convention I cannot otherwise recall) I put on a primitive VR-like device. It was suspended as a pair of eyeglasses, but with one side empty and the other side occupied by a small module. That module produced a red dot on black screen display (this tells you how old it was) that substituted for the screen display of typical computers of the time. You could see the “screen” with one eye while the other could see your normal surroundings. I didn’t try to play a game with it but I was quite impressed with how very well it substituted for a screen.

I also recall, in the early to mid 90s, watching a graphical “virtual tour” of a part of the new Womack Medical Center that was being built. The 486 computers of the day really weren’t fast enough to render the tour in more than slow motion. It was quite fascinating nonetheless.

More recently I’ve seen augmented reality (AR) games, and I understand that game developers are far more gung ho about AR than about VR, yet few of them are actually producing AR products. [Written before Pokemon Go was released! I bet a lot more are working on AR now.]

Within the past six or seven years I’ve also been in a virtual-reality chamber where three walls showed a seascape and you could walk around looking at it.

Recognizing that computing power is still advancing rapidly, and thinking about how the graphical capabilities of computers have changed from the old ASCII graphics to modern 3-D, it appears to me to be inevitable that VR will succeed sooner or later. Too many people want to reach the Star Trek holodeck stage for maximum immersion.

Whether the current products will start that progression, or fail as those of the past have failed, is subject to all kinds of chance and unforeseen factors (such as hygiene?). Remember, the best products don’t always prevail in the marketplace (Betamax versus VHS VCR for example). Timing is very important, and we have no idea, even now with products out there, whether the timing is good.

***

My Black Friday/Christmas sale on my online game design courses is listed on my website, http://pulsiphergames.com/#BlackFriday

Doomstar has sold better than the average mobile game, though how it compares with other PC (and Mac/Linux) games I do not know. It’s on Steam as “Lew Pulsipher’s Doomstar” but Doomstar is good enough to search. Or buy from the publisher https://largevisiblemachine.itch.io/doomstar