October 17, 2010
So its been quite a while since I’ve posted on this blog, mainly because I’ve dived into development of a flash game (in fact, a polished version of my Ludum Dare entry). Hopefully I’ll be able to get back into posting regularly over the next few weeks (after which I’m going travelling, so things might be a bit more transient).
As I do more development, I’m starting to make some observations about the process of game development, in relation to the story-based ideas that I’ve blogged upon in the past. So what you’ll probably start to see are some posts that have a similar theme as before, but which are somewhat bent towards the development side.
Today, I’m wanting to talk about Portal and a potential pitfall in using this game as a guide to develop others. The game Portal remains brilliant: I stand by what I said in my analysis of the game’s success (if you haven’t read this, it’s probably a good idea to do so before continuing, as I’ll refer to some of the ideas mentioned within).
As I mentioned in that article, much of the sheer awesome that Portal resonates occurs because of the strong link between its gameplay story, and its story-story (or as Kim Swift and Eric Wolpaw put it, in its low ‘delta’ between these two stories). This ‘why’ is not the problem. The ‘how’ is.
When I say the ‘how’ is a problem, it’s not because Portal’s methods are inscrutable or difficult to understand: in fact, quite the opposite is true. Portal uses a system of duality to ground the gameplay within the story: individual test chambers represent levels which help you learn how to use the Portal Gun both as a player and as a character; the change of pace from training to utilisation is marked by a clear change in both environment and story as GLaDOS turns from trainer to opressor; the player and the character have an exact equality in knowledge and understanding at all points in time.
Portal masters this duality so well that it seems an obvious toolset for other games to utilise to enhance their story-gameplay links, and yet, it quickly becomes abundantly clear that this methodology is far from repeatable. For there’s really only so many games you can make where a large proportion of the story can be realistically confined to a training or experimentation meme before it becomes really, really old: not to mention the huge restrictions you’re placing on your story by doing so.
I don’t think it takes a huge stretch of the imagination to think that in making Portal, Valve had the gameplay worked out first, from which they developed an optimal story. The elements used produce a terrifically low story delta at an astoundingly low technological and interactivity cost, with much of the story being told pervasively, either through dialogue which doesn’t affect your gameplay or doodles of cake on the walls.
The result is a masterpiece which is incredibly hard to match: anyone taking the same gameplay->story development path will be hard pressed not to use similar elements and storylines while creating a story with a similarly low delta. If we’re to reach the same heights of story without the ‘oh, they’re just copying Portal’ feeling, the stories will need to be more complex, and we’ll have to be all that much more creative with story delivery.
In a way, Valve has successfully patented some of the simplest methods of creating an incredibly tight story-gameplay bond without ever applying for a single patent. The rest of us are left with a greater understanding of what makes a brilliant game, but are forced to challenge ourselves to create new tools to create them.
Which, at the end of the day, makes this an incredibly exciting time to be a game developer.