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.