Video (screencast) Are you Designing a Game, or Throwing one Together?

Here is the text of the slides. The entire presentation (over 15 minutes), obviously, contains more than this text.

Are you Designing a Game, or Throwing one Together?
Dr. Lewis Pulsipher
Pulsiphergames.com
“Game Design” channel on YouTube

This is Really Important
Yes, there is creativity in game design, but it may amount to 10% of the whole
The rest is more or less engineering: identifying problems, proposing solutions, testing the results of those solutions, and so on
Scientific method is involved, more or less
It is not trial and error
(I use the meaning prevalent when I was young, that of guessing what might work, then checking to see if it does)
There seems to be a notion now that trial-and-error is more or less scientific method: NO!

It’s not a Guessing Game!
Let me use an example from programming to illustrate
While I was a college teacher, I substituted for a teacher who was ill in a beginning programming class
The students had a program to work on, so I walked around trying to help
In general, their program didn’t work
Programming is very logical. The proper response 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 once you’re playing a prototype
That “identify” might include some intuition, and the solution might involve some creativity, but mostly it’s logic
But the students?
Rather than try to figure out why it wasn’t working, they just guessed, changed the program, and compiled it again to see what happened
If that didn’t work, they guessed something else
They were using trial and error (guess and check)
And they were frustrated, of course
So I tried to show them how to figure out the logic and flow of the program, rather than guess

Methods
Certainly, different people have different design methods
Some design more “from the gut” than via logic, hypothesis, and test
Nonetheless, if you are actually designing something, you are primarily using your brain, I think (I hope), not just inspiration
Inspiration is not very reliable! It comes and goes
And the more you treat modification as an engineering problem, the more efficient you’ll be

Art versus Craft
The more you think of a game as art rather than craft, the more you may be inclined to rely on inspiration and intuition
Perhaps we should call that “game creation” or “game inspiration,” not “game design”
Practically speaking, though, it’s mostly craft once you have a playable prototype

NOT throwing things against the wall to see if they stick
Trial and error amounts to “throw things against the wall and see what sticks”
This is a terrible way to solve a problem, if you have any alternative
I’ve seen this dramatically illustrated

Egregious Example
A beginning designer had his simple (< 30 minutes, cards and scoring only) card game playtested by players new to the game
The game has already been successfully Kickstarted, but clearly was far from done – most of the cards were hand-written (not even computer generated), for example
As he started the game (he played – also an error in my view) – I saw that he had no rules with him
His response was, he played it 6 or 7 different ways, and was changing it to satisfy backers as well
My comment: already Kickstarted and the rules writing wasn’t being tested, since they weren’t even at hand

But then he said he was trying out a particular rule change
How can you try a change when the rest of the game isn’t stable? You’re only trying with 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
The next question was, “how are you recording the results of the playtest”?
He usually had a notebook, he said, but not today

Though he did have a laptop on which he took notes after the game ended
By the way, this game involved player elimination – NOT desirable nowadays, even in a 30 minute game
And though it was a scoring game, the designer hadn’t bothered to bring the scoring devices, so everyone scored on their smartphones!
This is just sloppy. You’ve got to test the actual game, not substitutes!

Obvious Flaws
It was a card game of direct attack on other players (in a more than two-sided game)
There was no constraint on whom you could attack
So while I didn’t watch the game much, I asked afterward if there was a strong tendency to attack the leader
The answer from the players was “yes”

Leader-Bashing
The game suffered from leader-bashing, but I’m not sure the designer recognized that term when I used it, and only had glimmerings of why it was undesirable
Then people suggested solutions, but the first (only attack those adjacent) would have pretty drastically changed a game that’s already Kickstarted!

Why is leader-bashing undesirable?
It takes most decision-making out of the game
It makes people want to sandbag
It’s dull because it’s predictable

Part 2

What we have here is a case of somebody throwing things against the wall to see what will stick
He tries to playtest the game in various ways and see what seems to work better
That’s Trial and Error (in the older, undesirable, sense)
And it helps show that Kickstarter is often about ideas and intentions rather than about an actual game
The art (he had it for a small number of cards) looked good, and that probably helped the KS a lot

Here’s the proper way to go about this, not just trying this and that, with a fairly detailed borrowed diagram, and with a simpler version:
[diagrams]

Or more simply
[Diagram]

Scientific Method
Wikipedia’s description of the scientific method (accessed 14 April 09) can be taken as a guide to what you’re doing as part of (but not all of) this design process:
“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.”
This is a large part of the replan and especially the monitoring tasks

But More Than That
Unlike scientists, in most cases you must rely on fewer testing iterations
These are more like usability tests than scientific experiments (Nielsen-Norman group: http://www.nngroup.com/articles/ or alertbox.com)
On the other hand, you’re making changes in a design, as well as experimenting to see what happens

An Analogy
This engineering versus trial and error is comparable to how people learn software or home appliances/electronics
I read the manual (shocking). It’s amazing how much you can learn that way. And far more efficient
Most people just dive in and try things
Or simply remain ignorant
The engineering style of game design is like reading the manual. The T&E method is like diving in and trying things – much less efficient
Yes, not reading the manual is easier
(And yes, I prefer to read the rules to a game in order to learn it, unlike most people)

Education
I’ve discussed this cycle at length in my “Learning Game Design” course on Udemy.com
The major point to make here is that you follow a process that relies on solving problems you’ve identified
But you also have to know what kinds of problems might occur
Such as leader-bashing in a card game
Or many others – which is why I make so many of my videos, to educate people about those possible problems

Method
Trial & Error (guess and check) is poison unless you have no choice but to use it
If you rely heavily on intuition, more power to you
But that’s not something we want to teach to aspiring 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 consistently, not hope to be bailed out by random flashes of brilliance

For me as a teacher, I want people to understand a good method, and “inspiration/intuition” or especially trial and error are not good methods.