Unfortunately the ongoing process of getting ready to be back in New York City full-time is still preventing me from doing much in the way of design. However, not everyone is similarly roadblocked! Check out this paper, a mathematical study of design issues in high score games.
Category: Game design theory
Portfolio Updates
A dream job was posted earlier this week, so I’ve been doing another round of portfolio updates here and on the Game Center’s website as I put my application together. Feel free, as always, to take a look!
This Friday I’ll be off to a wedding; I’ll get the post ready tomorrow so that there are no delays in updating. Expect it to be a prototype of a new game.
Lest there be no game design thinking in this post, I’ll leave you with Frank Lantz, director of the NYU Game Center, talking about Pokemon Go.
Theory: Don’t Get Captured by Game Feel
There’s an interesting difference in decisions in video games versus those in tabletop games—one with huge implications for designers. Choices on the tabletop are usually discrete; we can quickly identify the exact point where the choice is made, and so it’s relatively easy to ask whether that decision was complex, deep, etc.* By contrast, we emphasize the “feel” of video games because that’s a sensible way to evaluate the many little decisions that go into playing most digital titles. One of the challenges in designing video games is zooming out, locating the decisions that really matter and making sure that they’re as rich as those of a good board game.
We tend not to ask whether video game decisions are difficult or interesting. That’s not surprising, because most of the choices one makes when playing most video games aren’t. I want Mario to go left; to achieve that, I hold down the left button (or hold the joystick to the left, etc.). A huge number of decisions go into that movement, since I am constantly making a binary choice between holding or letting go, and it’s not always easy to be sure which decisions among the infinity of little ones are really impacting the player’s success.
Tabletop board games work differently. The moment-to-moment is abstracted away. Every decision the player makes is weighty. Choices are limited in number, and their import is clear.
Unfortunately, the challenge involved in figuring out just where the big, meaningful decisions are in video games sometimes means that we don’t ever get around to locating them. As a result, we never check on their quality. We get caught up in polishing the infinite tiny choices—an important thing to do, given how many there are!—and fail to ask which ones are the most meaningful, or how meaningful they really are.
I ran into this issue personally with my most recent thesis prototype. Many hours in, having carefully picked out suitable 3D models and hooked up animations and tuned the movement speeds, I realized that the game wasn’t any fun. Early on the player made one choice, and then spent a long time executing that choice through a bunch of movements that had great feel but weren’t significantly changing the game state. If the player’s single important choice had been made correctly, she was rewarded with a power-up which effectively reset the game. To put it directly: the player got to do one meaningful thing, and if she did it well, she was rewarded by having it invalidated!
Several playtests later, I think the problem is (mostly, hopefully) resolved. Alas, I could’ve been here sooner had I begun by considering, not game feel, but the number and quality of interesting decisions I wanted the player to make. Emphasize sifting out and evaluating the truly meaningful decisions in your video games; they’ll be better for it.
* Answering that question might, of course, be very hard!
Link: Shigeru Miyamoto on Game Feel
First and foremost, my apologies for the update schedule last week. I thought I had resolved all of the issues involved in posting while traveling; I was mistaken. Next time I’ll just queue up some posts rather than try to get them online while on the road.
While we get back on a reasonable schedule, check out this interview with Shigeru Miyamoto. It’s hard to find a more compelling argument for the importance of game feel than the image of playing the original Super Mario Bros. with a block on the screen, completely focused on trying to get the jumping to be compelling.
Little Lessons
- Maze-like levels get more interesting when there are plenty of paths through them. Dead ends create binary spaces where the only options are “there’s no enemy here, everything is fine” or “an enemy blocks my exit, I’m doomed.” Interconnected areas invite maneuver.
- If you want the player to interact with the antagonist, the antagonist must be where the player wants to be. Otherwise, the best strategy is always to go where the antagonist is not. In the picture above, the waypoints the knight uses for its AI pathing are not particularly close to the piles of gold coins the player-dragon wants to dig through; this means the player can usually dig in near-complete safety.
- Even a little bit of power can be very exciting. It’s not necessary to immediately ramp the player to a balance-destroying level, even if the thrill of powering up is a goal.
- Always keep in mind why you made a decision in the first place. When a technical problem forces you to revisit that decision, don’t jump to the most technically feasible option. Remind yourself why the design was as it was, and ask how you can get that same result.
Theory: The Hard Part
When I first started learning about game design, it seemed like there were new revelations every day. By now, the low-hanging fruit is gone. I still learn things every day–but the lessons are narrower.
It’s possible to do a double-sided single 3D plane in Unity, but it requires writing a custom shader, or at least customizing an existing one with the “Cull Off” command.
Git and SVN offer much the same basic functionality, albeit under different names. Many of the best practices for using each are the same.
Adobe has a great collection of color swatches here.
So much of doing good work, in the law or in game design, is in the details. These lessons aren’t as sweeping as the early ones, but these smaller building blocks are valuable–they fill in gaps that could otherwise show through in a final product.
Link: Mark Herman’s Inside GMT Blog
I was happy to learn that Mark Herman, an award-winning designer with decades of industry experience, has a blog over at GMT Games. Some of the posts are play-by-plays that will probably be of most interest to those with experience of the games in question, but others take a broader look at design issues. Read his posts through when you get a chance; Mr. Herman’s knowledge is an invaluable asset to the game design field.
Theory: Computerized Brainstorming
There’s something to RoboRosewater. It’s fair to say that this isn’t a great card:
Or that this one isn’t even coherent:
However, this automatically-generated creature is a cute idea:
This one might even have a valid role in some conceivable metagames:
While one clearly has to take the good with the bad, I think the interesting aspect of RoboRosewater is that it’s at least capable of putting together cards that are interesting. Its cards suggest weird possibilities that might be worth following up on. For example, I wouldn’t have thought of representing your creatures’ negative effects on opponents’ creatures with bonuses rather than penalties if RoboRosewater hadn’t tried it, with very thematically satisfying results.
I can imagine this sort of tool being useful for many games that use exception-based design. We humans can have trouble getting out of our own heads in order to find new and interesting exceptions. Computers, though, can do it easily. For a game that’s going to be around a while, it might be worth designing a script that can toss out new player powers and the like.
Theory: Test Decisions in the Right Context
Some small percentage of interesting decisions are always going to be fun. Some interesting decisions never are. Most, though, are fun only when given a context in which they can shine. It’s vital to understand what situation a decision needs, and to test your game accordingly.
Many well-known, big-budget games have decisions that work as gameplay specifically because of how they’re presented. Choosing where on the screen to click with a mouse, for example, is completely trivial in a turn-based environment that allows the player to take as much time as she wants. Yet, that activity supports the entire FPS genre, because it’s not at all easy to click just the right spot under extreme time pressure.
Fighting games are of the same ilk. Lots of fighting game decisions are easy once the player understands the game (“I should parry this projectile, that’s strictly better for me than blocking or jumping”). Others are more-or-less math problems: there are two options, with the first having a higher expected value than the second. On paper, the player alway makes the right choice. When one has to find the right move in a sixth of a second, doing the math or executing the correct action is a lot harder—and the difficulty helps turn what would otherwise be a trivial exercise into a tense journey through donkeyspace.
Both of those examples rely on time limits, but there are other contexts that can affect whether a decision is interesting. While in school, for example, I worked on a game loosely based on regattas. Players formed teams, and then teams rowed against each other to win a race. We were to discover the hard way that that has the potential to be interesting . . . so long as the game isn’t an entirely cooperative game about rowing in tandem.
If you’ve ever been out on a boat yourself, this probably doesn’t surprise you. Rowing can lead to beautiful scenery, it can be a kind of moving meditation, one can use it as a social event. It’s unusual, though, for the actual act of rowing to be intellectually challenging. We struggled for weeks to build a system that would make coordinating a team of rowers fun in and of itself. Two weeks went by with the team rowing boats using different systems, just by ourselves without any opposition, searching for a way to turn that into a fun puzzle.
Mercifully, that process ended (as is so often the case with design problems) when we gritted our teeth and took our not-really-working game out to playtest. The results were dramatic—it was great fun! Players enjoyed it, we enjoyed watching them play, everyone had a good time. What had happened, to bring about such a remarkable change?
All we did was change the context in which the same decisions were made. Throughout our internal design work we played a cooperative slice of our cooperate-to-compete game. In doing so we put all the weight on the puzzle, and the puzzle couldn’t bear the load. It wasn’t deep enough to be a game unto itself.
A competitive environment, on the other hand, made the relatively simple puzzle we had built deeply rewarding. It was hard enough that players sometimes made mistakes, and those mistakes now existed in a context where they mattered. At the same time, it was easy enough to allow for successful cooperation more often than not, and players enjoyed solving each turn’s puzzle in order to progress in the race. Competition made the exact same mechanics fun.
Our game didn’t have the wrong decisions; we’d just been testing those decisions in the wrong context. If you can predict that your game will work best when certain things obtain, be sure to test in that context. It’s worth saving those two weeks of heartache!
Good Uses of AR?
I’m currently assisting in the development of a game that edges into the realm of augmented reality. That experience has made me curious about the technology, which I must admit I have up to this point done very little with.
Are there AR games, apps, or activities that have particularly impressed you? I’m familiar with AR applications that, for example, make a 3D model appear when the camera focuses on a particular image. What else have you seen AR do? How have you seen games incorporate AR into their mechanics?
The Law of Game Design 