Sunday, May 19, 2013

May 2013 Miscellany

Thoughts about some game-related topics that are not long enough for separate blog posts.
As I read the rules for the 2013 Game Chef contest, the "self-plagiarism" component of this one struck me as bizarre:
"Rule on Previous Work
You may draw on concepts you have thought about or worked on before the contest, but everything you submit must be new work, not existing material. Plagiarism or self-plagiarism will get your game disqualified."

It reminded me of the education community, where "self-plagiarism" is regarded as wrong, and many teachers will flunk a student for doing it.
If you've done the work, why shouldn't you use it?  Both in a class, and in a game design contest.

Game Chef is a sort of "Game Jam" for tabletop games, conducted over nine days, and judged by the participants.  The games tend to be RPGs.
This year's contest starts 17 May.

This year I was at PrezCon, will be at WBC, will be at GenCon as an "Industry Insider Guest of Honor", will not be at Origins.  I didn't attend ECGC this year.

I will have games to playtest, of course.

I'm interested in talking with people about the nature of game design.  (Which can be really interesting, believe me.)  You don't need to be an expert, you don't even need to be a game designer, because the players are more important than the designers . . .

Convention seminars:
I'll be doing my usual talk at WBC ("Lew Pulsipher's Annual Game Design "Seminar").   As much as I can say (and hear) about game design in the time people want to listen (two hours plus, usually).  Since my book that's strictly about game design has been published, I'll focus more this year on the business of game licensing and marketing, including protection of intellectual property.  And a bit about self-publishing.   Thursday, 4PM.

At GenCon:  all in ICC 242
Game Design Business: Getting the Attention of Publishers 8/15/2013 7:00:00 PM
Game Design Business: Protecting your Intellectual Property 8/16/2013 3:00:00 PM
Game Design Business: Publishing (and Funding) 8/17/2013 1:00:00 PM
Of Course You Can Design a Game, But Can You Design a Good One? 8/18/2013 10:00:00 AM

I've been reading the list of over 8,000 events for GenCon 2013.  GenCon is a story convention at least as much as a game convention, and it may be instructive that it's much larger than other hobby game conventions in the USA.  Stories are good for marketing, always epitomized by my experience looking through game libraries at conventions.  Most of the games in game libraries are Euro-ish games.  Many of them are essentially abstract games with atmospheres tacked on.  But when you look at the game box, it's all about the atmosphere, you rarely learn much about the actual gameplay.  Because stories sell games, though gameplay makes people play games repeatedly.

Some college/university classes, like some games, are intended to be models of reality.  But as with games, the classes are often so far removed from reality, they can no longer pretend to be models.  They are abstract or purely theoretical.  In the best classes that are aimed at real-world jobs (not all are) you do things that represent what you'd do in the real world.

A brief review of my game design book is in ARBA vol 44 p. 16: (final sentence) "Although a single book cannot substitute for education in game creation or practice, this book provides useful tips and resources for game designers and those interested in entering the field."  This is another professional, subscription only, journal so I cannot provide a URL (I got a non-convertible PDF from my publisher).

 I've always thought it might be frustrating to be a Hollywood screenwriter, because the directors get so much more credit than the writers.  Yet even the best directors aren't going to make a good movie with a poor script.

I suspect the better directors are also better at recognizing good scripts and bad ones.  Are the "auteurs" in video games better at recognizing exceptionally good game ideas from lesser ones?

And this all seems to be muddied by the advent of "creative directors" in video game production.  The game designers appear to be shoved down to the status of mechanics adjusting bits of the game.


Monday, May 13, 2013

Giving Victory Points for Fighting Battles

Occasionally I hear about a game that gives victory points (VP) for fighting a battle (not even just for winning, just for fighting).

Why would you do that?  From a modeling point of view, what’s the virtue of fighting a battle, especially one that you do not win?  In the real world, fighting a battle is one of the dumbest things you can do.  Or as Sir Winston Churchill said, "Battles are won by slaughter and manoeuvre. The greater the general, the more he contributes in manoeuvre, the less he demands in slaughter."  And the best general is one who wins a war without casualties.

One reason to reward fighting that is common in video games, where the computer can easily track it, is that units gain experience, and ultimately gain new capabilities, through fighting.  Of course, you’ve got to survive to prosper.  And in tabletop games there is too much record-keeping involved in experience for individual units to make it practical. Still, that’s not victory points, it’s increased unit capability.

There are excuses for VP points for losing battles: it represents glory, causing fear in others, learning lessons that can be applied later; but then these should only apply to winners.  While we can argue that those who lose a battle learn more than the winners do, and this is often the case for a war as a whole, it is much less clear for individual battles.   You can’t learn anything useful if you’re dead or captured.

No, in virtually every case, I think, this kind of rule is added to encourage fighting where otherwise it may not be worthwhile.  That is, the gain in VP is worth the losses (physical and positional) when you lose a battle.

So why would a designer do it?  Awarding VP for fighting strongly implies that the game otherwise encourages “turtling,” that is, hiding out, staying out of battles, sitting on the sidelines, letting the other players beat each other up.  In other words, giving VP for fighting and not winning a battle is a kludge designed to save an otherwise flawed design.  (“Kludge” originally meant “a software or hardware configuration that, while inelegant, inefficient, clumsy, or patched together, succeeds in solving a specific problem or performing a particular task.”  But this term can be applied to game design just as well, just substitute "game design configuration" for "software hardware configuration".)

The most well-known game design kludge I can think of is in Risk, also to discourage turtling.  It’s the turn-in of territory cards for lots of armies.  Players must successfully attack at least one area to get a territory card, thus forcing turtles to do SOMEthing, to take at least one territory.  And no player can afford to stay out of the “card derby” because it yields (under American rules, at least) so many armies in the long run when you turn in sets of cards. 

Risk is hardly a model of the real world, but the card-play, in particular, has absolutely no correspondence to anything that happens in reality, it is analogous to nothing.  It is there only as a structural kludge.

The cards are also a kludge to bring the game to an end in a reasonable amount of time.  Without them, given the structure of the game, many games would last many, many hours.  With them, players can be wiped outn by the enormous influx of armies when someone turns in a set of cards, and the enormous reward for wiping out another player is that you gain his cards, which can lead to another turn-in for even more armies.

Now if you see a game design as just a collection of mechanics devised to allow certain things to occur, you might see awarding VPs for fighting as just one more mechanic.  If a game is abstract, this point of view is easier for me to understand.  But a non-abstract game is modeling some reality in some sense, and that's when this VP-for-fighting mechanic becomes an obvious kludge. 

So why the kludge to encourage attacking?  I think it’s because the rest of the game design is flawed.  What can a designer do to discourage turtling?

I discussed the turtling problem at length in the first chapter of the book Tabletop: Analog Game Design (chapter title, "The Three Player Problem") which is a free download at
  (the book consists of contributions from a couple dozen writers).

Briefly, you redesign that game so that it makes sense to fight despite losses that may occur.  Make what you gain from the battle more valuable, in the long run, than what you lose.  One way to do this is a zero-sum game, that is, you can only gain something if someone else loses it.  A turtle stays static while successful attackers get stronger.  Consequently, turtling doesn't lead to success. 

But even in a non-zero-sum game, if your gain is worth the losses - in the long run - then fighting makes sense.  This usually involves an economic game, often with a maintenance limit, that is, your economy must support existing assets before you get more, so the only way to increase your overall assets is to improve your economy.  If you can improve your economy peacefully, or improve it as much peacefully as you can belligerently, then you can turtle.  If improving your economy requires territorial expansion, you've got to attack, not turtle.  See my discussion of "The economic production cycle in games" at .

Extreme uncertainty about who is ahead in the game also discourages turtling.  Turtling only makes sense when the turtle can see that he benefits by hanging back.

In games that are primarily tactical rather than economic, but for more than two players, the tendency is for everyone to turtle.  Consider three or four player chess.  Unless the rewards for attacking are very great, the only smart strategy is to sit back and let the others kill off one another - because there's virtually no economy to allow creation of new units (promoting a pawn is the exception). 

Fortunately, most tactical games, and most games depicting a set-piece battle, are for two players (or two sides, which amounts to the same thing).  Turtling is rarely a problem in a two (or one) player game.

Design your game so that you don't have to use VP to encourage fighting.