Tuesday, February 23, 2010
Some Quick Thoughts
The shorter the game is, the more you can forgive.
Is there some sort of wonky rule in the game? Is the game not that balanced? Is it more of a luck fest than a game? Well, if the game's only 10 minutes long, then so what? Who cares? I mean it's only 10 minutes. If the game is an hour long, then it's a different story. (Sure I'm saying this partly tongue in cheek but, seriously, if the game is very short then it's much easier to overlook things that would be unforgivable in a longer game.) The next thought follows naturally.
The longer the game is, the more it needs to offer.
If you're playing a light game that could be classified as a filler, that's totally okay - but not if the game is a 2 hour long game. If people are going to see their time investment as being worth it, the game had better deliver if it's going to go longer.
As the number of internal bookkeeping processes in a game's design increases, so does the likelihood that the game should be a video game instead of a board game.
If there are lots of calculations or procedures where things are happening in the game that don't involve player choice, or perhaps the game has modifiers stacked on top of modifiers, then it's probably best that the game be made into a computer game so the computer can handle those bookkeeping tasks without burdening the players with them.
Looking for ways to reduce the number of components often results in simplified rules - which tends to result in better games.
Usually, more components equals more procedures and more rules. Otherwise, why would the components be necessary? Either that, or the systems for tracking information in the game are very inefficient and need to be streamlined. Either way, consistently trying to lessen the component density is a good habit to have. At the same time, this next thought should also be considered.
With respect to utility and clarity, the type of components used in a prototype matters.
If there is a marker that is going to be passed around from player to player and/or is one that needs to be easily seen from across the table, then using a small, thin, flat disc, is a bad idea. You would need something that's larger so it's easier to see and/or pick up. It's easy to think that this sort of thing doesn't matter but, if players get frustrated with simple, tactile aspects of the prototype, then that frustration will carry over into their underlying, general impression of the game. I'm not saying that a prototype has to be a Kinkos masterpiece to be playable. There are times when I've marked up a board with a Sharpie and then used that same board for more playtesting - but the board was still clear and it was easy to see what was going on.
Be willing to "cut your favorite scene".
Through the iterative process, game designs evolve and that evolution starts to take on directions as aspects of the game start to gel and other aspects do not. If there was some mechanic that was your whole inspiration for starting the design in the first place, but the design has now evolved such that that original mechanic is the very thing that's wrong with the game now, then be willing to throw that mechanic out. It's a better goal to make a good game than to just to make a game with some particular mechanic in it.
Make a prototype of your game idea before taking your idea to far.
Sometimes an idea comes to us and, in our minds, it seems like the best thing ever thought of. If one takes an idea and then adds other ideas to it, and then more ideas, and then more ideas without having actually put together a physical prototype first, then a person may find that their original idea had basic flaws in it and all the time they spent on coming up with subsequent ideas to go with the original were just interesting musings on an unworkable premise. Get the idea into a physical prototype of some kind (even if it's just post-it notes) before taking the idea too far.
Iterate A LOT before printing off a nice new board or a new rule book.
I mean, sure, if money is no object and you don't care about costs, then knock yourself out. I, however, have learned the hard way that thinking the game is done before it really is can get expensive really fast if you're not careful. At the same time...
Start writing a rule book as soon as possible.
Just like how making a physical prototype will clarify benefits and problems with an idea quicker than just thinking about it will, the act of trying to write a rule book will do the same thing. Thinking about how a rule should be worded, what terms are involved in the explanation, and which examples are important in illustrating to a new player how the game works will accelerate the design process by bringing to the surface potential flaws or areas of ambiguity in your game that need to be clarified. Granted, it will take a bit of playing around with the initial prototype and game structure before beginning a rule book is warranted. However, if a designer allows himself to go too far into the design process without requiring a rough-draft rule book of some kind from himself, then he stands to potentially waste a lot of time that could have been saved had he applied himself towards actually putting the current version of the game's rules down in some sort of readable medium. If how the rule should be worded is not clear to you, then perhaps the rule its self needs some examination.
I'm not saying go full throttle with a final version rule book early on. I am saying that at least beginning one - even just a designer having a rough draft as a Word document on his computer that he can go to and work on from time to time as he works through the iterations of his design - will help clarify fundamental thinking about a particular design in critical ways.
I personally find that trying to put my thoughts into words helps me clarify my thinking about board game design. That's partly why I put together these blog posts. : )
Update: I've had to shut down comments on this particular post because, for whatever reason, it was attracting lots of spam comments.
Monday, February 22, 2010
Themes and Implicit Promises in Game Design
I was reading some posts on a blog about video game design entitled "Theory and Principles of Game Design" by Adrian Lopez. Specifically, there was a short article he wrote about a "design flaw" in a basketball video game called "In Your Face" where he criticizes the "coin flip" animation at the beginning of the game because it's "cosmetic" - meaning the human player "always gets initial control". He said that this breaks the game's "implicit promise" to the player because what happens does not "agree with the player's expectation that a coin flip should produce random outcomes". (There are links to the articles at the end of this post if you want to go read more about some of his thoughts along these lines.)
These articles got me thinking. Specifically, with respect to the decision to play a game, when someone actively decides to sit down and invest time in learning a game that is supposedly about theme "X", but plays nothing at all like what one would expect a game about theme "X" to play like, then a virtual "promise" has been broken between the theme of the game and the player.
Usually, the more "rich" a designer wants a theme to be, the less abstract the game will be. This is because theme is often more fully developed with nuances in the game that reflect the narrative. The more nuances, the more reflective of the narrative the game play will be. However, the more nuances there are, the more "rules" there will have to be in the game in order to create a sufficiently diverse palette of game mechanics to reflect the theme to a degree that can be classified as "rich". If you want games very heavy in theme, one way to find them is to go buy one of the big-box games from Fantasy Flight. However, you'll also typically be buying a game with a much thicker rule book and with lots more exceptions to the general rules of the game for specific circumstances.
Take wargames as a genre as a further continuation of this idea that the more a theme is reinforced, the more rules are needed to support that reinforcement. With many wargames, the objective of the design is not necessary to create balanced game play. It's to recreate as much as possible a historical skirmish, battle, or war. To do that as accurately as possible, you'll see rules about landscape (with different rules governing different types of landscapes), morale considerations (with rules to govern them), different types of weapons (each with different rules governing how they work), etc.
Having said all of this, for Eurogame designers, this idea of thematic reinforcement can present somewhat of a problem as Eurogames are noted for their simplicity of rules and relatively streamlined mechanics. So, how does one design a Euro-style game without creating a "promise" that will be broken once a player sits down to play the game?I would argue that the better a designer gets at designing games, the more and more that designer thinks about ways to portray the elements and objects within his game as things that act on as much of an intuitive level as possible for the people playing the game. When people have to make huge "leaps" in logic in order to accept that something happening in the game is as the theme is describing it, then the flow of game emersion is disrupted and the fulfillment of the game experience is lessened. The same thing happens in movies when one watches an actor having to deliver very poorly written dialogue. When dialogue is identifiably bad, it will come off as phony. The cascading consequences of that are that the viewer is then immediately reminded that that is an actor on the screen, that the walls and objects in the scene are merely props, that the clothes are just costumes, and so forth. It pulls the viewer away from the story being told and reminds the viewer that it's all just an illusion. The same effect can happen with board games.
I think that one huge mistake a person can make in trying to design a Euro game is to think that it's okay to just put together mechanics and then try to figure out a theme in the aftermath. I think that a commitment to consistency within a theme will tend to drive the mechanics towards more interesting interactions than would an approach that is purely mechanic based. Thus, if someone has a cool idea for a mechanic but not a theme, my first suggestion is to commit to a theme before going much further with the mechanical development. Otherwise, you could end up with a game that, though interesting, unfortunately breaks its promise to new players once they actually start playing it.
Here are the articles I was talking about:
http://gamedesigntheory.blogspot.com/2007/09/design-flaw-in-your-face.html
http://gamedesigntheory.blogspot.com/2007/09/game-design-questions.html
http://gamedesigntheory.blogspot.com/2008/01/cause-and-effect.html