Writing for Video Games (Steve Ince)

Screen Shot 2017-08-04 at 9.30.21 PM.png

Writing for Video Games by Steve Ince came out in 2006. It’s primarily directed at a skilled writer from other media who is considering a move to video games, so it includes a bunch of introductory material about how games are different and what game genres exist (2006-inflected and a bit simplified). Elsewhere, he introduces concepts like story bibles and character profiles, and warns about the challenges of working with a large team. For people seeking these tips about how to work functionally in a game industry team, though, I’d recommend more recent resources like Evan Skolnick’s Video Game Storytelling.

I’m not sure that, if I were a novelist encountering this book, I would be terribly encouraged by the prospect of moving into games writing. Ince warns the prospective writer that interactive narrative is always secondary to gameplay in all types of game, and also indicates that typical games aren’t very well written.

On narrative structure, he tends to be a bit absolutist — that branching narrative is “impossible to create” as “the resources needed to offer all these possibilities would be beyond the budget of even the largest game”. He does suggest some of the traditional alternatives, but the usual narrative structure resources (Ashwell on CYOA, Salience/QBN discussion) cover more territory.

The discussion of dialogue similarly focuses on the need to use variables and if-conditions, fairly basic concepts without a dive into the more systematic ways of handling this kind of information. This probably is helpful if the writer has never had to think about branching and dependencies before — and Ince does elsewhere talk about things like avoiding repeated dialogue, not reusing your punchlines in a comedy, etc. — but it’s not the place to look for guidance in new ways to design and organize interactive dialogue.

Ince also has a tendency to withdraw into general advice (meet your deadlines, make your story and gameplay line up, talk frequently to the development team, listen to the testers). This advice is typically correct but a bit basic.

Overall: not a terrible set of guidelines for its intended audience, but it’s brief, introductory, and now a bit dated (hardly its fault — I’m the one who decided to make as comprehensive a survey as I could).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s