Getting it Wrong
From a recent post by Yehuda with some simple but important advice: how to recognize hack game design. Too many games, digital and non-digital alike, fall into at least one of these traps. As the designer of more than thirty quick game designs on this blog, I am well aware of the easiness of hacking a design. And, as a student, I see these flaws glaring in many of my fellow students’ work. However, I submit that this is not their fault, and nothing to be ashamed of. They are inexperienced designers, and they have to start somewhere. I certainly count myself among these — I am not a professional (yet) and by forcing a new design out of my head each week, I have no doubt that some of them are utterly worthless, awful games. I value these failures above all others, because this is how I learn. Failing and then having to fix your failure will teach you better than anything how to avoid that mistake again, and being able to recognize the hack spots in your design is critical to this process. It’s no good to have a broken game and no idea why it won’t work. So, if you’re like me and trying to grow and improve as a designer, read what Yehuda has to say and make a checklist for yourself. Study games you play and look for the hacks. Little by little, you’ll learn how to avoid getting it wrong 
3 Comments
This entry is filed under Game Criticism, General.
You can also follow any responses to this entry through the RSS 2.0 feed.
Or perhaps you're just looking for the trackback and/or the permalink.
RE: The list itself. It seems like the article was written by a very technically minded game designer. He has some good points, but he also throws out some good design because it breaks technically minded game design.
RE: Points 1,2, and 4. Randomness is not bad, luck can be good, it just has to be used correctly. Specifically it can let lower skilled players win sometimes and it can make the excitement of last minute comebacks a possibility. This can be (and often is) a good thing! Sometimes you want to make a game of pure skill and that’s fine, but it’s not a hack if you don’t.
RE: Points 9 and 10. Theme is not the enemy. Yeah, don’t prop up your game with your theme, and always be willing to sacrifice realism for good gameplay, but to completely relegate theme to the backburner and you might make a great game but it won’t catch the eye or the imagination. And while you don’t want to break gameplay for theme, sometimes it is appropriate to build it around the theme, and doing so is not a hack. (to be fair, he didn’t say theme is completely unimportant, but it felt like these points were a little too mechanics centric to be given a free pass).
The rest have generally good points, but I can’t say the entire list is something I’d agree with.
Your post though, for sure. Fail early and fail often (and then eventually stop failing…). If you’re doing something new though, which most game designs aim to be, you’re going to be treading new ground. Recognizing quickly though when you’ve failed and learning from that failure, that’s where a good designer stands out.
Excellent points, and I don’t disagree. I can’t speak for Yehuda, but from my experience with his writings I know him to be an insightful critic. I’m confident that what he meant to warn against was over-reliance on any of these constructs as the core or mainspring of the gameplay. I certainly appreciate the careful use of many of these in my games — the danger is becoming overbalanced and relying on it entirely. As you say, luck makes a game more interesting and accessible, and can save an otherwise tedious experience. The other side of that is that a game that features too many luck-based decisions will grow tiresome just as quickly as one with no luck at all. The key is moderation in all mechanics
Like in Yehuda’s example about math-based choice, his wording suggests that math is not inherently bad design, but rather the construction of a math-based choice that always produces the same outcome is bad. That is not a choice at all, and definitely poor design. I’d say the salient point of the piece is that game design is a tricky art, and that each of these ten elements must be used carefully and skillfully. Thus, the list serves as a guide to likely problem spots in your game, and how to tell when you’ve overdone it.
I also see it that way, the problem isn’t really the points itself, but the reliance on each one of these alone.
Despite the fact that we can infer this workarounds for each one of these points, I think it would be a nice idead to publish a list of 10 ways to address these design flaws.