Cause and Effect

June 27, 2010 in Methods, Reviews

I took part in Deborah Todd’s fantastic workshop way back at GLS 5, buying Game Design: from Blue Sky to Green Light as it closed. I’m finding it a refreshingly unique and informative take on the subject.

Todd’s chapter on plot and narratives has me particularly thoughtful. In writing about what she calls the ‘”and then” syndrome’, she compares cause-and-effect plots with the disconnected structures of much weaker narratives. It seems obvious that a cause-and-effect plot will, on the whole, make for a much more interactive and exciting game plot.

“Because the player does this, the enemies respond thus…”

…and so the player is involved more in each decision.

Many games do express this in at least a simple fashion. A cut-scene may show us that because the player reached the bomb and disabled it in time, their character lives and the building remains in tact. The enemy plot has thus been foiled. I have, however, seen games in which the bomb disarmament (or similar objective) was taken out of the player’s control, and all they were asked to do was make it from ‘A’ to ‘B’ within a time limit. The climactic events from then on were in keeping with the overall pace of that mission, but the player was robbed of any part in them.

This plot device owes a lot to film and other, non-interactive media. On the face of it, the game narrative would be less fun if the player completed a white-knuckle dash to the bomb, only to be shown a mini-game or some other form of ‘quick-time event’ (see Shenmue, Fahrenheit) whose presence slows the game down. Worse still, failing this crucial event will likely mean them running the obstacle course again, robbing this climax of all thrill.

Still, I can’t help feeling that this is inappropriate design; it has certainly been implemented in some quite disappointing games.

"Doctor Who: the Adventure Games" main screen

One such game is City of the Daleks – first instalment of Doctor Who: the Adventure Games. Overall I was impressed with the game: it offers 2 hours of authentic adventure in the Doctor Who universe, with some drama to embarrass many a ‘AAA’ title. It’s let down by its ending, however.

Some spoilers for Doctor Who: the Adventure Games may follow:

Read the rest of this entry →

Making Blu-Tack and Paperclips Stealthier

February 8, 2009 in Uncategorized

Discovering new ways to design puzzles, planning in miniature on my desktop before committing them to paper and to cyberspace.

As much as this is a shameful admission for me to make, today has been the first time I’ve dealt with designing a proper puzzle. It turns out that beginners’ luck probably passed me over, too.

As part of my degree studies, I’m working with a team on a prototype game for Microsoft’s Xbox Live Arcade. Featuring co-operative play throughout, and mixing puzzle stages with combat across a variety of fun and exciting timezones, it’s a game which hopes to strike ambitiously at the broad and inclusive ‘action’ genre. My job as design lead on this is a fairly fuzzy one, given our small staff of eight, but I’ve gladly seized the opportunity to try and set precedents for detail on the game’s puzzles and architecture. As well as documenting my co-workers’ designs for the G.D.D. (game design document), I volunteered to design a few myself and in today’s example, found myself breaking out the tokens and felt tip pens just to try and work it through logically.

For this particular puzzle, the first in the medieval zone (and the game as a whole), the two players must work through a maze dotted with sentries in order to reach the exit. One player has free reign around the outside of the room, in a manner similar to those players who’ve died in Bomberman – they can wield influence upon the room below, but cannot interact with it directly. It is down to this player to distract the attention of the sentries so that the second player can sneak around them without being spotted.

In tackling this puzzle I opted first to design a simple shape for the room, so that I might draft different maze options without it affecting the aesthetic, non-interactive architecture. Sketching then began, and I was attempting to draw out a map while making notes of the direction the player would take. This quickly became confusing. It is tough on the noggin to try and draw up new moves and replay all those prior, just to check that you’re not going to wind up stabbing the player in the back with a move they initiated four steps back. This was abandoned, but I had a start, at least.

A few weeks later, the thought struck me – this could actually be played out live. Part of the problem with sketching a puzzle in which the sentries can turn is that a pencil drawing is static. It’s imagination which has to track each sentry’s field of view, and mine could only go so far before nine sentries’ paths were criss-crossing beyond my comprehension. Why not try to model the puzzle in interactive 3D, then? Thankfully, the atomic world offers me a physics engine and control mechanism without the need to distract one of the programmers coding this game. After some hunting around, I found a few reliable tokens and set about crafting the medieval keep in miniature.

So there we are. From Google SketchUp to Pritt Stick, Blu Tack and paperclips. From here, I was able to place the two characters in any given spot (represented by the Blu-Tack snowmen), align the sentries (paperclips) to any given position and work my way through the map as both players. I was able to place the sentries at any new point up ahead, and sketch out obstacles (the felt tip pen scribbles) as I went along, being sure to make a note of which directions had already been set. Make a mistake? I simply move the sentry without any need for erasing and redrawing, as on paper.

Once I reached a satisfactory end, I then backtracked. Partly this was to test the play, in order to pick out any paths I may have missed; indeed, there had been a few but I was allowed to redraw elements of the maze with little trouble. It was also part of a crafty plan in which I photographed each stage of interaction. The bonus to this method was that a 3D model offers us a prime canvas for storyboarding – ideal, when a puzzle can’t easily be explained in any other manner than visually or kinetically. So, with digital camera in hand and the chance to rotate each sentry according to the next step of the puzzle, I went about my stop-frame demonstration of the room.

The true benefit here is not in what I produced, though. The photos I took are woefully abstract, but lndthemselves brilliantly to a template I can now incorporate into the SketchUp maps. Instead of dedicating myself to a map which may have to be redrawn from scratch should I spot a bug, I’ve already anticipated any errors by having the puzzle in photographic form. I’d call that a win for productivity.

‘Course, I’ve no idea if the puzzle is any good – in fact, I’d go as far to saying it’s likely to play pretty badly. At least I can be sure that the players aren’t going to find themselves stuck, which is more than I can say for my Blu-Tack avatars.