Just a few interesting notes about controllers from recent playtesting:

1. People will continue to attempt to use the first controller that works with your game, even if it is no longer functioning. It is very important, therefore, not to switch from the keyboard to a mouse, or from a mouse to a console controller, etc. Keep the player using one controller from start to finish.
2. Players don’t necessarily explore to find out whether there are controls available beyond those they are aware of. They might push all the buttons on a controller, but that’s about it–and if a button doesn’t have a function at that moment, they probably won’t come back to it later. Don’t assume that the player will learn all of a game’s controls without instruction/tutorials/etc.
3. Players will do things as fast as they can, not as fast as they need to. If you want players to do things slowly–e.g., in a rhythm game–you need to incentivize the pace you’re looking for, or find some other way (for example, visual and sound design) to lull them into a more restful pace.

I’m a bit behind on this one, but the talks from PRACTICE 2015 are now online. There’s a lot of amazing stuff there, including Brian Moriarty’s incredible history of interactive fiction, Ben Ruiz’s masterclass on attack animations, and Jeff Mishtawy on balancing Nascar races. Meg Jayanth’s keynote was also remarkable; I was particularly struck by her discussion of how players feel themselves in control even of entirely out-of-control situations.

Check the videos out when you get the chance; they’re fascinating, and well worth your time.

Work with designers who aren’t like you. Designers who share your interests and background are fun to team up with, and you can learn a lot from them, but there are some barriers you can only break through with the help of someone who has a very different perspective. Find people who like games you don’t (or that you think you wouldn’t), people of other genders and ethnicities, and design games with them. The lessons you’ll learn are irreplaceable.

Injecting a sense of narrative into a game can be as simple as combining uncertainty with inevitability. People like to find stories in events, and inevitability helps them see stories in the games they play; if the game is drawing closer to a defined end point, players will naturally begin to see a narrative in the way the game approaches its conclusion. Uncertainty keeps the excitement going while that story plays out.

However, those aren’t the only tools designers have to create narrative in games. For example, stories (in some traditions, at least) follow a three-act structure: an initial period of exploration and preparation, a second act with lots of conflict and danger, and then a headlong rush toward the final reckoning. A game’s mechanics can be used to imitate that structure, such as by organizing cards so that they have noticeable quantum leaps in the danger they pose to players, or by situating resources on a map so that there are natural stages in the players’ conflicts over them.

You can even try something weirder. At one point this semester a group I was in considered a design wherein whole new mechanics would be introduced to mark act changes. That particular concept didn’t make it into the final game, but I think it’s a neat concept, and it’s something I’m sure I’ll return to as a way to ratchet up tension and create a sense of progress as a game goes on.

About mid-semester I was told that a game seemed “flat”–every turn was like the last until the game ended. In games as in soda, flatness is bad. 😉 Create drama and narrative by making it clear that the game is advancing toward a conclusion, keep the result uncertain until that conclusion is reached, and do whatever else the design permits to bring the feeling of a story to your games.

There’s a lot of amazing scholarship about games. New ideas, fascinating perspectives, important principles: they’re all out there, in the DiGRA library, in Game Studies, even in good old-fashioned print.

What’s more, this isn’t ivory-tower material. It’s relevant to the day-to-day work of game designers. Thoroughgoing studies of the nature of play help us find new ways to bring fun into games; in-depth discussions of Orientalism in games help us see how everything from art to level design can play into stereotypes. Scholarship informs our processes, and by doing so aids in improving them.

It’s worth tracking down the major works in game studies, and it’s further worth keeping up with the field. The theoretical work in this area is both interesting in its own right and valuable in application.

The physics engines bundled in with modern game development IDEs are incredibly powerful and convenient. However, they’re also expensive in terms of processor cycles, and they tend to lock you into default behaviors. If you don’t need the full capabilities of a physics engine, you’re better off coding your own solution.

It might seem strange not to take advantage of built-in functionality, but most games don’t need true, complete physics simulation. Platformers, for example, are most likely satisfied with simple collision detection. Mario needs to know if he’s touching an enemy, the ground, or a block, and that’s about it. Similarly, FPSes need to know if bullets are occupying the same space as targets; they probably don’t require, or even want, realistic simulation of objects moving in three dimensions. The things these games actually benefit from can be accomplished with very simple code that doesn’t implicate the enormous complexity of a fully-fledged physics engine.

Programming just the physics bits you need has two key advantages. First, it’s easier for the computer. There’s no good in wasting processor cycles on unimportant calculations; that irks people with strong machines, and cuts out those with older computers entirely. Efficiency might not seem like a bit deal in an era when many laptops have discrete GPUs, but there are potential customers out there who will care.

Second, programming your own physics systems lets you control them precisely. Commercial physics engines aren’t appropriate for every project. They come with their own assumptions, defaults, and, well, quirks. Making your own collision detection or gravity allows you to make assumptions, set defaults, and choose quirks that will be ideal for your particular game.

Physics engines are often great–a boon to design. However, that doesn’t mean you should adopt them blindly and use them whenever you’re doing something vaguely physics-y. Building the (probably few) physics elements you need can offer substantial gains in both efficiency and control over your design.