4.33 out of 5
4.33
3 reviews on Udemy

Game Playtesting: the Heart of Game Design

Playtesting: when, how, why, what to do (and not do)
Instructor:
Lewis Pulsipher
34 students enrolled
English [Auto-generated]
Understand that there's a lot more to playtesting than just playing the prototype
Recognize that playtesting is not only about fixing problems, it's about ensuring your target market enjoys the game
Know what you can do to more efficiently arrange playtesting
Understand what you can do to conduct playtesting more effectively
Understand what you can do when using the results of playtesting
And many other considerations that come into playtesting

This is an in-depth treatment of what’s important, and how to effectively conduct and benefit from, game playtesting. Translating the 6.5 hours of videos to words, it’s the size of a small novel (more than 50,000 words). To my knowledge, there is nothing approaching this size on this subject in existence.

Playtesting is the heart (though not the brains) of game design. If you want to be a good game designer, not just a hack, you have to understand that heart just as you have to understand the brains, as covered in my other courses.

The major sections cover:

What is Playtesting?

Arranging the Playtesting

How to Conduct Playtesting

How to use the results of Playtesting

Other Considerations when Playtesting

There is nothing here about game programming, art, sound, etc. It is all about game design.

Introduction

1
Instructor and Course Introduction (same as "Course Promo")
2
The heart of game design

Video game developers decades ago relied on a priori (thinking alone) judgments about the quality of their games, now everyone realizes a posteriori (empirical evidence, that is, testing) is necessary.


We're focused on games that our users like. It doesn't actually matter what we think our users like, it matters what our users actually like. A 15 year-old girl in Estonia likes to play different games than a 40 year-old woman in South Korea versus a 25 year-old woman from Texas.


Following is the first section of the Playtesting chapter from my book "Game Design":

Chapter 6 How to work with and improve the prototype

You make a prototype so that you can test the game by actually playing it. There is NO substitute. Playtesting gives you the chance to improve the game immensely, but you’ve got to make that happen.

A. The purpose of playtesting

Whether you’re working on video games, or you’re designing tabletop games as a way of learning game design, constant playtesting to improve the game is the major path to success.

The biggest factor in the playability, the successful gameplay, of a game is not the quality of the ideas, nor the strength of conception, nor the marketing skill, nor the skill of artists or programmers. It's the quality and quantity of playtesting and the resulting improvements made to the game. In the end, if enough people in your target market play the game and enjoy it, then it's "good"; if they don't, then it isn't! While a poor game may sell well thanks to marketing and other factors, ideally you want to create a good game to give you the best overall chance of success.

The number of inexperienced people who think they've successfully designed a game, yet haven't playtested it at all, is remarkable. Playtesting is playing the game to find out how it can be improved, and then improving it to try again. The process is both incremental–a little at a time–and iterative, again and again. The playtesting stage is closer to the start of successful design, than to the end.

Let's clarify something. This is playtesting to improve gameplay, not testing to squash programming bugs. Some people call the former “fun testing” and the latter “bug testing”. Bug testing is often what video game makers mean when they talk about "testing", and this testing takes place late in the development cycle, when the gameplay and appearance are set in stone (because it's too late to make big changes). This bug testing (misleadingly called "Quality Assurance") is aimed at making sure the game works the way it is supposed to, but does not determine whether the way it's supposed to work is good enough.

"Bug testing" essentially does not exist in tabletop games, although it is important (and often forgotten) to test the production version of a game, as converting the prototype into the published version can introduce its own set of problems. (A small example: the boxes on the Population Track on the 2006 Britannia board are inconveniently small; this new version of the board evidently was not actually tested. They are larger on the 2008 printing.)

The "natural" way to design a game, as used in tabletop games, was long used in the video game industry, then abandoned, but is coming back into custom. A playable prototype is produced as soon as possible. It is played, revised, played, revised, played, revised, seemingly forever, until a stable "good game" has been produced.

The lead designer/programmer of Unreal Tournament III, Steve Polge, described how important it was for Epic to be able to playtest within a month of starting, and constantly thereafter. (See the video with the UT III Ultimate Edition.) Epic’s Gears of War 2 was playtested something like forty thousand hours (that’s the equivalent of 20 people working a normal schedule for an entire year). For Civilization IV Firaxis used a team of only 7 or 8 people to make a working prototype as early as possible, then played it constantly throughout the production process. They then added many more to the team for production artwork and polishing. (See their 2006 GDC presentation, available in video form with the Civilization IV Game of the Year edition).

The "wannabe" designer's assumption that the first prototype will be just fine as it is, before it's even played, is a product of both ignorance and the tendency to oversimplify the role of game design. If you think that a good idea makes a game, you might be excused for thinking the prototype will be "just fine". As we’ve observed, the idea is just a starting point.

People in other fields of art and entertainment revise their work often, even if they don’t test it on others. Beethoven had notebooks filled with musical ideas and revisions of his work. He actually completed four versions of the overture for his sole opera--Leonora 1, Leonora 2, Leonora 3, and Fidelio, the one finally used. You can hear the improvements when you listen. I like Leonora 3 best, but this mini-symphony was too monumental to be used as an overture to an opera, so the composer tried another tack for Fidelio. He matched the work to his goals and requirements, something every game designer needs to do, especially when employed to make a particular game.

Ideally, a game designer has the time to do this with every game, but this example is extreme even for Beethoven, and would be extreme for a game designer, to finish three versions of the same general work before settling on a fourth. The difference from games is that Beethoven was producing a passive kind of art, something to be presented to the audience when done rather than to be tested with an audience. Because games are interactive, the only way to modify them sensibly is to ask the “users” what they think and feel.

When you design a game, you try to see in your "mind's eye" how the game is going to work, but until you play it, you simply cannot know what is going to work and what is not. The first few times you play, many things will change (provided, of course, that you're willing to make changes, which is a major characteristic of a successful game designer).

More experienced designers can foresee more weaknesses and eliminate them before reaching the prototype stage. But every designer, regardless of experience, is likely to change the game significantly when it begins to be played.

What you absolutely cannot do is convince yourself that whatever you like is what other people will like, that the way you play is the way other people will play. You are not your audience, you are not typical (or you wouldn’t be designing games), you are too close to the game: you cannot rely on yourself.

There is no substitute for extensive playtesting. Your initial prototype is almost certainly going to stink. Get used to it.

3
What you'll discover in this Playtesting course, and how it works

Just what it says . . .

I'm not a big fan of quizzes, but many people like them, so I've included a quiz with most sections of the course. In particular, life is an essay test, not multiple choice, but we have no way to do an essay test.

4
Voluntary, anonymous entry survey (10 questions)

What is Playtesting?

1
Why Playtest? Games are Active, not Passive – unlike many other Individual Arts

Unlike most other works of individual art, games are altered by the user/consumer. Hence, the designer loses a lot of control over the user's experience. The best way to regain some control, to at least eliminate undesirable results, is to test the game with lots of players from the target market, and modify it to remove that which is undesirable. That's why we playtest.

2
12 "Need to Knows" about game playtesting

This is a summary I created for aspiring game designers in general. I've added it here, though we'll go into more detail about most of these points as we go through this course.

3
Bug testing versus "fun testing"

We're interested in testing to make sure that the way a game works, is interesting and enjoyable ("fun testing"). This contrasts with more traditional (in video games) bug testing, which is to make sure the software works the way it was designed to work.

4
The Process of Playtesting and Modification
The playtest and modify cycle is a form of engineering, or perhaps of scientific method.

From my "Learning Game Design" course.

5
Playtesting "Broken" Games - is that why your group won't test your games?

Yes, every prototype (and many published games) is broken in some way. But do you fix enough of your brand-new prototype that when other people play it, they can more or less enjoy it? This requires solo testing and fixing, no way around it.

6
Kinds of Playtesters

Categories of playtesters and how they differ, and where to find playtesters.

From my "Learning Game Design" course.

7
Metrics, and differences between tabletop and video game playtesting

Metrics is the technique, sometimes becoming a near-fetish, of using a large array of computer-monitored measurements to modify a video game that’s either in “early access”/released, or in a widespread beta. It amounts to a form of A/B testing common on Websites

To me, it easily becomes a form of “throw things against the wall and see what sticks”, of trial and error (guess and check), rather than of informed DESIGN.

I discuss that technique, and the differences in playtesting between tabletop and video games.

8
Emergent behavior and Playtesting
Emergent behavior - player and game behavior not intended or anticipated by the designer - is what you're looking for in playtesting. Depending on whether you're a game designer, puzzle designer, or story writer, governs how you deal with emergent behavior.
9
What Playtesting is NOT!

Playtesting is not focus groups, or bug testing, or validation testing. It's testing how the game plays to make sure it's entertaining (or otherwise effective, if it's a "serious" game).


From my "Learning Game Design" course.

10
Playtesting is like practice, without doing it right, you won't excel

Perfect?

You’ve heard the phrase “practice makes perfect”. Evidently it’s a really old phrase:

“Practice is everything. This is often misquoted as Practice makes perfect.” Periander (an ancient Greek from before the Golden Age).

But “everything” is not really true either, you have to practice the right way or you waste much of your time, and that’s the topic for today/

11
Confusions: playtesting with family versus with target market

•To get the best from playtesting, you need “objective” opinions

–That is, ones with no emotional connection to you or to the development of the game

•Those who are connected with a game tend to lose their objectivity, just as in anything else

•Those who are emotionally connected with you similarly lose their objectivity

12
The fruitless search for the "magic pill" solution

Some novice designers hope that there's a formula, an easy solution, to any problem, sort of like the pill (or the cassette) in The Matrix. No such luck! Game design doesn't work that way.

13
Exercise: practice what you're going to do
14
Quiz 1: What is playtesting?

Arranging the Playtesting

1
Nine ways to make playtesting more attractive to gamers

Contemporary gamers tend to be finicky about playtesting games that look (and probably are) unfinished. Here are some ways to make playtesting more attractive, but there's no substitute for a regular group who are familiar with you and your games.

2
Where to find playtesters

This is largely about tabletop playtesting, which presents additional problems to video game testing. It's about where people congregate to play games, and how you can locate them.

3
Stages of Playtesting

What are alpha, beta, and gamma (post-release) playtesting?

From my "Learning Game Design" course. Additions are in the next (written) "lecture".

4
Stages of Playtesting: the state of the game, or the nature of the testers?

I always think of stages of playtesting as relating to the state of the game, but some people relate stages to the nature of the playtesters. Discussed here.

5
Playtesting objectives can vary

Generally, you playtest to fix what’s broken, and to make sure the target market enjoys the game.
But there can be more specific goals, and that’s the topic here.I imagine that in some circumstances there are goals other than the ones I list here,these are the most common ones, I think.

More Specific Goals:

  • Test to see “if there’s something in it”
  • Testing with new people to get their reaction – broadening the testing pool – and to see how they see things differently
  • Testing to see how people change their play with experience
  • Test with those outside your target market
  • Test one change
6
Conventions: Protospiels, UnPubs, and "publisher speed dating"
7
Why is it so hard to persuade people to playtest prototypes?

There are three major reasons why it can be hard to find people to playtest your prototype.

8
Blind testing

Blind testing - having someone play your game without your intervention of even presence, so they must read the rules to learn the game - is ideal, but it's hard to find reliable tabletop blind testers. REALLY HARD.

On the other hand, video games blind testing is the norm, because video games hardly ever come with rulebooks or other reading materials.

9
Quiz: Arranging playtesting
10
Project: Arranging Playtesting

How to Conduct Playtesting

1
Playtesting Exercise
2
What to Watch for in a Playtest Session - Part I

Playtesting is the heart of game design, and there are a lot of things to look for during a playtesting session (or from reports from blind testers). Which results in a two-part discussion. From my "Learning Game Design" course. Part 1

3
What to watch for in playtesting - Part 2

Playtesting is the heard of game design, and there are a lot of things to look for during a playtesting session (or from reports from blind testers). Which results in a two-part discussion. From my "Learning Game Design" course. Part 2

4
The "tweaking" segment of playtesting

•At some point your game prototype will be fairly stable

•The rules are set, but you’re looking for improvement (as usual)

•You’re trying little things to see which of 2 or 3 choices works best

•This is what I call the tweaking stage of playtesting

5
Should you play in your own playtests?

Short answer, most of the time, no. It skews the results. But if you design games primarily so that you can play them (I do not), you might ignore my advice.


6
Testing the rules as you play

The rules are the most important component of a published game. You need to test the rules just like you test everything else, and that means writing the rules fairly early in the process, revising and retesting them as you go along.


From my "How to Write Clear Rules" course.

7
Using questionnaires in face-to-face playtesting

I don't use questionnaires. Why Not?


First, it is widely known that if you ask people for opinions that involve their own actions and preferences, they’ll often tell you WRONG. Not intentionally, they just often get it wrong.
It’s much more reliable to watch what people actually do, how they actually react.
Second, unbiased questionnaires that actually find out what you need are VERY HARD to create
Which is likely one reason why I don’t try to.

I never ask people if they'd buy a game (prototype). First, because the answer wouldn't be accurate. Second, what they've just seen/played doesn't look cool (usually), where the published game can. Third, because people are often polite and might say when they think you want to hear. Fourth, because amongst young people (college-age), a few buy lots of games and the rest buy none. The answer would depend largely on whether I had some of the former.

If someone volunteers that they'd buy it, fine.

And more reasons, as discussed.

8
Using the "Six Hats" method to evaluate playtesting

I like playtesting to be as much like normal game testing as possible. But when I want to "go into more detail," I don't use a questionnaire, I use the "Six Hats" method for evaluating ideas, modified slightly for evaluating the game just tested.

9
Can there ever be a "bad" playtest?

Depends on what “bad” means.
Bad in the sense of “lacking in information?”:
Every playtest offers something, but some times less than other times.


Bad in the sense of “not fun?”:
Yes, that can happen, just as you can play any game and it isn’t fun for some reason(s)


Bad in the sense of “indicating your game is weak?”:
Yes, but if it IS weak, you want to find that out ASAP so you can fix it! That’s why we playtest


Bad in the sense of “someone broke the game?”:
But we need to know that NOW rather than later!

10
Brief examples of playtesting specific modifications

Some "designers" think that ideas can be ignored if they don't originate with the designer: the "not invented here" syndrome. This is an example of the ad hominem logical fallacy.

Don't be foolish. Evaluate an idea on its *own merits*, not because of where it came from. You are not god, nor are you infallible.

11
Example: Handwritten (!) notes from a solo playtest of a strategic space wargame
Handwritten (!) notes from a solo playtest of a strategic space wargame. This particular design has gone "swimmingly" (well, without major changes).
12
Example: Detailed notes from PT of a game that still needs significant changes

This is from one of my most-tested designs, but also one that has required major changes along the line. These are notes from a recent test, with more significant changes. Sometimes that's how it works out. Sigh.

13
Example: Notes from the initial playtest of a game (not handwritten this time!)

I probably typed these notes as I played, on a portable computer. More recently, I dictate to a smartphone in Evernote, then sync the text result to my desktop.

This particular game has not been played in years, these notes from 2009. It works, but I'm not keen on it at all.

14
Example: Notes (originally from Info Select) of first play of a space wargame

Notes from Info Select (my free-text database) about the first (solo, of course) play of a space wargame with both strategic and tactical elements.

I generally make a copy of the original notes for archival/historical purposes, then make notations/modifications to the notes in preparation for the second solo play.

15
How much do I try to "break" my games during testing?

During an interview I was asked this question. Good question: it's important to make sure your game isn't broken before it's released.

16
"Finding the fun" in a prototype? It should be built in

Someone on Quora asked "how do you find the fun" in a game? Sorry, you're supposed to design the fun in from the start! If you need to find it . . .

17
Quiz: How to conduct playtesting

How to use the Results of Playtesting - change, change, change, love it or fail

1
The Progressive Stages of Playtesting

This is a different look at stages of testing, from the point of view of what the designer is thinking, more than who the testers are.

2
Are you designing a game, or throwing a game together? Part 1

This is one of the more important screencasts I've made. I try to teach people a method for designing games, one that relies on thinking and problem-solving. Some people appear to use a much free-er form, I daresay sloppy, method, which amounts in large part to trial-and-error (guess and check) and "throwing things against the wall to see what sticks." Bad Idea.


I used to teach Project Management (graduate level), among other things, and game design has many elements of project management to it. Even though projects can change drastically, those who spend all their time "fighting fires" do a poor job. Those who plan and focus on the desired results are more successful. You need to do the same thing in game design, I think, to have the best chance to succeed.


This is Part 1.

3
Are you designing a game, or throwing a game together? Part 2

This is part 2.

This is one of the more important screencasts I've made. I try to teach people a method for designing games, one that relies on thinking and problem-solving. Some people appear to use a much free-er form, I daresay sloppy, method, which amounts in large part to trial-and-error (guess and check) and "throwing things against the wall to see what sticks." Bad Idea.


I used to teach Project Management (graduate level), among other things, and game design has many elements of project management to it. Even though projects can change drastically, those who spend all their time "fighting fires" do a poor job. Those who plan and focus on the desired results are more successful. You need to do the same thing in game design, I think, to have the best chance to succeed.

4
What makes a game good? Part 1

This is a summary of thoughts about what makes a game "good". There is no single way, as tastes vary so much in "games" (many of which are much more puzzle than game). So in the end, after describing many alternatives, I inevitably settle on my point of view. Part 1

5
What makes a game good? Part 2

This is a summary of thoughts about what makes a game "good". There is no single way, as tastes vary so much in "games" (many of which are much more puzzle than game). So in the end, after describing many alternatives, I inevitably settle on my point of view. Part 2

6
The pernicious "Not Invented Here" syndrome

Some "designers" think that ideas can be ignored if they don't originate with the designer: the "Not Invented Here" syndrome. This is an example of the ad hominem logical fallacy.

Don't be foolish. Evaluate an idea on its *own merits*, not because of where it came from. You are not god, nor are you infallible. And many heads are better than one.

7
What to do with the Feedback

How do you deal with (or cope with, since it can be critical) feedback from playtesting?

From my "Learning Game Design" course.

I was once asked whether to ask for/accept suggested solutions from PTers. As Neil Gaiman said (paraphrasing), if a PTer tells you what doesn't work for them, they're probably right, if they tell you how to fix it, they're probably wrong.

Like most game design questions, the answer is clearly "it depends". If you're playtesting with a lot of game designers, you'd be nuts not to solicit and listen to their suggested solutions. If you're playtesting with people who are just playing what may turn out to be fun games, even though they're prototypes, people who don't really think of themselves as playtesters, then you're unlikely to solicit much comment, and often you won't get many comments. The PTers are helping me identify problems, whether explicitly, or by my observations of their behavior. Though I cannot imagine not listening to a suggested change, the time it takes is minimal and "two heads are better than one", though I also agree that the problems are mine to solve.

In other words, it depends on the mindset of the testers, and on how much they think like designers. There is no single answer.




8
Continuous Improvement, not Discrete Versions

Testing and modifying a game design should be a continuous process of improvement. 

9
Playtesting Results: Is it the Game, or the Players?

Designers have to ask themselves, when a playtest results in an "outlier", whether it's in the game, or a result of the people playing the game (and the location).

10
A little change can go a long way

Even when your game works well, you should be looking for ways to improve it. Small changes can make small improvements. But they can also make big differences, and we'll hope you test those fairly early in the testing process.


This turned out to be quite a bit longer than I expected.

11
Confusions of game design: Symmetric and Balanced are separate things, pt 1

Symmetry is no guarantee of balance. A turn-based symmetric game can be quite unbalanced if the first mover (or last) gains a significant advantage. An asymmetric game can be balanced through careful playtesting. Part 1 of 2.

12
Confusions of game design: Symmetric and Balanced are separate things, pt 2

Symmetry is no guarantee of balance. A turn-based symmetric game can be quite unbalanced if the first mover (or last) gains a significant advantage. An asymmetric game can be balanced through careful playtesting. Part 2 of 2.

13
Rulebook: drafts, drafts. and more drafts

You don't write the rules just once, or twice. You write them, rewrite them, revise them, rewrite them, revise them, and on and on.

14
Good once, good thrice, good always

What are your standards? Are you trying to make a game that will be OK for one to three plays (like most published boardgames and video games these days), or do you want one that can be played 25 or a hundred times or more by those who like it? This will have a big impact on your testing.

15
Stages at which a game design might be abandoned

In order to help the most inexperienced among us, I've described the stages or junctures at which a game design might be abandoned (for months, years, or permanently). There are lots of possibilities, and lots of possible reasons.

If you're NOT willing to abandon a design, you're likely to turn out a lot of weak if not awful games.

16
Example: Notes from solo play of Epic Britannia to post in online playtest forum

These extensive, play-by-play, notes were written to post in an online forum for development of Britannia Third Edition. This is much more than I would normally do for a playtest.

If you're fortunate enough to have a following (for you, or your game) you may be able to set up a forum (such as on Yahoo Groups) for discussion of playtest results with testers. Britannia has been around for nearly 30 years in various editions, and I can get help from fans of the game when testing the third editions.

17
"My game is DONE!" But is it?

•I try not to say, when one of my games is playtested, that I consider it “done” •Because I KNOW how often the “done” game gets changed, if only in small ways –Keep in mind, some “improvements”, aren’t

18
Quiz : How to use the playtesting results

Other Considerations when Playtesting

1
What level of expertise have you designed and tested for? Part 1

Ideally, a game would work equally well with:
Novices: beginning gamers (especially, beginners at this game)
Mediocre: people who generally aren’t good game players (which is the majority), however many times they’ve played a game
Experts: both as game players, and in this particular game


But it almost never happens, except in really simple games that even children can play well:
In other words, where expertise makes no difference.

The more gameplay depth to a game, the bigger difference there can be between experts, novices, and people who aren’t good game players

If you've designed for experts, then you want to have some expert players, especially some who have playtested the game a lot.

If you've designed for mediocre players, especially those who expect a game to be transparent, and who only expect to play a few times, then you don't need to worry about expertise. Or about how people play when they've played many times.

Part 1

2
What level of expertise have you designed and tested for? Part 2

Ideally, a game would work equally well with:
Novices: beginning gamers (especially, beginners at this game)
Mediocre: people who generally aren’t good game players (which is the majority), however many times they’ve played a game
Experts: both as game players, and in this particular game


But it almost never happens, except in really simple games that even children can play well:
In other words, where expertise makes no difference.

The more gameplay depth to a game, the bigger difference there can be between experts, novices, and people who aren’t good game players

If you've designed for experts, then you want to have some expert players, especially some who have playtested the game a lot.

If you've designed for mediocre players, especially those who expect a game to be transparent, and who only expect to play a few times, then you don't need to worry about expertise. Or about how people play when they've played many times.

Part 2

3
If your Game Design is “My Baby”, you’ll need to “Grow Up” to be a Pro

You have to be willing to change your game again and again, and if necessary, to kill it. If it's "my baby", how are you going to do that? It's a game, folks.


I'm sorry the sound is too low. My new (at the time) computer wasn't doing well.

4
Unintended consequences from rule changes

Often during playtesting, you change a rule in order to modify the game in a desirable way. Of course, you watch to see whether it works as you intended. But you also need to look for unintended consequences, as games are logical structures, much like computer programs in their reaction to change. (Programmers amongst us know very well how fixing one bug can introduce others unintentionally.)

5
The 80-20 (Pareto) Principle

The old 80/20 rule actually has a name, and applies to many things in life. Including game design, especially testing.

6
What to record when playtesting multi-sided games

In addition to what you'd normally track when playtesting a two- or one- player game, there are some additional things to watch for in multi-sided games.

7
What paper prototypes look like

Here is a discussion, and some examples from my games, of what paper prototypes might look like. Not real pretty, nor hand-made.


From my course "The Joys of Game Design".

8
Playing Styles: Fluidity in Tabletop and Video Games, part 1

While I haven't emphasized it in the screencast, when you design a game you're practically choosing a play style that will be most efficient, depending on how fluid the game is. I discuss what I mean by "fluidity" and the three playstyles that result (one being kind of "in between the two extremes"). Part 1.

9
Playing Styles: Fluidity in Tabletop and Video Games, part 2
While I haven't emphasized it in the screencast, when you design a game you're practically choosing a play style that will be most efficient, depending on how fluid the game is. I discuss what I mean by "fluidity" and the three playstyles that result (one being kind of "in between the two extremes"). Part 2.
10
Playtest notes for a game still in development

I regard this unnamed "block" space wargame for two (or four, playing partners) as one of my better games. But it's only a year and a half old.(I refer to it as "4X".)

I tried developing a four-sided version; while it worked strategically, I don't believe you can play a block game for four because it's too easy to see the hidden side of some opposing blocks, especially in a game without strict "battle lines" (blocks scattered all over the board). I've included notes from a solo 4 player test.

11
Quiz : Other Considerations

Conclusion

1
What's Next?
2
"Bonus" Lecture about Lew's courses and activities
3
Example: My full game-by-game playtesting notes for a game "lying fallow"

This is an example of the brief notes I keep of each game playtest. (Sometimes I write much longer notes, that I keep separate, as in another example in this course from "Age of Expansion".) Since I made this file in 2008, I've discovered that the leader at midpoint nearly always won the game, so I've had to modify it and test further. Right now it's "lying fallow," not played in some years.

Bonus Materials

1
Why I wrote my book "Game Design"

Why write a book in the 21st century, an era when people rarely read non-fiction books? And why a game design book? Here's why…

2
What makes my book "Game Design" unique or unusual
What makes my game design book unusual or unique.
3
Other Designers as Playtesters
You can view and review the lecture materials indefinitely, like an on-demand channel.
Definitely! If you have an internet connection, courses on Udemy are available on any device at any time. If you don't have an internet connection, some instructors also let their students download course lectures. That's up to the instructor though, so make sure you get on their good side!
4.3
4.3 out of 5
3 Ratings

Detailed Rating

Stars 5
1
Stars 4
2
Stars 3
0
Stars 2
0
Stars 1
0
7d72e9649e1aa9ce4c6796f9a097ee6d
30-Day Money-Back Guarantee

Includes

7 hours on-demand video
4 articles
Full lifetime access
Access on mobile and TV