Game Playtesting: the Heart of Game Design

Playtesting: when, how, why, what to do (and not do)
0.0 (0 ratings) Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
17 students enrolled
Instructed by Lewis Pulsipher Design / Game Design
$30
Take This Course
  • Lectures 69
  • Contents Video: 6 hours
    Other: 39 mins
  • Skill Level All Levels
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 2/2016 English

Course Description

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.

What are the requirements?

  • Basic knowledge of game design required

What am I going to get from this course?

  • 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

What is the target audience?

  • Game designers, especially those who are inexperienced or just starting out

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: Introduction
Instructor and Course Introduction (same as "Course Promo")
Preview
02:17
03:57

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.

03:40

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.

Voluntary, anonymous entry survey (10 questions)
Article
Section 2: What is Playtesting?
08:02

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.

10:56

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.

02:34

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.

04:50
The playtest and modify cycle is a form of engineering, or perhaps of scientific method.

From my "Learning Game Design" course.

02:55

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.

04:17

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

From my "Learning Game Design" course.

05:41

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.

08:43
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.
06:07

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.

03:57

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/

02:51

•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

03:33

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.

Exercise: practice what you're going to do
Article
Quiz 1: What is playtesting?
5 questions
Section 3: Arranging the Playtesting
09:55

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.

08:20

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.

05:44

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

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

3 pages

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.

07:34

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
Conventions: Protospiels, UnPubs, and "publisher speed dating"
06:00
02:00

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.

Quiz: Arranging playtesting
5 questions
Project: Arranging Playtesting
Article
Section 4: How to Conduct Playtesting
Playtesting Exercise
Article
09:34

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

09:41

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

03:08

•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

08:05

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.


06:38

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.

10:18

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.

05:39

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.

07:46

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!

06:13

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.

1 page
Handwritten (!) notes from a solo playtest of a strategic space wargame. This particular design has gone "swimmingly" (well, without major changes).
2 pages

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.

3 pages

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.

2 pages

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.

Quiz: How to conduct playtesting
5 questions
Section 5: How to use the Results of Playtesting - change, change, change, love it or fail
07:28

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.

06:54

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.

09:04

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

11:42

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

06:16

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.

03:23

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.




04:31

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).

13:21

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.

09:37

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.

07:23

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.

04:53

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.

07:13

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.

10:56

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.

6 pages

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.

04:15

•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

Quiz : How to use the playtesting results
5 questions
Section 6: Other Considerations when Playtesting
07:57

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

07:05

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

04:02

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.

07:21

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.)

03:42

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

05:04

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.

08:00

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".

06:23

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.

04:55
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.
4 pages

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.

Quiz : Other Considerations
5 questions
Section 7: Conclusion
What's Next?
01:17
"Bonus" Lecture about Lew's courses and activities
14 pages
2 pages

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.

Section 8: Bonus Materials
08:24

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…

04:40
What makes my game design book unusual or unique.

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Lewis Pulsipher, Commercially Published Game Designer, College Teacher

Dr. Lewis Pulsipher (Wikipedia: "Lewis Pulsipher"; "Britannia (board game)"; "Archomental" ) is the designer of half a dozen commercially published boardgames. His game "Britannia" is described in an Armchair General review "as one of the great titles in the world of games." Britannia was also one of the 100 games highlighted in the book "Hobby Games: the 100 Best". He has over 17,000 classroom hours of teaching experience including teaching video game design and production, and over 20 years of part-time graduate teaching experience.

His book "Game Design: How to Create Video and Tabletop Games, Start to Finish" (McFarland) focuses on practical advice for beginning game designers, about how you actually create and complete game designs. He also contributed to the books "Tabletop: Analog Game Design," "Hobby Games: the 100 Best," "Family Games: the 100 Best." His game design blog has been active since 2004, and he is a contributor and "expert blogger" on Gamasutra, the #1 site for professional video game developers.

His latest published game is the 2011 reissue with additions of "Dragon Rage," originally published in 1982. Three new versions of Britannia, including a 90-120 minute version and a diceless version, are forthcoming, as well as several other games from Worthington Publishing and others. His Viking adventure game "Sea Kings" was published by Worthington in August 2015.

Lew has a Ph.D. in military and diplomatic history from Duke University, from ancient days when degrees in media, computer networking, or game design did not exist--nor did IBM PCs. In 2012 he was a speaker at the East Coast Game Conference, PrezCon, Origins Game Fair, and World Boardgaming Championships. Long ago he was contributing editor for White Dwarf and Dragon magazines, and publisher of various game fanzines. In 2013 he was Industry Insider Guest of Honor at GenCon, and in 2014 is again speaker at the ECGC.

Game design blog and teach game design blogs are on blogspot

"Expert blogger", Gamasutra

former contributing editor, White Dwarf, Dragon, Space Gamer, etc.

former publisher, Supernova, Blood and Iron, Sweep of History, etc.


"Always do right--this will gratify some and astonish the rest." --Mark Twain

Ready to start learning?
Take This Course