When game writers pitch story ideas to designers, they’re hoping for a good reaction. They want the designers to get excited about their ideas, to say “Yes! Brilliant! That sounds AMAZING.”

But that’s not always the reaction writers get. Maybe you’ve seen this in meetings: poker faces, crossed arms, frowns…

What gives? Does the story suck and they just can’t bring themselves to tell the writer the painful truth?

Nope! (Well, hopefully nope…)

Game designers are smart people. They’re thinking, always thinking. They’re visualizing their maps, they’re calibrating their systems, they’re troubleshooting their mechanics…they’ve got a lot going on.

And when designers and writers get together to talk about story, you can almost see the wheels turning in the designers' heads. They’re listening to the writers, sure, but they’re also figuring out what this could mean for the game. And sometimes it comes down to, What problems will this cause? Will this break my design? Do we have to do this?

(Which is not the reaction most writers want!)

But the designers ARE on the writer’s side. Like the writer, they want to ship a great title. They’re just problem-solving and troubleshooting. In their minds, they’re looking at parts of the game that the writer hasn’t seen yet.

And truly: game designers are brilliant. They can solve story problems you didn’t even know you had!

I’ve been lucky enough to work with some great designers over the years. Here are three best practices they shared to help us bring story and gameplay together.

(No last names, because these guys like their privacy.)

Best Practice #1: Let design break your story as soon as possible

I learned this from my friend Pete, who is BY FAR the most chill designer I’ve ever worked with. We only had a chance to work on one project together; I wish I could work with him on every project. He’s that good, and that fun.

And that jerk broke my story in half!

Here’s how:

We were working on a game based on an existing IP. So we knew a lot, going in: we knew who our main character was, what genre we were working in, and what the player fantasy was all about. All we needed to do was get started.

So we took a couple of days to work up our ideas. I came up with a storyline that I thought was fast, fun, and would stay true to the character’s badass persona.

When we got together for our first meeting, I drew a line down the middle of the whiteboard. On the left hand side, labeled STORY, I wrote out my main plot points, and I spaced them out based on my time estimates. “OK he’s going to get to town, crew up, establish a base and let everybody know there’s a new sheriff in town.” In my mind this was all setup that wouldn’t take more than 10-20 minutes, max. Then once we got all that out of the way ASAP, we could get to the good stuff.

Then Pete stepped to the whiteboard.

And on the right-hand side, labeled GAME, he drew out what goals the player needed to accomplish. Turns out all those elements I thought was just setup? That was core to gameplay. And the player was going to be invested in getting those systems dialed in, because it was going to define how they played the game.

So what took 10 minutes in my mind was going to take 2-3 hours in the game.

Which meant the story was going to be EXTREMELY BORING unless I changed things up pronto.

In a 30-minute meeting, Pete saved me from spending weeks, maybe months, doing work that would just end up in the trash.

He saved me from myself!

Best Practice #2: Meet the player where they’re at

This one I learned from Patrick, another brilliant developer. The signal-to-noise ratio with Patrick is amazing. Everything he says is on point.

We were working together on an open-world project, where the player could initiate conversations with NPCs at any time. The problem we faced was this: some players love story, some players don’t. But they’ll ALL need to talk to NPCs to find out what to do next in the game.

So how do we write interesting conversations for the story fans, without frustrating the players who just couldn't care less?

Patrick, of course, had a solution. He taught me a way of designing conversations so that players only heard what they wanted to hear.

Imagine you’re a mercenary in a foreign land, and you approach your handler to get your next assignment.

The handler/NPC tells the player that the man they seek is hiding in a nearby village. This is pure mission data, 100% gameplay.

For some players, this will be enough. They know what they need to do - Find The Dude - and they’ll run off. But some players will stick around and hit X - they want to hear more.

So the next line could be something about how there’s a ledger in the man’s home that lists all the bribes he’s been taking, and that you should grab it - it’s great leverage. This line is a 50/50 split between gameplay and story. You’ve been given an extra task to accomplish, and you’ve also learned something helpful about the world.

Most players will probably decide they’ve heard enough at this point, and run off. But SOME players are really into narrative, and they’ll want to hear more.

So you want to reward their curiosity with a good reveal. Maybe this man confesses that the man he’s betraying is his estranged brother! This has nothing to do with gameplay (as far as we know), but it makes the world richer and more complex for the story-nerd players.

Everybody gets a different conversation, and everybody likes the conversation they get.

Best Practice #3: Think like a teacher

This one comes from Designer X, who’s worked on some of the best games out there. He’s like a ninja, this guy. He’s the designer who just works quietly, never drawing any attention to himself, and then emerges with the best level you’ve ever seen. (He doesn't want me to even use his first name, so now he's Mr X.)

I was working on a story, and wondering how to integrate it with the tutorial. So I asked Monsieur X how he designs tutorials for a game. When is the player ready to leave the tutorial behind? When does s/he know enough to just play the game?

His answer surprised me. He said, “The whole game is a tutorial.”

But when I thought about it, I could see he was right. We’re always learning something new in a game - how to navigate a level, or use a new weapon, or unlock a puzzle.

When he designs a level, he’s thinking, “How can I teach the player what they need to know to win this game?”

I realized that while guys like Senor X need to help the player discover how to use things like mechanics and systems, writers like myself need to help the player discover things like character secrets and plot twists.

We’re both teachers - we’re just teaching different subjects. Kind of like Professor McGonagall and Professor Snape.

So there are a few things I've learned from designers over the years. Honestly, this is just the tip of the iceberg. Designers work hard to solve our problems as well as their own. They make our stories possible. They are our greatest allies! Even if we don't always see eye-to-eye.

Thanks for reading. See you next week.

Write great scripts with this free guide

Want to build up your writing skills? We can help. We've created an easy 5-step guide you can use to write scripts your players will love.

Best of all, it's free. Just click the button below!

Susan’s first job as a game writer was for “a slumber party game - for girls!” She’s gone on to work on over 25 projects, including award-winning titles in the BioShock, Far Cry and Tomb Raider franchises. Titles in her portfolio have sold over 30 million copies and generated over $500 million in sales. She is an adjunct professor at UT Austin, where she teaches a course on writing for games. A long time ago, she founded the Game Narrative Summit at GDC. Now, she partners with studios, publishers, and writers to help teams ship great games with great stories. She is dedicated to supporting creatives in the games industry so that they can do their best work.