Following up on last Wednesday’s post, I wanted to call attention to another article regarding Super Mario Maker. It’s got a lot of good design advice for those interested in using Super Mario Maker well, and for those interested in platformer design in general.
Link: GameMaker Humble Bundle
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
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
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!
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.
Theory: Learn from the Worst Game
Rudolf Wanderone, a professional billiards player, once said, “[y]ou don’t learn from smart people, you learn from idiots. Watch what they do, then don’t do it.” While that’s obviously not advice to be taken literally, there are certainly lessons to be learned from the worst games.
There are a lot of lists of “worst games” out there, and everyone has their choices. I’m a little older, so my #1 worst is a PC game from 1994. Everyone, please welcome . . . Outpost!
Outpost is a great game to study because it doesn’t just do one, critical thing wrong. Instead, it makes a bunch of mistakes, all of them different and potentially interesting.
Let’s dig deep on just one of them: the unguided choice of where to go. Early on the player is supposed to decide which star system to travel to—but as the review points out, the data meant to inform that decision is so opaque as to be useless. The player is thus reduced to picking at more or less at random and hoping for the best.
Experience garnered from many games shows that randomness can be entertaining. However, a single random event that can end the game if you get unlucky isn’t a fun implementation. Like a badly-done RPS mechanic, a one-and-done random choice that decides the game at its very beginning isn’t a good experience.
If that were the only sin Outpost’s early game committed, it would be damning. However, things only get worse when one factors in the promises mentioned in the video—that Outpost was to be based on real science, with the choice of where to go based on legitimate astronomy. Trying to live up to that promise likely ate up development time that could have gone into making the game playable. Certainly it built excitement that turned into disappointment when the game hit the shelves. Outpost established expectations, and then didn’t meet them.
Finally, consider the problem the review cites regarding the process of supplying your vessel: you don’t know where you’re going, so you don’t know what you need. What should be an important decision thus becomes an exercise in frustration, almost in being mocked. The game asks the player to make decisions based on information the player can’t possibly have or acquire.
Outpost gives us three examples of things not to do in the very first thing the player does. That’s a pretty good time-to-lessons ratio! If you’re looking for a game that can teach you what not to do, give Outpost a try.
Or maybe don’t. It’s terrible. Just read up on it. 😉
New Theme?
Since the Law of Game Design opened I’ve used the same theme. I like it; it’s functional, easy to navigate, and has a nice picture at the top.
Recently, however, I’ve been thinking about changing things up a bit. I’d like, in particular, to keep posts about the goal of this blog and the limitations of this approach visible.
Most of the themes that allow for that dispense with the tag cloud and category list, although some of them make it accessible through a collapsible menu. Would losing those be a concern for you? Are they useful tools?
More generally, would you like to see a redesign? If so, to add (or remove) what functionality?
Theory: Decisions about Die Rolls
Just a little thing I noticed: decisions about die rolls made before the roll is made are all about risk. They’re exciting and unpredictable.
By contrast, decisions made after dice are rolled are all about allocation. Optimization, rather than thrills, is the focus.
Theory: The Limitations on the Rules
I propound a lot of rules on this blog, and I present them as things you should always do. However, it’s important to recognize that they are not necessarily immutable or universally applicable. While I don’t believe rules are made to be broken, I do believe that they need to be properly understood—and that means giving due weight to their limitations.
One might reasonably ask why it is that game design rules aren’t as reliable as, for example, the laws of physics. I can see at least four reasons:
1. Game design rules are sometimes in tension, and so it might not be possible to follow all of them at once.
Wargames are called upon to provide reasonably accurate simulations of the conflicts they’re based on. That often means putting in some period detail. Fire in the Lake is a good game about the Vietnam War for many reasons, and among them is how it incorporates actual events and issues to create a you-are-there feeling.
At the same time, elegance is usually seen as an important design goal. Just as too much chrome is bad for the look of a car, too many special cases and deviations from the general pattern is bad for a game experience.
Top-flight wargames can balance these two considerations, detail and elegance, but they will always be in conflict. It’s just not possible for such a game to pursue either elegance or historicity to their fullest extents; doing so will prevent the game from achieving its broader goals. The design rules have to bend.
2. Sometimes you get more by breaking a rule than you do from following it.
League of Legends is arguably the most popular game in existence today. It also, as its VP of Game Design points out, breaks the rules sometimes. That’s not because League’s designers don’t know the rules; it’s because they recognize circumstances where they can get more than they give.
As a non-League example, think back to the Babylon 5 CCG. The B5CCG was probably “wrong” to have lots of off-card states to track. However, those states created levers cards used to impact the table-talk at the heart of the game. B5CCG broke a rule because doing so was important to that specific design.
It may be that this is just a subset of the previous situation; the B5CCG may actually have been following a rule (perhaps one as yet unelucidated) when it added meters that had to be tracked on a playmat. However, I think the question of “should I break this rule, given that I’ll get a lot of benefits” comes up often enough to deserve its own entry. If the cost-benefit analysis supports it, the answer is “yes.”
3. We know that some games break rules and get away with it.
An act that contravenes the laws of physics is going to have big problems, but we know from experience that games can break the rules of design and be a lot of fun. Maybe that means they’re following deeper rules than we’ve yet discovered; maybe that means the rules are mere guidelines. Either way, there’s clearly a limit to how much respect the rules of design are due.
4. I don’t know everything.
The fact is that I’m learning as I go. Sometimes I’ll have an incomplete understanding, and thus propound an incomplete rule; sometimes I may just turn out to be wrong. Rules are best when they’re made by the best, and I’m not there yet.
Try letting go
I like rules. I think they’re useful. I’ll even go so far as to say that I believe in their power and utility.
However, the rules of game design aren’t as ironclad as the rules of science. Perhaps that’s because they can’t be; perhaps we simply aren’t as far along in our understanding of them. Either way, it’s always worth keeping in mind that the rules may not be leading you in the right direction. Recognize their limitations, and allow yourself the freedom to—judiciously—break them.
Theory: Avoid Thematic Mismatch
We shouldn’t judge books by their cover, but we expect the cover to tell us something about what’s inside. Similarly, a game’s theme sets expectations about what it will be like. What’s more, just as we’re disappointed when a book turns out to be other than what its cover advertised, players are apt to be frustrated when a game’s play diverges wildly from its theme. It’s therefore important to make sure that a game’s experience and theme align, lest players be put off of otherwise good products because they weren’t what was expected.
I saw this issue crop up when playing Ryu. Ryu is absolutely plastered with dragons. There’s a giant dragon on the box, dragons on the player screens, even big dragon meeples! Everything about this game screams dragons.
Pause for just a moment and think about what you would expect to find in a game about dragons. Fire-breathing, maybe. Accumulating a hoard of treasure. Doing battle against knights.
Ryu has . . . visiting islands. It also features a simple economy (expressed through wooden cubes). One wins by building a mechanical dragon.
Not fighting with the mechanical dragon. Not breathing fire with the mechanical dragon. Building the mechanical dragon.
There’s nothing wrong with a building a mechanical dragon, and after playing Ryu I found that the game actually had some interesting things going on. A key dynamic in my play-through was acquiring enough materials to build sustainably without having so many as to be targeted by thieves. Judging when opponents would push the thieves into motion, and how to spend enough to avoid being a wealthy target while saving enough to maintain a critical mass of economic power, was interesting.
However, I couldn’t help but be disappointed as the game drew to a close. I had so very much expected excitement, and I got something awfully dry.
By contrast, Agricola’s box is very clear about what the game is going to be—a family-friendly take on farming. No one ever bought it only to be frustrated when the play didn’t match the cover!
Not every game is a thrill-a-minute affair, and those that aren’t are better off without themes that establish expectations they can’t meet. In the same way, pulse-pounding games will find it harder to attract their desired audiences with sedate art. Choose a theme that works with the game’s play; your players, and by extension you, will be happier for it.
The Law of Game Design 