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

Screen Shot 2016-07-05 at 11.48.31 PM

  • 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:

CkXuQWcVAAEtIL9.jpg-large

Or that this one isn’t even coherent:

CksP__hWsAAqqzQ.jpg-large

However, this automatically-generated creature is a cute idea:

CknJ5xzXEAEa6ba.jpg-large

This one might even have a valid role in some conceivable metagames:

Ck3DmFWUoAAED--.jpg-large

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?

Theory: Build a Knowledge Base

This article is interesting, for two reasons. First, it has some Kickstarter-related advice that might be of interest. Second, and perhaps more importantly, it has this to say about good design:

Pro Tip: Play a f*** ton of games before you try to design one.”

While I wouldn’t put it in those terms, I think the message is spot-on. Having a broad familiarity with games helps one avoid reinventing the wheel, and all the struggles along that path.

We’ve been down this road before

A lot of people have made a lot of games. That means that someone has probably at least attempted something similar to what you’re looking to do. In some cases, they discovered something your game would greatly benefit from knowing.

The current mousetrap

In some cases this might be a mechanical innovation that you could put to use. Magic: the Gathering, for example, left-right-left pattern of drafting to a huge new audience.*

(For those unfamiliar with Magic drafts, each player opens a pack, chooses a card from it for her deck, and then passes the remaining cards to the left. Everyone keeps choosing one card and passing until all the cards from all the opened packs are gone. Everyone then opens another pack, but passes to the right for this second round. Finally players go through a third round, passing to the left once again.)

The left-right-left approach makes card picking decisions much trickier than they would be in a left-left-left draft. For example, in a Magic draft a player might intentionally pass cards of a color he doesn’t want to play to the player on his left in round one. Hopefully the player to the left will focus on that color–and will therefore pass cards in some other, more desirable color to the right in round two. Since the left-right-left pattern makes “signaling” in this fashion important, and since signaling makes weighing one’s pick choices quite a bit more interesting, the left-right-left system has been widely adopted (see, e.g., 7 Wonders). If you’re making a card-drafting game, it’s far better to know about that pattern–whether you adopt it or react to it–than to spend hours upon hours figuring it out from scratch, just so you can get to the design stage that someone who’s drafted Magic cards would’ve reached immediately.

The dark paths

It might also be that your idea has been tried before . . . and didn’t work out quite as planned. Learning from past mistakes can save a lot of time and heartache.

One sees this at play every time someone says they want to create a new CCG. Immediately someone points to the endless ranks of failed trading card games. Each of them sought to recapture Magic‘s lightning in a bottle, but were brought low by some combination of complex packaging requirements, enormous distribution costs, overwhelming design challenges, and an inability to develop a player base large enough to generate useful network effects. Better to redirect the design early to a model that’s going to be more workable.

There are warnings to be found in the digital realm as well. Online multiplayer, for example, is exceptionally hard to implement. AAA studios have made it seem like a de rigeur inclusion–but of course, they have AAA resources. Smaller studios and independent designers have run into trouble after promising it, and might want to focus on single-player games while they build up money and expertise. Playing games with shaky online play, or where the “multiplayer” button has been greyed out since release, or even very successful games that have struggled with rocky launches (which is to say, just about every multiplayer game, even those with the backing of huge enterprises) might help developers realize that they should think carefully about whether and when they’ll commit to online play.

On the Shoulders of Giants

Playing lots of games doesn’t mean that one has to go back over old ground endlessly. Nor does it mean the accepted ways of doing things become constraints. Rather, knowing what’s out there makes innovation easier, by enabling one to know which design approaches are actually innovative–and which are well-trod paths, or worse, are rife with land mines. Don’t use play-for-research as a substitute for progress on your own work, but recognize the importance of that research, and make time for it.

 

*I’m not sure if the pattern originated there, but it may well have.