Plotting Talk

I gave a talk on plotting last night at a meeting of York Writers. I was pretty nervous, as many of the writers have been published, and wondered how they would take what I had to say. Thankfully, they all seemed to enjoy it and it fired up some interesting discussion afterwards, which resulted in us running over the normal meeting time.

Because of my years of game development experience, the first part of the talk was about how stories work in games and how we approach the creation of the stories to ensure that they are sound, logically. The second was how I'm bringing some of those techniques to bear for the novel that I'm writing in my spare time.

If I get the time, I may turn my notes into a Developing Thoughts article, though it may be better as a couple of articles. I shall let you know.

Developing Thoughts 24

Interaction Density

I came up with the term “Interaction Density” when I was part of a long forum discussion on the way there are no adventures targeted at 8-13 year old boys. Why did the likes of “Day of the Tentacle” and “Monkey Island” appeal to this age group when they came out, yet today’s adventure games fail to do so?

Some of the answer lies in the fact that adventure games no longer have that element of fun about them that they once did. Where are the talking skulls, the spitting contests, the tentacles trying to take over the world? Where is the grandiose sense of adventure written big, with jokes and dialogue to match? Some people are of the opinion that the answer lies in recreating the style of the old games and everyone will be happy, but that fails to take into account the changing nature of the game market.

There is another aspect to the problem that has only come about in recent years since the CD became commonplace, the lack of high Interaction Density.

Back when games for the PC and the Amiga came on floppy discs, space was short, so every location was made to earn its keep. On each colourful screen existed a veritable plethora of fun characters to interact with, objects to pick up and hotspots to examine, along with the regular puzzle-solving gameplay. In other words, there was always lots for the player to do in each location – the high Interaction Density ensure that the player shouldn’t become bored.

This thread over at the Adventure Gamers Forums caused me to think about why today's adventure games might not be attractive to 8-13 year olds (boys, mainly). Aside from the fact that very few of them have the pure fun element that older games like Monkey Island or Day of the Tentacle, most of today's adventures have a low Interaction Density.

Because older games had to make the most of limited floppy disc space, particularly on the Amiga, each location in an adventure was made to work hard for its keep. Each screen was filled with wonderful characters, objects to collect or interact with and hotspots to examine. Now, with the ability to cram ten times (or more) the number of locations onto a CD or DVD, even at very high resolution, the number of interactable items on each screen/location has reduced for the same amount of gameplay. The Interaction Density has decreased drastically, to the point in some places where there are strings of locations through which all the player character does is walk.

Game players of all ages don't simply want to wander around, particularly young kids with notoriously short attention spans, so when there is little to interact with, the natural conclusion to draw is that adventures are boring and not worth bothering with. Action games, in comparison, offer an almost constantly high Interaction Density and are always going to be a better draw to gamers who want to be always "doing stuff" in the games they play.

Clearly, the time has come to address this balance by thinking more creatively about the layout of adventures so that they offer the same level of Interaction Density they used to.

© Steve Ince, 2005

Developing Thoughts 23

Back-Story

No, this isn’t the story of how I’m in constant pain with my bad back. But now that I’ve brought it up, I wonder how much sympathy I can garner from mentioning the stabbing pains that run up and (That’s enough, Ince. Get on with the column, you pathetic wimp – Ed.)
Ahem.

Back-story falls into the same category as character profiles – you can write and design your game without it, but it will be so much richer if you’ve taken the time to develop it well.

The back-story should cover anything and everything that leads up to the events of the story covered in the game. Because the game world itself regularly contributes to the experience the player enjoys, details of how the game world came to be should be a major part of the detail.

You may have already chosen to include each character’s personal back-story into the character profiles, but this shouldn’t stop you looking at how the characters fit into the overall back-story. As already mentioned last week, the character profiles enable you and the team to get a handle on the characters themselves – what makes them tick. The back-story enables you to get a handle on the game as a whole, the story that unfolds and the world in which it all takes place.

Many elements of the back-story have a direct bearing on the game’s story and gameplay. Sometimes this is revealed as important clues or information the player discovers as he progresses through the game; sometimes it’s just background that adds to the flavour and richness, but has no direct influence on the story.

The development team should always know more about the world than they ever expect to put into the game. Some material may exist just to help the writer approach a particular scene in a way that makes it more believable.

One such instance is a scene in Broken Sword: The Sleeping Dragon. Petra is holding a gun on Nico and suggests that they have met previously, but doesn’t enlighten Nico as to when that was. Here is a detail that, though created, was not fully revealed. Not only does it refer to a time and place outside of the current game world, it also adds a mystery as the player puzzles over this. If there are further sequels, more detail could be revealed, but for the follower of the series, thoughts about where it could have happened in the previous games (if at all) abound.

In a similar manner to working up character profiles, develop your back-story with a view to creating detail and answering questions about everything that has a possible bearing. What is the history of the weird race of cats? How did the zombies arrive on the strange moon? What is the story behind the gold artefact found at the bottom of a Scottish loch?

Unlike character profiles, it is not possible to break down the back-story into a series of headings to be filled in. Because the nature of your story is likely to be unique, the events that lead up to it will also be unique. Each game will have its own back-story, its own way of pulling everything together to make the story much more rewarding.

Don’t be afraid to be quite open in your inventiveness – providing you maintain a consistency with your world. I don’t have a bad back, but it would have made the story of the way I sit here and type these words so much more interesting if that were the case. The thought of a writer suffering for his art somehow seems more in keeping with a stereotype image.

However, I’ll leave it for you to decide if that should belong in my character profile or my life’s back-story.

© Steve Ince, 2004

Developing Thoughts 22

Character Profiles

Part of my current job involves creating the character profiles for my client’s project. Now, I can’t go into the specific details of what I’m doing (for obvious reasons), but I thought I would reflect on how important it is to do this work. Although I’ve already discussed characters, in an earlier column, this edition deals with the profiles themselves.

Of course, you may think that if you’re the only one working on your project, character profiles are not important – you know what your characters will do or how they’ll behave in a given situation. However, while that may be true for a few main characters, it’s unlikely to be the case for all of the characters you’ll likely need in a story-based game. It’s equally important to develop proper character profiles if you are a team of one, or part of a team of fifty.

Not only do character profiles act as a means of recording your thoughts on your main characters – how they behave and react – they also serve a fuller purpose of helping you work through the details of your supporting characters. The process of developing the profiles allows you flesh out the characters and make them much more rounded.

You may wonder why this is important for supporting characters, but if you want the character designer and modeller to transfer your ideas into polygon flesh, so to speak, then the more they have to go on the better the character will match the mental picture you had of each one. Likewise, if the animators have an understanding of what makes your characters tick, then they’re much more likely to animate them in a rich and varied manner. As important as this side of things is, the real value of the profiles is how they can help you.

Months may pass from writing the story for your project and writing the scenes that take place between the characters. While you may remember the broad sweep with crystal clarity, it’s likely that all of the subtlety you were thinking of at the time has been lost because you’ve spent the intervening time working on other aspects of the project, or even on another project altogether.

I’m not talking about the subtlety of the story, but of the characters. If Katie Eckersley has suffered from asthma since being six years old, how will that affect her outlook on life? Has she given into it and developed a hatred for all sports? Or has she seen it as a challenge and is now a champion swimmer? And how did that affect the relationship she had with her mother, who smothered her in attempting to protect Katie from harm?

Characters are so much more than one defining trait, though, and the profiles you develop should reflect this. Basic information like gender, age and build are always useful to include, simply because they start the ball rolling and get you into the other details more readily. What you include in your list will be down to your particular tastes and the needs of the game you’re developing for, but it’s better to have too much information than not enough. Some suggestions for included traits or information could be:

• The purpose of the character in the game.
• How they progress through the game.
• Speech oddities, accents and mannerisms.
• Occupation.
• Personal history or background.
• What they like to do in their spare time.
• Any special talents or abilities.
• Any handicaps or problems.
• How they dress.

This is a straightforward list, but it can be adapted or added to, particularly if your characters inhabit a fantastical universe, or it’s important to build a highly subtle portrait of each character. However, there are things that it would be silly to include, like favourite colour – when was the last time you heard of the way two people interact with one-another being affected by their favourite colour?

One of the real beauties of working through your list of traits and information, filling out details for each character, is that it can be such fun. Not only do you get to make up small stories about each character’s life and the type of person they are, it can give you new insights into the main story and how it can be subtly enriched by this wealth of detail you have just developed.

The characters come to life and the story and game become so much more immersive.

© Steve Ince, 2004

Developing Thoughts 21

Obstacles of Desire

One of my favourite obstacles in a game was in Beneath a Steel Sky. Though I worked on this game, I didn’t contribute to the gameplay design; so I think it’s okay for me to feel this way. One of the reasons I enjoyed my eleven years with Revolution was that I had such respect for the people I worked with.

The obstacle in question involved getting into a security building with the use of a grappling hook and cable. The route to getting these objects had a convoluted series of steps that involved finding a spanner, fitting the robot, Joey, with a welder shell, trading objects with others, distracting people, getting Joey to melt through a loose cable and then have him cut the anchor off a statue in order that you could use it as the hook. Mixed into this were other minor obstacles and much humour as you explored the world and put up with the sarcastic comments of a less than enthusiastic sidekick.

What worked best for me was the way that I never felt that I was simply solving a small puzzle and then moving onto the next one – the gameplay seemed more continuous and free flowing than that. Being able to wander around the world with relative freedom also helped give the impression that I was in control of what was going on.

Another obstacle I particularly admire is in Half-Life, where you must kill the monster with the test rocket engine. Of course, you must get past the monster a few times in order to get the fuel and power flowing to the engine and console, working out how to distract it temporarily as you work through the tasks involved. The elegance of the obstacle is that not only was it clear what your objective was, but it acted as a secondary obstacle to completing the other tasks. Then, when you completed the tasks and fired off the rocket engine, it was such a satisfying thing to do, rewarding you well for overcoming the obstacle.

One of the things that strikes me, is that a successful obstacle is one that doesn’t give the impression that it’s insurmountable, even if you’re struggling to complete the tasks needed to beat it. If the objective is clear and the tools are to hand (though they may be difficult to obtain), then all that’s left is for the player to put the parts together. Of course, simply put like that, it may seem as though making the obstacles easy is the key, but that’s not the case. It’s not about ease, but clarity – difficulty should arise from the way the route to beating the obstacle tests the skills of the player, not by making the steps along the route obscure or illogical.

There have been games in the past, where playing them has felt, at times, as if it’s a battle with the designer. Searching for the important object was reduced to a mind-numbing pixel hunt, or leaping across the chasm could only be achieved by a professional gaming ninja with skills enough to press twenty buttons or keys at the same time.

When the designer of an obstacle begins to think, “There’s no way the player will beat this one!” then it’s time that the designer should be re-thinking his approach to obstacle design. Thankfully, few games have this flaw, today, but thinking carefully about obstacles will only improve the whole gaming experience for all of us.

© Steve Ince, 2004

Developing Thoughts 20

Puzzling Through the Obstacles

One of the criticisms levelled at Adventure Games these days is that they can feel a little old fashioned. I’m increasingly of the opinion that this is because they contain these things we refer to as “puzzles”. This term can then create the wrong idea in people’s heads as to what sort of game adventures are. Of course, there are adventures that probably fit this perception very well, but more and more adventures are developing a kind of gameplay that makes it difficult to think of the player as solving puzzles.

The word puzzle, to me, suggests gameplay that involves pulling levers in the right combination or fiddling around with sliders. While there isn’t necessarily anything wrong with this type of gameplay, it does have a “static” kind of feel to it, particularly at a time when the majority of gamers want dynamic games. Some of the other aspects of adventure games – collecting clues, using inventory objects, developing story and so forth – are already being included in other genres, so it seems that adventures could find a broader player base if they concentrated on just these aspects. And stopped using the word, puzzle.

I believe that a much better term is “obstacle”. This has a much wider relevance and can be applied to almost any genre of game. For my purposes, an obstacle is anything that the player must overcome in order to progress in the game. A puzzle may be an obstacle, but obstacles aren’t restricted to puzzles. An obstacle is also the end of level boss in a platform game, or winning the gold trophy in a race game in order to unlock the special car.

One of the beauties of thinking in terms of obstacles is that you can take a much wider approach to your thinking than when concentrating on puzzles. In many respects, the antagonist, working his way through the plot of the game in opposition to the hero, is a large obstacle that lasts the length and breadth of the game and the other obstacles simply feed into that. At least they can if they are designed with an eye on how they fit with the overall story, design and the style of gameplay.

Obstacles can overlap and interweave with one another, in the same way that subplots do in a good film or novel. It could be that the player has a number of different obstacles to overcome at any one time and that they could be overcome in any order. Alternatively, in order to overcome one obstacle, another has to be beat to get the device, clue or information needed to address the first.

Sometimes an obstacle needs a multiple-stage approach to beating it, with some of those stages opening up new obstacles. Suppose, for instance, your character needs to get into the courtyard, but there’s a wall blocking the way. The character can’t just climb over, as it’s too high, so he brings across the nearby dustbin to stand on. Only then, he finds that broken glass has been cemented into the top of the wall and he’ll cut himself to ribbons if he tries to climb over. Therefore, he needs to find something like a heavy rug to drape over the wall. The only one he can find nearby is being used by a tramp who won’t give it to him unless he gets a bottle of whiskey in return...

Of course, if it were a GTA type of game, the player would simply blow the tramp away and take the rug. However, if you had the anti-gravity pulse boots I talked about a few weeks ago, the wall would only be a minor obstacle, as the player character would simply jump over the wall without worrying.

What the above shows is that while obstacles can be built upon to provide increasing gameplay, the same obstacles in different styles of game will require different solutions and approaches by the player.

The trick is in making the obstacles challenging without giving the player the feeling that they are going nowhere.

© Steve Ince, 2004

Developing Thoughts 19

Shall we interface?

Have you ever picked up your joypad or approached your keyboard and found that you struggled to play the game that’s in the machine because the interface felt wrong? Have you ever given up on a game simply because you were fighting the interface more than playing the game? When the interface creates these feelings in the player, it acts as a barrier to enjoyment of the game, instead of a means by which players can immerse themselves into the game world with ease.

The development of a set of interface mechanics can be a major concern. If you don’t get it right, the whole perception of the playability of your game will be judged by how the interface affects the player’s enjoyment. It’s likely that most projects go through a period where the interface doesn’t feel right or needs improvement – the trick is to discover the problems before the game is released.

It is at this point that some of you may be wondering about the interface problems in Broken Sword – The Sleeping Dragon. For many people, the keyboard interface on this game was a major barrier to their enjoyment and is actually a powerful lesson in the dangers of taking things for granted.

Revolution Software was clear from the outset that the game should move away from the point-and-click interface that was the trademark of the adventure. Many reviews of other adventures or articles about the adventure genre often talked about the point-and-click interface in a derogatory manner. It was felt that such a PC-specific interface was holding the genre back from moving to a wider range of gaming platforms. With this in mind, the development of The Sleeping Dragon was geared towards a lead on the PS2 and Xbox consoles with an interface that matched the joypads that the two machines used.

The joypad-based interfaces worked very well and suited perfectly the aims of broadening the genre. However, this success blinded us to the problem of the PC interface and here was where we took for granted that on the keyboard it would just work. Moving the player character around the game environments in a screen-relative control mode simply isn’t as easy on a keyboard as it is with a joypad.

Perhaps it’s the nature of the keys themselves; perhaps it’s something about the difference between using fingers instead of thumbs. Whatever the reason behind the difficulty, it should have been seen earlier so that something could have been done about it. Giving an additional option to switch to character-relative control may have been all that was needed, but it was something we missed and it’s certainly a lesson I have learned. Unfortunately, a lesson learned the hard way.

Of course, it could be that the worry over the point-and-click interface led to a slight over-reaction, particularly when you consider that other games use this type of interface. PC based RPGs regularly use a point-and-click interface with no worry about whether it’s outmoded. Even Doom 3 uses a variation for when the player wishes to interact with objects he comes across in the game world.

When looking at the interface for your game, be aware of what other games are doing and learn from approaches that work well. You can also learn from interfaces that make mistakes, by ensuring that you don’t make those same mistakes.

The interface should be the player’s means of connecting with a great game, not a barrier to having fun.

© Steve Ince, 2004

Developing Thoughts 18

Level 17 Made Me Cry

This may seem like I’m being a little slow on the uptake, but I wanted to finish off my two-part piece on mechanics design before writing this. Besides, it’s always best to ruminate on these things for a little while before launching into commentary. Reacting too swiftly to news, people’s statements and press releases can give results that are coloured by an initial emotional reaction instead of reasoned thought.

Some of the things I’ve read about Spielberg’s and Zemeckis’s recent comments fall into the category of knee-jerk defensive reaction. To summarise, they both feel that while games are developing their story telling well, there is still some way to go before they will be on a par with films. I must say that I agree with this view and it’s difficult to see why anyone would disagree. There are some fabulous things being done in games and we should be proud of how far the industry has developed in a relatively short time, but at the same time, we need to be realistic about where we are in the larger scheme of things.

Having a go at Spielberg seems a little misguided to me. Here is a man with vision, who has created a large number of excellent, successful films; yet people have jumped on his comments as if he doesn't know what he's talking about. While he may not know everything about the games industry, we should be listening to what this man says from the viewpoint of someone on the outside looking in. We should consider how we might use his experience and vision to move game development forward.

Specific attention has been aimed at Spielberg’s quote, "I think the real indicator will be when somebody confesses that they cried at level 17." Many seem to think that it’s an indication that he’s out of touch with games because no one refers to levels in games any more. Come on, just because we may refer to them as chapters or missions, to all intents and purposes they are still levels, particularly in the way that many games implement them.

To ridicule Spielberg’s statement only shows how little is known about the larger issues; about how story works on many levels. Most reactions I’ve read use the same example to refute his claim – the death of Aeris in Final Fantasy VII. If we have only the one example to turn to, it actually shows how right Spielberg is, particularly when you take into account that it’s the death of a main character – an extreme plot development in any situation. What about crying because the main character’s just been told he has cancer? Or with relief that her kidnapped son is alive and well? Or with joy because the boy meets girl subplot has resulted in a meaningful relationship? This is the real significance behind Spielberg’s statement.

From the perspective of people looking from outside the industry, games have clearly yet to move us in the way that films do. One highly emotional scene from a single game that has forty hours of gameplay doesn’t even come close and shows how far we have yet to go.

Because Spielberg has said something that make games look inferior to movies, some people have simply become defensive. Instead, we should be using this as a springboard to making games reach the heights and tell the stories that not only equal those told in films, but also surpass them. There is an amazing wealth of talent in the industry that can help achieve this, but the key is being realistic about where we are now.

© Steve Ince, 2004

Developing Thoughts 17

Gameplay Mechanics part 2

So, it’s a week later and we’ve called the design team together to discuss the results of the brainstorming session. We’ve all typed up our thoughts or scribbled notes in the margins of the brainstorming list. The project is in the early stages, so we’re all really excited about it. We don’t care if it’s going to be a long session because we’re going to have some fun.

Of course, design is a serious business and should always be approached with a professional manner, but if the development of ideas isn’t interlaced with a liberal dose of fun, how will the fun get through to the final game?

Working through a number of ideas, with varying degrees of success, we get to the one that I proposed, the rocket boots. A couple of people express concern that it may be a bit of a cliché, so I suggest that we have a mini-brainstorm and think about possible ways of developing the idea further. If we don’t think it is going anywhere after ten minutes we should put it to one side and move on.

We start with possible variations on the rocket boot idea and we get a few suggestions: jet boots, spring boots and anti-gravity boots. That last idea we think might have legs (ho, ho) so we concentrate on this for a time.

Worried that having the anti-gravity boots on all the time may prove to be a gameplay problem, we look at how we could limit their functionality and make that limit become part of the gameplay. Because many gameplay mechanics are developments of old ideas or simply because players expect sophistication, it’s always better to refine the ideas into something more than the bare essentials.

With this in mind, someone suggests that the boots should be anti-gravity pulse boots. A short burst of anti-gravity would shoot the player character into the air, but they would then be subject to the pull of gravity. It would be down to the player to work out how to use that sudden, huge leap to their advantage. This is a good development, but there is now a concern that the player will simply keep jumping their character continually.

The next suggestion involves a modification so that the boots take thirty seconds to recharge and the battery packs for them only have ten charges. Finding the battery packs for the boots becomes an additional layer of gameplay. Of course, at this stage, any numbers discussed are simply pulled out of the air and will require full game testing and tweaking before a proper gameplay balance is found.

The design session would normally continue looking at the other brainstorming ideas, but for the moment, let’s concentrate on the anti-gravity pulse boots. Although the mechanic is a feasible one, we need to be sure that it fits with the overall concept of the game. If it’s a Victorian mystery adventure, then the idea of the boots would never have been developed in the first place, so the fact that we entertained the idea to the degree we did implies that the basic concept fits with the game premise.

The next stage in the development of any mechanic is to assess the impact it will have on the overall gameplay, the level designs and building and the other mechanics like shooting weapons. Then there are the specific details that have to be considered – the application of physics during flight, the damage to the player for missing the overhead walkway, etc. While looking at these aspects, the design team must be its own devil’s advocate, because if any issues are not discovered and ironed out at this stage, then they are bound to surface later when they will be much more costly to remedy.

Once the details of the mechanic have been worked through to everyone’s satisfaction, the task of documenting it must be undertaken. Never underestimate the value of documentation. Without clearly written documents you have no record of the details of the mechanic. Artists will be unclear what they have to do. Programmers may take months before they are able to work on this mechanic and you’re bound to have forgotten some detail in the interim, so get it down while the idea is still fresh still excites you.

After going through this process, you may think you’ve done well by completely designing a cool mechanic. Fine – pat yourself on the back. But make sure you have plenty of energy for the other 99% of the game that still has to be designed...

© Steve Ince, 2004

Developing Thoughts 16

Gameplay Mechanics

About eight years ago, I was sent a game design handwritten on two sheets of A4 paper with one very small map drawn in pencil. Most of the writing described a story, rather than gameplay, but it was clear that the guy who sent it thought that we’d just take it and implement a game from this. I think it’s fair to say that nowadays the general gaming public have a bit more idea of what goes into making a game than they did those few short years ago, though it’s always useful to look into why we do the things we do.

One of the hardest parts about game design is turning all the cool ideas into realistic and consistent game mechanics and documenting them in such a way that the coding and implementation will happen without any misunderstandings. This isn’t about designing cool levels; this is about developing the basic building blocks with which to design those levels.

Very often, the basic premise for a game is there from the very beginning. The team knows that they want to create an FPS/RPG/RTS/Platformer/Adventure/etc. and they have to build from there. What gameplay mechanics are they going to create that gives their game an edge in today’s marketplace? Clearly a team-wide brainstorming session is called for, where anyone can throw ideas onto the table.

A good brainstorming session should give the team more ideas than they could ever hope to incorporate into a single game. It should never be about analysing those ideas – that comes later – but should be a way of getting everything recorded. If it’s run with the principle of there being no stupid ideas, it will encourage everyone to think outside of the box. Sometimes the “stupid” ideas are the best ones for making everyone feel at ease and may even inspire great ideas in a tangential way.

For the purpose of this column, I’m going to work through an idea that I’ve just brainstormed with myself (don’t worry, it’s perfectly safe if I wash my hands afterwards). Thinking about a way to add something into the mix, I came up with the idea of Rocket Boots. In a normal brainstorming session there would be a few humorous comments, no doubt, so just imagine that someone somewhere has made a witty remark about Elton John’s “Rocket Man”. However, along with everything else generated from the session, it goes down on the list of possible ideas.

The thing about ideas is that they so often need to mature and develop, becoming full-bodied as they work away in the subconscious of the individual team members’ minds. The list of ideas should be written up and distributed, immediately following the brainstorming session, but the design meeting to develop those ideas should be left for at least a couple of days. If possible, so that everyone has had the time to think about them, allow a week to pass by before calling the meeting.

Therefore, with that in mind, if you all have a think about Rocket Boots over the next week, when I resume this topic next time I’ll look at how the idea could be developed into a possible gameplay mechanic.

© Steve Ince, 2004

Developing Thoughts 15

Motivation and Conflict

Like many other aspects of game development, motivation is two-pronged. Not only do you need to consider the motivation of what drives the player character through the game’s story, you also need to consider how to keep the player motivated to continue playing the game.

All games, whether they have a story or not, should ensure that the player is sufficiently motivated to continue playing on a moment-to-moment basis. This is part of the fundamentals of good gameplay and is not what I want to discuss this time around. I want to concentrate on the player character’s motivation and the conflicts that stand in the way. For only with conflict can we get something that approaches true drama.

Motivation comes from a combination of things; the personality of the character, his connection to what’s at stake and his ability to discern a clear direction that will take him towards his goals. If he doesn’t care enough or believe that he can do what needs to be done, then his motivation to even try is going to be severely lacking.

The developing story drives the motivation of the player character. If the broad gameplay goals tie in with the story goals, then the blending of the two will provide additional impetus to the player. If there is a strong story reason to go to the abandoned school, and not just because it’s a cool location, then you believe the character’s motivation for going there much more.

Because there are other characters in the game, you also need to take into account their motivation, particularly the antagonist. Without good motivation, the player will begin to question why the bad guy is doing what he’s doing. It also needs to be made clear that the antagonist is getting on with his plans off screen or it will feel like he’s just sitting around waiting for the player to turn up at the end of the next level.

Drama is created when the expectations of two characters, driven by their individual motivation, comes into conflict. This could be something as simple as one character trying to get through a doorway and another character preventing them. More often than not, the conflict will be more complicated or less clearly definable. Sometimes conflict can be a mixture of three or more characters and it may not always be clear who is conflicting with who – sides may shift and change through the course of an exchange that in turn leads to more conflict.

Conflict may appear to be an odd way of providing motivation for the characters, but if they were the type of characters that backed away from conflict and adversity, would they be the type of characters you’d want in a game? Certainly, the player character should be sufficiently motivated that he will continue, even when faced with personal danger, the threat of global annihilation, and sarcastic ridicule.

If the player character is taking a path that brings him into conflict with the plans of the antagonist, then he’s clearly on the right lines. If that isn’t enough motivation in itself, then we’ll throw in some poisonous spiders and snakes for good measure.

© Steve Ince, 2004

Developing Thoughts 14

Dialogue? What dialogue?
Part Three

That this subject had stretched itself to a third column shows the importance I feel that dialogue plays in story and character driven games. As I touched on briefly last time, if vital game information is revealed through dialogue, conversations should not be separated out from the overall gameplay. This means that because dialogue becomes an important part of the gameplay, the player should therefore have at least a modicum of control during conversations.

The player can become frustrated when it seems they are simply a passenger during long periods of exposition. However, if the player gets the opportunity to work for that exposition, the rewarding nature of the interaction increases the empathy with the player character and the involvement in the developing story.

To obtain the best possible fit, dialogue must become part of the overall game design process or the aims of the dialogue and the gameplay may be at odds with each other. In other words, a structure should be developed for the way that the dialogue scenes are triggered so that it matches the structure of the other aspects of developing gameplay.

This isn’t to say that actual lines of dialogue need to be written as part of the design process, simply that the scenes should be identified and what information is going to be discussed and passed on.

In many respects, it’s much better not to write any dialogue at first as it can have an effect on the speed of implementation and testing. Having just the bare bones of the scenes with variables being set, means exactly the same thing to the progress of the game, providing that the people implementing the game have a clear idea of what is happening in each scene. The dialogue can be written and added in at a later point and may benefit from the writer being able to see the game in progress and match the feel of the dialogue to what’s on screen.

Something that always strikes me as poor dialogue structure, when I see it in a game, is when avenues of dialogue repeat unnecessarily. Unless the dialogue structure is specifically designed so that the discussion of a subject can expand in detail – introducing new lines for example – the chance to talk about that subject again should not be available. When a scene, or part of a scene, repeats word for word, I feel it undermines the hard work that the writer has put in, reducing any drama and spoiling the professional appearance.

Some scenes, if not all, are best developed with the writer and designer working together. Scenes aren’t just about giving the player important game information, but also for developing the characters, working through sub-plots and for creating dramatic tension and conflict. Subtext, while not something that’s been particularly strong in games so far, will come increasingly into play, as character acting and facial expressions continue to improve and tools are developed that allow subtle acting to become a common part of games.

Only when a designer and writer both understand the story, character and gameplay needs of all scenes will they be able to deliver something very special.

© Steve Ince, 2004

Developing Thoughts 13

Dialogue? What dialogue?
Part Two

There are many games where dialogue is an important part of the gameplay experience, yet it’s often handled in a way that strikes me as being far too convenient. Supporting characters almost fall over themselves in their eagerness to give the player the information he needs to progress. The following lines illustrate a simplified version of a common structure.

“Hello, we’ve never met before.”
“That’s okay. If you get me Madonna’s autograph I’ll tell you the secret password.”

What just happened, here? As a player I was given game information too suddenly and I was taken aback - I feel cheated that it happened too easily. How on earth did this character know I wanted the secret password? Was I aware that I wanted this information?

There are two problems that arise from an exchange as short as that – the structure of the conversation itself and the imparting of game information.

We all know how conversations work from experience, even if we cannot write. This knowledge comes from interacting with other people on a day to day basis, over-hearing conversations on the bus, and from the wealth of TV and film we’re all exposed to, as well as many other examples. When we experience a conversation that falls outside of what we expect, it immediately puts a strain on our suspension of disbelief. The following lines approach the interaction in a more convincing way.

“Hi, I’m Brad Green.”
“So?”
“I understand you know the password to the Kitty Klub.”
“You understand wrong.”
“Tommy Smith told me -”
“Tommy Smith talks out of his backside. Now get lost.”

Admittedly, the player didn’t find out about the autograph, but we believe the structure because it fits with our experiences. We have also created dramatic conflict because the player character (and the player) has not achieved what he expected to. This failure to get the information suddenly throws up the need for more gameplay in order that the player character can finally convince this person to give him the password. Or to find out why Tommy Smith was lying. Or something else entirely. The actual gameplay and the route to the information will take different forms depending on the genre of the game involved.

Dialogue must not only serve the needs of drama and gameplay, it must also be written in a way that’s in keeping with the nature of the characters involved. What if the holder of the password was incredibly chatty, but only ever talked about himself? The conflict could be made humorous rather than sinister. What if they were sad, or drunk, or in fear for their life? What if they were in the pay of someone who wants you to have the information, but they’ve got to make it seem like you’re forcing it out of them? The potential for variety is endless.

The key to building good dialogue structure is to start by understanding what the agendas of the characters are so that you have two points of view when writing each scene. It might be something simple like the other character not wanting to talk with anyone. If it’s one of the major characters in the story, though, it’s likely that the agenda the character has will relate to the plot and may well change depending on how far along the plot the player has progressed.

Even with the best structure in the world, dialogue can often fail if it’s written in a way that sounds clumsy when spoken aloud. The only solution here is to speak the lines out loud, act them out, and any weaknesses will quickly be evident.

Of course, that introduces a different type of problem. When you’re in the middle of a gritty dramatic conversation with yourself and your partner walks into the room, having her fall about laughing makes you wish you’d rented office space away from home.

© Steve Ince, 2004

Developing Thoughts 12

I'm going to blast them all onto the blog in one go. You have been warned! :)


Dialogue? What dialogue?
Part One

Not a simple subject even at the best of times, I realised as I was writing this that what I wanted to touch on could only be done by spreading it over two columns.

I’ve worked almost exclusively on games where the dialogue between characters is developed to a high degree to maximise the relevance to the game, staying true to the characters and laced with high interest and humour. This often affects the way that I respond to dialogue in other games. While there are many games that handle dialogue very well, others contain character speeches that really don’t fit the true meaning of the word dialogue.

Many game developers choose not to have the main character speak for numerous valid reasons. For instance, the player may create their own character from a choice of templates and having the character speak would mean having to record a huge number of line variations to make the dialogue fit the character. The downside to this non-speaking player character is that, because conversations with other characters are often one-sided, it can give the impression that the player is simply listening to a series of mini monologues.

Sometimes these monologues are triggered by proximity of the player character, which can in itself create an artificial feeling because suddenly, this character you’ve never met before, is giving you plot-relevant information without being asked. Even in games where conversations are triggered and controlled by the player, because the player character doesn’t speak, the other character’s lines are often structured in a way that gives more information than you’d normally expect. In a film or a novel, the main character would only get the information they need by a dynamic exchange of dialogue. When characters are not reacting to anything the other character is saying, the speech always comes across as a little surreal and this in turn strains at the immersion the player gets from playing the game.

It may well be that monologue conversations are a necessary part of certain types of games, though I find that hard to imagine. If this were the case, however, writing monologues would need to look towards doing so in a way that will give the maximum dramatic effect and may lead to an expansion of existing writing vocabulary. Not an insignificant task.

The main burden of the monologue approach is that the character speaking is effectively doing the work of two characters by second-guessing what the player character wants and providing detailed answers. This actually has a knock-on effect of weakening the main character because they simply listen to the monologues in a very passive way. What’s the point of developing a dynamic character that fights for his life while trying to save the world, if he shows no reaction to important revelations from the other characters?

When games are becoming increasingly realistic in their rendering of characters, adversaries and locations, it often feels that elements of the game that don’t match this approach are things that can destroy the suspension of disbelief and prevent the player from achieving a fully immersive experience.

Because two-way conversations – dialogue – are such an important part of our everyday lives, monologues will always come across as artificial because they do not represent the way we talk. As games continue to become increasingly sophisticated the artificial feel will only increase.

© Steve Ince, 2004

Developing Thoughts 11

I've really been lax in updating these and it's been nearly a year since I posted the last one, which was the tenth in the series. So thanks to Erwan for giving me a nudge on this. I've also been through the older posts and attached labels to them so that you can find them all in one place.


Showing Character

Deciding the type of characterisation for the main character of a game can be one of the most important parts of concept development. If the character doesn’t suit the needs of the game, there is a good chance that the game as a whole will suffer as a direct result.

If the game’s story is one of its most important aspects, coming up with an idea for a main character may follow the initial outline of the story. Once the character starts to form, this feeds back into the story and the two play off each other, becoming more and more complex as other characters, particularly the antagonist, are introduced. The result of this should mean that the story and character are completely at one with each other and, if the design process has been completely successful, with the gameplay, too.

An alternative method is to create the character first and then decide the story he will be involved with, which can be a much more difficult route. Of course, no character can be created completely in a vacuum, so the design team will likely have a good idea of the type of story the character will be involved in before the character is developed.

In many character-driven stories, the main character goes through a transformation of sorts as the story unfolds and is no longer the same person at the end as he was when the story began. This transformation may not always be desirable, particularly if the character is expected to become central to a whole series of games. For a continuing series, character progression in each story should be relatively minimal or the changes could take him/her away from what made the character right for the central role in the first place. One of the reasons the James Bond films have been so successful over the years is that as a character he’s been pretty well defined and he tends to end the film the same person that started it. The stories revolve around his job rather than him as a person and are what is known as event-driven rather than character-driven. Many games fall into this category and so the Bond level of characterisation is about right for these, offering up many chances for sequels.

You will often read in books that you should avoid stereotypes at all cost, but sometimes the main character needs to be nothing more than a stereotype because this may help the player get a handle on what the character represents from the very beginning of the game. The gameplay may be all-important and any story and characterisation is superficial at best. The requirements from the character are not what he/she is like as a person, but what their gameplay abilities are – how high can they jump, how fast can they run, and so forth. If Mario suddenly started questioning his place in the world and became angst-ridden, then players would rightly complain that he’s no longer the character they came to love. Mario has become his own stereotype, but one that works perfectly within the context of the games he’s used in.

Naming your characters can be much more difficult than creating them in the first place. If James Bond had been called Reginald Periwinkle, Ian Fleming may never have sold his first Bond novel. Sometimes I feel that every name I ever choose for a character could be better (with the exception of Scout the One-Eyed Cat, of course). I always know when a name definitely won’t work, but finding one that definitely will work can be so elusive.

Although getting a good name is important, it’s also got to fit the style of character. A strong and bold name wouldn’t necessarily fit a character who’s really just an ordinary guy thrust into a series of events outside of his control. Yes, he may rise to the challenge and become a hero, but choosing a name that fits his initial nature can emphasise just how far he’s come in his journey through the story.

© Steve Ince, 2004

Developing Thoughts 10

Another in the series. Though this one may be less than topical now, I'm still reproducing it for completeness' sake.


Secret Panels

I was reading a weblog posting that made the claim of scripting weaknesses in some aspects of Doom 3. It struck me that, from the description, the underlying problem wasn’t the scripting but the design behind it. A person can only script what’s been designed, after all.

The issue the weblog picked up on centres on secret panels. The ones that open after the player has passed them by, revealing – usually by shooting you in the back – that monsters have suddenly appeared in the corridor behind you.

Now I’ve always had this problem with secret panels in general because, even in the most fantastical of settings, I can rarely see the justification for their existence. The more realistic the setting, the more any justification struggles to gain ground.

Okay, in a fantasy setting, when the players get to the heart of the castle they may find a secret panel behind the king’s throne that hides something very precious, but you wouldn’t expect to find such panels spread all through the castle. Would you?

What I want to know is, did the panels exist before the world/castle/high-tech base was populated with monsters? If so, what was the reason for their existence? Could a person never trust their colleagues and so must use them to store belongings? What’s wrong with good old-fashioned locks?

Perhaps I’m looking for my answers in the wrong place and the base has been subject to the whims of a television home-improvement, makeover programme:

“You know what would go really well in here? A secret panel. I know what you’re thinking, that they’re a little passé, but just imagine the tricks you can play on your colleagues on a Monday morning. You dress up in the rubber costume from the fancy-dress shop and hide behind the secret panel waiting for them to arrive...”

But what really gets me smiling to myself is the thought of putting the monsters behind the secret panels. Presumably there was someone with a big evil plan that felt it was a good idea, making sure there was no food or water so they’d be good and angry when you triggered their appearance:

“Just hide in there, will you please?”
“Do I have to?”
“Yes you do. I’m the arch villain, sorry, antagonist – it says in my contract, you know – so you have to do what I tell you.”
“It’s always me. Why not one of the others?”
“The others don’t have your flair for terrifying the crap out of unsuspecting, gun-toting, space marines.”
“I bet you say that to all the monsters.”
“Only the ugly ones.”
“Oh, you...”
“Come on, I haven’t got all day, you know.”
“But I’m claustrophobic and this is such a small space...”
“For heaven’s sake, you’re a goddamn monster!”
“Oooh! So now you’re saying that we don’t have normal rights and feelings?”
“That’s all I need, a sulking monster. GET BEHIND THE PANEL!”
“RRAAAWRR!”
“Okay, I may have been a little harsh, there. Now, will you please take my head out of your mouth...?”

© Steve Ince, 2004

Developing Thoughts 9

The ninth installment of my original Developing Thoughts column.


Fun, fun, fun!

Danny: Don't worry yourself. I'll find the proof we need.
Estelle: You?! You couldn’t find the floor unless it was covered in beer.

The above comes from a document of ideas I’m developing for a game project. For me it illustrates what games should be about – the player having fun while they are working their way through the gameplay.

This week’s column was actually going to be about something else entirely, but I felt that I was in danger of taking myself too seriously (particularly after the sombre nature of the last column) and decided it was time to lighten up and have some fun. After all, that’s what games are meant to be about. Aren’t they?

Sometimes it seems, when reading the gaming news sites, that games are increasingly serious in nature, so it was a breath of fresh air when I was given the chance of script-editing the English version of an excellent comedy game. Not only was it good to work on this title, it also re-kindled my interest in designing comedy games, so this week I’ve been putting some time into two different comedy game projects of my own and it’s been great fun to do so.

Comedy is something that’s subjective at the best of times, so what works for one person may very well fall flat for another. But as long as it falls flat on its face in a muddy puddle, all may not be lost. What I mean by this is that for a broad appeal, the comedy may need to work on more than one level.

I’m a firm believer that there’s a long way to go with comedy in games and it’s certainly an area I want to explore over the next few years. This ranges from cartoon-style to sitcom-style to more subtle, film style comedy. It also ranges from comedy aimed at children to comedy aimed at adults, with a centre ground that appeals to both.

Where, for instance, is the game equivalent of Toy Story or Finding Nemo? I’m not talking about the games that use the license in a superficial way, but ones that use the characters as they were used in the film, to create moments of genuine humour through the way the characters interact with one another. And if it is the player who triggers the humour through the gameplay interaction, then they are part of the unfolding comedy and it becomes a much more rewarding experience.

When I was developing part of the game, In Cold Blood, I decided to put in a couple of characters sitting near to each other. When the player character talks with them he discovers that they are having a tiff and not on speaking terms – she’s jealous because he lent his scarf to a female officer. They start talking to one another through the player character, and the humour of the situation unfolds by the player talking to each one in turn, “Can you tell him that I’m not speaking to him until he apologises...”

This situation had nothing to do with the main plot of the game, but was an excellent way of adding richness by giving the feeling that there was more going on than just the story related scenes and by having some fun in the process.

Just imagine, though, if the main plot of a game unfolded through a regular series of such humorous scenes, how much more fun that could be.

© Steve Ince, 2004

Developing Thoughts 8

Yet more of my old words...


Giving the customer what they want

The old saying, “The customer is always right”, is often taken too literally and many customers believe it allows them rights and privileges beyond what should reasonably be expected. However, the one thing that we must remember is that the customer is always right to choose only that which meets their requirements. A freelance provider of services to the games industry, when dealing with customers, must be very aware of that, because the moment they feel that this is not the case is the moment when they would no longer require those services.

Regardless of how a person may feel about the work they’ve taken on, once they have agreed to undertake it they must treat it with a fully professional attitude and deliver what has been defined. The temptation to adjust or deviate from the requirements of the customer must be resisted at all costs. Even if it’s felt that those changes would improve the product being contributing to.

It may well be that part of the remit is to do exactly that. To work up new ideas and suggest areas where improvements could be made. They have decided that this particular expertise and experience is what their project needs to inject freshness into the process. But even then, finding out where the boundaries lie is an important thing to do. Without knowing these boundaries, not only will there be a risk of alienating the customer by re-working areas that they may well be perfectly happy with, but time will have been wasted if the work is rejected. If it falls outside the boundaries of the person’s role in the project, then it will also be work that they will not be able to charge for.

Because finding out what the customer wants is of prime importance, only by asking plenty of questions will the knowledge be gained to deliver what the customer wants. Assumptions should never be made that are based upon initial perceptions of the project, because the likelihood is that it will be nothing like those assumptions. A clear definition of the project would be an ideal place to start, along with a clear statement of the required role. If the role overlaps with those of other people, it would be wise to ask if those people could be included in any briefing sessions so that all parties are working as a team.

Sometimes the role that the client has in mind isn’t clearly defined because they are unsure what they need. By asking questions, it not only helps define the service provider’s role, but could also help the customer define their own place in the working relationship.

Once the answers have been obtained and the work defined, it’s always worth summarising this in a document, which should consist of a brief breakdown of the work involved. Estimates of all times should be done as accurately as possible, particularly if it’s the early stages of the project and the work involved may have a big impact on the schedule. Then, when the work is delivered, it should not be late. It’s vitally important that each agreed milestone is met.

If you don’t deliver what the customer wants, then the customer is always right to not be interested in working with you again.

© Steve Ince, 2004

Developing Thoughts 7

Another of my columns...


Going with the flow

Ensuring that a game works as a whole is very important to the satisfaction the player will feel as they complete it. As with story and research, the flow of a game can make or break the experience.

I’m not, of course, talking about the story flow – though in some games this may well be tied very closely to what I’m covering here. What I mean is the logic flow of the game. Are there any dead ends, which cause the player to restore an earlier save game in order to progress? Do the conversations with these two separate characters still make sense if they are triggered in a different order?

Some games have a simple logic flow, which link sections of the game in a way that relies on finishing one section before completing another. There’s no going back and no complex sets of variables that have to be taken into account, other than those connected with the player character’s health, weapons or abilities. On the whole, these games are relatively straightforward when it comes to both designing the logic flow and testing its soundness.

Games that rely on the player visiting each section a number of times have the greatest chance for the logic flow to go wrong. Performing tasks or actions in one section that has an effect in another will always be at the whim of a complex set of variables that must be carried throughout the game. Development of the logic flow can be both time-consuming and potentially expensive, if it isn’t done right. The less rigorously it’s planned out, the more chance there is that the testing and fixing period will highlight serious problems that will lead to the game being delivered late.

Flow charts and diagrams are an important part of the development of the main gameplay and logic threads, along with detailed documentation at every level. Probably more important, however, is the ability to hold the image of the logic flow in your head and think it through on an almost daily basis, checking and re-checking that it is completely sound. In order to develop the logic flow successfully, the designer (lead designer, director, whatever) should live with this structure as though it’s a second circulatory system flowing through his/her very being.

The downside to this is that you tend to wake in the middle of the night with concerns about how you’re going to get the hero from the mountain village to the heart of New York without it feeling too contrived. And when you drift away from the conversation – eyes glazing over – in the middle of a dinner with friends, you’d better hope that they’re incredibly good friends. Not everyone will understand the way that the design of a game takes over your life.

Sometimes, even with the best planning in the world and thorough testing, logic bugs can slip through. You’ve played it through time and time again yourself. So have the rest of the team and the publisher’s test department. Yet, the first person who buys the game on release will happen to find the one logic bug that everyone missed.

And that’s when, as you berate yourself for missing the problem, you really get the sleepless nights...

© Steve Ince, 2004

Developing Thoughts 6

Yet another installment of my column from 2004.


Researching the Unexpected

The key to establishing authentic detail is plenty of research – geography, terminology, clothing, equipment or historical facts, for instance. The level of authenticity can determine how deeply players will immerse themselves into the world that’s been created.

In the early stages of Revolution Software’s game, Broken Sword – The Sleeping Dragon, I was looking for some historical hook that would give a good starting point to build the story around. I knew that we wanted to tie the game back to the first Broken Sword game, and in a way that would complete the trilogy in a tidy manner. With this in mind I started exploring connections to John Dee, who was mentioned in the earlier games. It wasn’t long before I turned up a reference to something called the Voynich Manuscript.

This was exactly the starting point I needed – a genuine historical document written in a bizarre code that, to this day, no one has been able to decipher. This meant that the contents of the manuscript could be invented to match the needs of the story – the perfect device upon which to hang a historical mystery. Tying in a Templar power conspiracy was relatively straightforward, but what was it that the Voynich Manuscript hid within its code? We decided that it held the secret to unlocking the power of the Earth itself.

Coincidences can be more than a little spooky. When I started reading up on ley lines – because the idea is that the Earth’s energy travels along these channels – my research kept pointing to many of the same things over and again. Not only did many of the ley line references lead to Glastonbury – which we used in the game – but there were also a number of them that mentioned York, where Revolution Software is based.

I read a little further and found that a number of the churches inside the old walls of the city were built along a straight ley line, including the huge York Minster. Ever curious, a couple of us went up to the top of the Minster tower and looked out over the city, expecting at best to see a vague approximation to a line. But there, in a perfectly straight line as clear as day, were the towers and spires of half a dozen churches as well as Clifford’s Tower, all lining up with the junction of the two rivers, Ouse and Foss.

The coincidences continued. The land at the river junction is actually named St George’s Field and the hero of the games is also named George. Even spookier is the fact that this land used to belong to the Templars. When we came down from the tower we were to get an even bigger surprise.

Outside the Minster a statue has been erected of the Roman Emperor, Constantine, a man who brought Christianity to the Roman Empire. The statue has him seated and looking at the pommel of his sword in a contemplative way. Yet the sculptor created the statue with the blade of the sword broken!

Although the York material didn’t make it into the game, this research helped establish a feel and flavour that ensured the game as a whole really did have an air of authenticity. When you’ve made striking connections through research on the internet and actually seen genuine ley lines for yourself, you get to thinking that there’s a kernel of truth in the stories you’re making up and the whole becomes so much more believable.

© Steve Ince, 2004

Developing Thoughts 5

A further installment of the original Developing Thoughts Column.


Let me tell you a story...

At school one year, when I was about eleven, we used to have one hour each week put aside for writing stories. It was always the final hour before lunch every Wednesday and I would look forward to that part of the week like no other. No thoughts of fame or money drove me, I simply loved to write stories and it’s been a passion that’s burned within me ever since.

We all love to be told stories; particularly ones that capture our attention and make us hang on the very words of the teller, whatever the medium. A good story, told well, will transport us to new worlds, to new situations that we could never experience for ourselves. It will allow us to see into the mind of an evil antagonist and empathise with the most downtrodden of heroes as the plot unfolds.

The principles behind the construction of stories has been with us for thousands of years, ranging from tales of Greek Gods to epic mediaeval poems; from heart-rending romance to futuristic high adventure. Many fundamentals have stayed with us through that time, yet many more subtleties and sophisticated variations have been developed to allow the act of story telling to remain fresh and relevant.

Though it is in the field of video games that story faces its biggest single upheaval, as challenges arise to tell stories in ways that adhere to the many established frameworks, but do so in an interactive manner also. Not only must the story be revealed by the actions of the player, it must respond to those same actions in some degree or other.

Games will develop stories that serve different purposes, depending on the requirements of the genre and the degree to which each particular game stresses the importance of the varying possibilities. Is the story, for instance, one with a linear plot that takes the player from the start to the end through a series of connected set-ups and scenarios? Or is it one that ends in the same place, but allows the player to choose the order based on parallel plot threads? Do the actions of the player lead to plot consequences that change the story ending, and so tell a different tale to the one that would have been revealed had the player taken a different course through the game? Or will it be a completely open-ended story; one that is, effectively written by the actions of the player?

Clearly, the next few years, decades even, will be an exciting time, as more variations and complexities arise from the need to tell stories in an increasingly interactive manner. But it will also be a time fraught with frustration and confusion, for we must define the new story-telling rules that will help us speak a common vocabulary.

Many books already exist which cover the telling of stories in other media – film, TV, novels, plays, etc. – but we’re only now beginning to scratch the surface of what constitutes telling interactive stories. There has already been some tendency to establish camps of what should be the way forward, as though one method of interactive story telling is somehow better than another.

I feel, though, that all are equally valid and that in the future we will see people choosing a game based upon how it tells a story as much as what the gameplay delivers.

© Steve Ince, 2004

Developing Thoughts 4

Continuing the posting of the Developing Thoughts column from 2004.


Taking the Rough with the Smooth

When Revolution released In Cold Blood, after working on it for nearly three years, one of the first magazines to review it gave it only four out of ten. I remember being quite shocked that this thing of beauty, this long labour of love, was not being adored by everyone who played it. What were these people thinking? Did they not realise how much sweat and sleepless nights went into the making of this game?

When you do anything that involves putting your soul on display for everyone to see, there will always be times when some of those people will brandish the whip of harsh criticism as they pass by. Taking your chances in game development’s creative free-for-all, means there are times when you've got to be prepared for any ensuing pain.

Of course, there are those of a masochistic nature who revel in the barbed comments that come their way, and others who use it as ammunition to condemn the masses as ignorant plebs, for not finding everything they create to be of sublime merit. But the majority learns to take it in their stride or run the risk of becoming a casualty of criticism.

Personally, I enjoy constructive feedback. In fact, this edition of the column was inspired by an e-mail I received offering some thoughts on my writing. This guy was clever – by starting with compliments on my work in general, he was then able to sneak in some pretty insightful remarks that got me thinking. How evil is that? To get a writer thinking about his own work. And on a weekend, too! If only all criticism was so fair.

Fairness, after all, is the only thing we should hope for when being reviewed or criticised. We have no right to expect kind words or high scores, even when we know it is the best work we could possibly have done; for every person has their own subjective viewpoint which will colour how they approach the material under review.

It is incredibly hard, however, not to feel frustrated by people who write off a game without even seeing it; who seem to think that no one has a right to experiment in a genre that was once renowned for its innovative development. To me, this not only lacks any semblance of fairness, it is also not really criticism – constructive or otherwise.

Whatever the tone of real criticism, I always find that the positive aspects outweigh the negative by a long way. Yes, take on board what is being said in the averse pieces and learn from them if you can; but use the positive to drive you forward with a will that enables you to deal with the negative and make your next project better still.

I once had a guy come up to me in a supermarket and point at the Beneath a Steel Sky T-shirt I wore. “That’s the best game I ever played! You should convert the Broken Sword games for the Amiga!”

I welcome your constructive feedback, for I want to give you games, in return, that instil those kinds of responses in people.

© Steve Ince, 2004

Developing Thoughts 3

The third of my Developing Thoughts columns from 2004.


Getting the ball rolling

When starting out on the process of making a game, the initial concept – the project vision – is vitally important to get right, whether you’re developing your first game or your tenth. If the direction is not clear from the outset, then the more likely it is that the project will drift aimlessly and require more work than necessary to pull it back on course later.

The initial concept may start from a single idea, but in order to approach publishers or to give clear direction to the project’s team, it has to be expanded into a fully realised vision document. Until this is done to a satisfactory level, the project will be going nowhere.

It’s likely that a few people will be involved in working towards defining the initial concept, but the majority of staff on the project will not be brought on board until the document states everything that the project aims to do. This should cover the game genre, the intended art style, the technical advances, the unique selling points, a brief story synopsis, and anything else that is deemed necessary to paint the right picture.

Although the document should be a brief, high-level statement of the project’s aims, it is still a very difficult one to create and not one to be taken lightly. In many respects it’s the most important document that the team will undertake, for it defines the flavour of the rest of the development. It must read well and lay everything out in a manner that means others in the company understand the aims and buy into the vision it portrays.

One of the most difficult hurdles to overcome when dealing with an important document like this is coherence. Part of the process of developing the vision will often entail brainstorming, where a number of people will throw a great variety of ideas into the mix. The intention being that the concept becomes one that is rich with diversity. If there is a lack of cohesion when pulling these ideas together, this will show in the final vision document and any readers may well be left with a feeling that there is something lacking. Each idea and suggestion has to be examined and questioned to determine if they add to the vision in a cohesive way, or simply feel bolted on and out of place.

Very occasionally, this examination will lead to the initial idea being removed or modified in favour of a combination of ideas that give a greater cohesion to the vision. While that may feel a little like throwing the baby out with the bath water, if the result is something better the project is going to benefit greatly as a result. For instance, when the first work began on the game In Cold Blood, the intention was for it to be the third in the Broken Sword series. It quickly became clear that it wasn’t a Broken Sword game and so a new hero was born and a great game produced; one that could have felt very forced and artificial, had this been ignored.

The key to success in creating the vision for a game is to be as objective as possible when analysing the overall structure of the document. Only then will you ensure you have a vision that hangs together well.

© Steve Ince, 2004

Developing Thoughts 2

The second in my series that's reproducing the original column here on the blog.


A Penny for Your Thoughts

While thinking of a way to open this piece, I pondered on the number of times I’ve read of writers proclaiming that, on meeting readers, the first thing they are asked is, “where do you get your ideas”. Now this only happened to me for the first time recently, so it’s not something I particularly gave a lot of thought to, until now.

To be honest, I have no idea where my ideas originate, or why they pop into my head at the most inappropriate moments. For those who know me, the glazing over of my eyes mid-way through a conversation, is not because the subject holds no interest, but that an idea has suddenly given birth to itself and is demanding my time in its need to be fed and nurtured. Can I help if my little babies need all the love and attention I can lavish upon them? Would you expect me to cast them out into a cruel world at the height of the blizzard?

Of course, many of my ideas are weak or malformed. Even with the greatest will and attention, they will not survive much beyond the birth process. These are the ideas that no one sees; the ones I forget almost instantly. But for every ten of these poor creatures, there is one that’s worth making a mental note of, scribbling down on a piece of paper, or placing in the ideas file on my computer. These are thoughts deserving of serious consideration.

Yet, even then, not all of these ideas are great ones. If twenty percent of them turn out to have any genuine value, I would consider that to be a good result. It is much better to have twenty ideas and throw sixteen away, than to only have only four ideas to begin with. The likelihood of each of those four ideas being a winner is very small. By my twenty percent estimation, you’d be fortunate if one of those ideas bore fruit. Unless, of course, you happen to be a unique individual whose every idea is a gem.

The hardest thing in dealing with ideas is discarding them. There are times when a person has to accept that even the best idea won’t work and must push it to one side – the context may be wrong, or it conflicts with the style of the project. If it’s a genuinely good idea, they always keep it on file, hopefully to be used in another project. But a person should be prepared to discard the idea and move on – ignoring the pleadings of their babies.

Because the creation of games is built on originality, ideas are a valuable commodity, particularly to those who struggle to come up with ideas themselves. Where would the industry be without the people to originate the ideas? A game needs more than a single gameplay mechanic to succeed in the current market. A couple of one-dimensional characters are not enough to give a game depth. And if it hadn’t been for the wealth of technical ideas that have abounded over the years, we would not have the high standards we have come to expect from our games.

A penny? Thoughts appear highly under-valued.

© Steve Ince, 2004

Developing Thoughts 1

Because the Randomville site appears to have removed my Developing Thoughts column, I thought it might be a good idea to re-publish them here on the blog. They will be reproduced exactly as they originally appeared and I shall be taking them in order. Perhaps I'll even continue the series once I'm caught up.


Oh Lucky Man...

I’ve recently had cause to look back over the last eleven years of my life and take stock. Often when you embark on such a reflective journey the gems and turds you discover along the way surprise you. Fortunately for me, my introspection turned up far more gems than turds and for this I consider myself a very lucky individual. For instance, how many people get given their chance on the say-so of a talented comic artist of the calibre of Dave Gibbons? Or to work on a day to day basis with a gaming luminary such as Charles Cecil?

I must admit to bluffing my way through those first few weeks in the job. I knew next to nothing about computers, and less than nothing when it came to creating and editing graphics on one of the damn beasts. But I’ve always been a quick learner and this, along with the support and understanding of other talented individuals in the team, enabled me to pull through. It wasn’t long before the feeling I was going to be rumbled began to recede. From such a humble beginning it’s been an uphill road the whole way, due to the constantly shifting goalposts of the gaming market, but the satisfaction I’ve derived from it has more than kept pace.

One of the most gratifying aspects of my time in development has been the chance to meet and to work with so many talented individuals – programmers, artists, animators, musicians, designers, writers, directors, producers, and testers. People who have made my work much easier. People who have helped catalyse brainstorming sessions to the point where an electric charge fills the air. People who have put in long hours of very hard work in order to add the polish prior to immovable deadlines. People I have a great deal of respect and admiration for.

My eleven years have seen a lot of exciting changes in the way that games are developed and the way they are presented to the player. What was once seen as sophisticated at a screen resolution of 320x200, is now relegated to the realms of the retro section at the back of many gaming magazines. Where once a team of eight completed a game, a top-flight game will now pull in the talents of forty, fifty, sixty or more people. From counting the number of 2D sprites a game would put on screen, we now measure the number of 3D polygons and texture memory a game is able to wring out of state-of-the-art graphics cards.

For me, the most exciting time in game development is still to come, in the area of my own field of expertise – writing and design. Long gone is the time when a superficial story would do and the quality of translations didn’t matter too much. Now we endeavour to tell a story through dynamic dialogue that would be at home in the best Hollywood films and ensure that the translated versions are equally powerful.

With such exciting challenges still ahead of me, is there any wonder I consider myself so lucky?

© Steve Ince, 2004