Category: Game design theory

Theory: Maintain a Changelog

Posted on Posted in Game design theoryTagged , Leave a comment

Long projects have a way of getting away from you. It’s hard to keep track of everything you’ve done, and it’s especially difficult to remember why you did it. Those times are the reason to keep a changelog.

You might have heard of a changelog in the context of programming. If you haven’t, it’s just a list of what you did for each version of your game/program/whatever. “Version 3–Reduced player chits from three to two, increased food to five units/player” is a perfectly good changelog entry.

Just doing that much will be a big help to your design. If nothing else, it will help you reverse course when something goes wrong (and I guarantee you, things will go wrong). A summary of what changed from version to version makes it easy to undo changes and get back to a version of the game that worked.

To get even more value out of your changelog, include a brief statement of why you did it. “Reduced player chits from three to two to avoid stalemates” is a short statement, but it allows you to reverse course selectively. If you’re still having a problem with stalemates, you can undo just the change that was meant to deal with them and try something else. If you’re happy with the stalemate situation but something else is wrong, you can roll back everything else.

Adding that extra detail to your changelog will also keep you from making stupid mistakes (of a sort, I will admit, I’ve made 😉 ). It’s very easy to forget which changes responded to which problems. You can very easily undo or modify a change that you need to keep, simply because you’ve forgotten what it was doing for you. Being able to quickly reference the changelog and say “wait, this thing that’s about to be altered is doing important work” can save a lot of time going down blind alleys.

For an example of a good changelog for a tabletop game, check out the one Mantic Games just put up for its Warpath rules. Most changes include a specific statement of why the change was made, so it’s clear which ones are safe to fiddle with and which ones aren’t.

(Disclaimer: I’m a backer for the current Warpath kickstarter, but only for about $20 to get a couple of specific models to use for other games. I don’t need more stretch goals met. ;))

Keeping this sort of changelog is the kind of thing that will take a few minutes each design/playtest session, and will save you hours of completely unnecessary design/playtest sessions. I can’t recommend it enough.

Theory: Coding Lessons Learned the Hard Way

Posted on Posted in Game design theoryTagged Leave a comment
  • If you can’t say with certainty how many times a loop is going to run, it’s going to cause crashes.
  • There’s a limit to how many statements can be nested before code becomes unreadable. A three-deep nest is OK. Five deep is a lot. Seven is begging for errors.
  • Comment every function with, at the least, a brief statement of what it’s meant to do and what its arguments are.
  • Javascript will let you get away with anything. That doesn’t mean you should feel free to do everything. Stick to good form; it might not be interesting, but it will only break in relatively predictable ways.
  • Learn coding best practices, and force yourself to use them. Formatting, good use of functions, even proper variable naming–all of these will save you time in the long run.
  • “If you’ve only backed up in one place, you haven’t backed up.”
  • Don’t set code aside for too long; you’ll forget how it all hangs together, and lose time working back through it from scratch. Keep it current in your mind.
  • On the flip side, don’t beat your head against a wall. If you haven’t solved a problem over the course of a few hours’ work you’re not going to solve it in that session. Do something else for a while.
  • Coding involves working on the computer, and that can be distracting–not least because you’ve probably already got a browser window open to look at Stack Exchange or documentation. Be rigorous with yourself about not doing fun stuff when you should be working.
  • As a game designer you can solve technical problems in two ways: the technical route and the design route. If a technical problem is proving unmanageable, put your design skills to good use. Find a way to change the game so that it’s in line with your technical skills.

Theory: Definitional Questions, Out in the World

Posted on Posted in Game design theory, Legal happeningsLeave a comment

It’s tempting not to want to talk about “what is a game” anymore. The discussion in popular culture has become toxic; debates in academia take place in ivory towers that can seem divorced from the practical requirements of designers. We shouldn’t completely abandon definitional questions, though, as they do become important from time to time–as in England right now, where a judge is weighing whether Bridge is a “sport.”

The facts, as I understand them, are as follows: Sport England is an English government body that provides funding to groups that put on sporting events. It’s made the decision that bridge isn’t a sport; ergo, bridge organizations aren’t eligible for money. The issue before the court now is whether Sport England made a “reasonable” decision.

(As a side note: this is a very common approach to judicial review of decisions made by government entities. The court doesn’t ask whether the decision was right. Instead, it considers whether the decision was made using the correct process. So long as the process was OK–all the necessary steps were followed, and the decision was made in light of the appropriate rules–the court won’t get involved in whether the decision was good or bad. The court will only overturn if there was a mistake in the process, and even then the court won’t change the decision; it will just tell the government entity to go back and revisit the question, using the right process.)

Whether Sport England was “reasonable” will depend, in part, on whether it followed the rules about what kind of organization it can give money to. Doubtless those rules involve–perhaps even revolve around–a definition of “sport.” Lots of money could ride on a word or two’s difference in a formal definition of what’s normally a very informal idea.

It’s not always easy to work through definitional issues regarding games. Recently, even the exercise hasn’t been pleasant. However, we need to keep hammering away at the problems. Definitions are one of the interfaces between games and the real world. Poor definitions mean poor interfaces, with all the unpredictable and undesirable results that implies.

Theory: Make Concessions a Part of Your Game

Posted on Posted in Game design theoryTagged , , Leave a comment

Concessions are generally viewed as disruptive, and a while back I talked about how to discourage them. However, there’s a little-explored alternative: embracing concessions, and making them part of a broader strategy. Backgammon and Magic have both taken this approach, and they’re better for it. It’s worth exploring for your games, as well.

Magic has a problem as a tournament game: there’s a fair amount of randomness, and only limited time in which to play rounds out. If a player gets a bad draw in game one of her best-of-three series, she can end up losing valuable minutes in a match whose outcome isn’t in doubt. Those minutes might end up being decisive, especially if one or the other player is piloting a slow deck that won’t allow all three games to be played. It’s disappointing for tournament results to be decided by luck and the clock.

Fortunately, Magic has long since solved this issue. By allowing players to concede, Magic gives them the option of reallocating time that would be spent in a doomed enterprise to games that can still be won. Players can now focus on the interesting games.

What’s more, conceding goes from being aggravating misconduct to being a valid, accepted strategy. It can even lead to interesting choices; it’s not always easy to know whether it’s better to concede and try again or to play a game out. By accepting concessions and giving them a purpose, Magic fixed them.

Backgammon goes a step farther, making the possibility of concession important in every game, not just lopsided ones. Modern Backgammon is played with a “doubling cube.” At the start of your turn, before you roll the dice, you may offer the cube to your opponent. If he accepts, the amount of money or points at stake is doubled. The six sides of the cube mark the six times the stakes can double, going up to 64 times the original pot.

I’ve played a lot of Backgammon recently, and I can tell you from experience: the decision as to whether or not to concede is hard. Probability, the board state, the number of points at risk and how they compare to the number needed to win the tournament–all of these things factor into a single fold-or-raise decision. The choice is tense, vital to good play, and all-around fascinating.

Concessions are usually thought of as a letdown: a game was going on, and then it just ended. Magic and Backgammon demonstrate that they can instead be meaningful and even exciting. When you’re trying to concession-proof your game, give some thought as to whether it might be possible instead to put a bridle on concessions, and make them work for you.

Link: GameMaker Humble Bundle

Posted on Posted in Game design theoryTagged , , Leave a comment

After Wednesday’s post it might seem weird that I’m linking to the GameMaker Humble Bundle. However, the product on offer here is different from Super Mario Maker in three key respects:

1. GameMaker is a proper engine, not just a level editor. Even if you start from the position that level editors are subject to limitations, GameMaker doesn’t suffer from them.

2. GameMaker is great for beginners. The strength of GameMaker is that it’s simple enough to learn quickly, while still being powerful enough that you can make some engaging stuff with it. I’ve heard of academic game design programs that use GameMaker as part of their introductory curriculum, and I can understand why it’s their choice. If you’re at an introductory stage, GameMaker is a good option.

3. The bundle includes source code. Although GameMaker is as accessible as a serious engine can be, it still involves programming–and that can be a real hurdle to clear. Having solid, working code to start from is a tremendous benefit to those new to programming, and easily makes the higher tiers of the bundle worthwhile.

I’ve only used GameMaker briefly, but I’ve been impressed with what I’ve seen. I think you’ll be more than satisfied with what you get for $12.

Link: A Critique of Super Mario Maker

Posted on Posted in Game design theoryTagged 2 Comments

This article in the Washington Post raises an interesting question: to what extent is a level editor’s potential limited by the game it’s editing? Level editors are often held up as mechanisms for expressing creativity, particularly for those without coding experience. However, the original Super Mario Brothers offers a very limited palette of technologies and tools–and limited palettes are the least forgiving to work with. The difficulties people are having in improving on the original game suggest that Super Mario Bros.’ simplicity is making it easier to understand the editing process–but much harder to express creativity in an interesting, rewarding way, and to get a good final result.

Theory: Playtest from the Rulebook

Posted on Posted in Game design theoryTagged Leave a comment

It’s obviously beneficial to have written rules when your game is done; after all, “‘you’re not going to come in the box.”’ There are also advantages to writing rules early. However, it’s useful to have the rules written out in the “middle” of playtesting, when some general concepts have been laid down but much is still in progress, as well. Both the tests and the rules will benefit from having a rulebook.

Tests are more useful when run from a rulebook

It’s surprisingly easy to screw up a playtest by teaching the rules incorrectly. Since your rules are probably in flux, at least in the details, it’s entirely possible to teach the wrong version of a rule, or to forget a new addition to the rulebook.

When not caught these errors lead to flawed tests. In the best case you realize you made a mistake and re-teach the game, frustrating the playtesters. (That’s not much of a best case!) Often you’ll end up in the somewhat-worse case, where you detect the problem only after the game is done and the time was simply wasted. The worst case is the flawed test where you never realize you messed up the explanation; you have bad data, but you think it’s trustworthy.

Using a rulebook helps avoid these problems. The playtester reads the rules, and thus is exposed to all of them in their most current form. You don’t need to worry about carrying the burden of knowledge successfully, trying to track the rules and the questions you want to ask and the feedback you’re getting. The existing rules take care of themselves, allowing you to focus on questions and answers.

Rules are better when they’re first playtested with you present

It’s broadly agreed that blind playtests, wherein the players learn the game without the designer’s input, are important–and rightly so! However, a blind playtest with broken rules is only half useful; it shows you where the problems with the rulebook are, but the time spent actually playing is just lost. Playtesting the rules in the middle of the process solves that problem by giving you the opportunity to learn what the problems with the rules are, in an environment where you can fix them and rescue the mechanical aspect of the test.

Blind playtests are often understood as being conducted with the designer not even present. That’s the best way to do it—but it takes a while to get there, and if you do a blind test before that point, with bad rules, the players might realistically never get around to playing the game. Even if they do they’re quite possibly playing wrong, and the data you get is of limited value.

If you’re there you can step in when something’s going wrong, and make sure the game plays out according the rules. That doesn’t mean you should step in often; if you do, you won’t know where the problems with the rulebook are. It only means that when there’s an issue, you can note the necessary change and get valuable information out of the play.

Write early, write often

Having the rules written out is useful at every stage of design. In the beginning it’s helpful to you; at the end it’s primarily for your players. In between it’s great for both. Write your rulebook as soon as possible. You’ll be impressed with the return on the investment.

Build a Prototype! Right Now!

Posted on Posted in Game design theoryTagged , Leave a comment

Since you’re reading this blog, I’m betting you have a game knocking around in your head. I want you to go prototype it, right now. Not later, not Sunday afternoon, not next week. Right now.

The fact is that some problems won’t be identified at the theory stage. It shouldn’t be so, but it is, every time. None of us are so good at envisioning how a game works that we can see all the permutations that will emerge during play.

So too, some really neat elements that deserve to be expanded on won’t be found just by thinking a game through. Fun is, in part, a matter of aesthetics and experience. It’s not easy to predict where people will find it.

You might be thinking that your game is too complicated to prototype. I guarantee you that it is not. Figure out what the bare minimum elements of the game are—the absolute fewest things you need to get through the simplest possible turn. Mock those up and start.

Is the game intended to be digital? That’s fine. Put together a paper version anyway. It’s faster, and easier to make changes. Code has a way of locking you in that 3” x 5” cards don’t.

Playtesting isn’t just important for refining a game. It’s important for discovering what the game is going to be in the first place. Build the prototype and start making progress.