I've been listening to a band called Signal Hill recently (for those interested they're an exceptional instrumental band from the States, I believe some of their music is being used in Irrational Games' podcasts - which by the way are also a great listen!). Anyway, it got me wondering about why I'm attracted to certain forms of music over others and why, for me at least, music is so much more a personal experience than games.
"A composer causes an event, which reaches me, the listener, in an acoustical way, causing me to have an experience. My reaction to the experience causes an effect which I can communicate to myself and, if I find words for it, to others" - Herbert Brum.
This sentence is talking about the relationship between composer and listener. I think fundamentally music has to be a dialogue, but you can only respond truthfully within yourself. A piece of music that you enjoy (or even one you don't!) is capable of stimulating thoughts and imagery seemingly from nowhere, be it a memory or an emotion or something new; the composer speaks and you respond.
I find music has a much easier time tapping into the more abyssal emotions - the stuff buried waaaaay down there - than video games. I guess this could be because games are a fusion of sound, visual and motor information, so perhaps music has more of your focused attention? It's interesting that I find the most poignant, meaningful music is void of lyrics. I wonder if musical sounds are simply more abstract than speech or visual signals so offer more room for interpretation?
It's pretty rare for games to offer emotional experiences that go beyond the staples of joy, fear, anger, surprise and interest. A couple of great examples of games that delve into complex emotions are Jason Rohrer's Gravitation and Rod Humble's The Marriage. According to the authors, both games were constructed with a meaning in mind but never specifically alluded to in the games themselves - all interpretation is allowed to flow from the player. Perhaps this is helped by the fact they are both quite abstract in appearance (The Marriage doesn't have audio at all), but that alone doesn't answer why something like Geometry Wars feels less emotionally complex. Then again, Geometry Wars was designed specifically to elicit joy, fear, surprise and by proxy probably anger when you die.
In the scheme of things Gravitation and The Marriage are hardly mainstream, whereas the kind of music that offers me complex emotion is available on a high street store or at the very least i-Tunes. When are we going to see games that have the same universal appeal as music?
Monday, 29 November 2010
Monday, 15 November 2010
Oldies are the best
Just a quickie: I've decided to change the name of this blog to The Subluminal Link. You can find out what it's all about by reading the post below but the long and short of it is it's slightly more exciting than Quiburg on..., though I suppose equally nebulous. Onward!
Saturday, 13 November 2010
The Subluminal Link - Enslaved: Odyssey to the West
I'm resurrecting a column I used to write for a site called The Second Dimension. The site was run by a friend and I but we've both since moved on to bigger and better things. The column was used primarily to review games with more of a journalistic slant and the name Subluminal Link was apt as I was notoriously irregular with updates to the site (note: it's subluminal rather than subliminal). I'll be using the column this time around to examine 5 design decisions within the game I'm writing about and what I thought the consequences of those decisions were along with alternate methods of implementing or improving them. As a side note I'd like to make these columns oriented around a bullet-point structure rather than lengthy essays, simply because it's easier to digest.
So, introductions over let's take a look at Ninja Theory's Enslaved: Odyssey to the West. It's a third-person action adventure with emphasis on environment traversal, platform mechanics and combat. The game's story is an adaptation of the classic Chinese text Journey to the West, written by screen-writer and novelist Alex Garland. Taking place in a post-apocalyptic near-future New York, the player takes the role of Monkey; a grizzled anti-hero with exceptional acrobatic abilities. The early moments of the game see Monkey team up with a young girl named Trip, whose great skill in manipulating gadgets and machinery can be used in tandem with Monkey's combat prowess to overcome puzzles and combat scenarios. Much of the core experience is in the player navigating environments while making use of Trip's special abilities remotely (the narrative explains this by allowing Monkey to communicate with Trip through his headband and vice-versa). Without further ado here are the 5 design decisions I've opted to discuss:
1.Objects the player can climb are highlighted, providing a breadcrumb trail to aid traversing environments.
Highlighting which objects can be climbed on helps stop players getting lost and generally gives them a nudge in the right direction while they navigate the game's vertical spaces. What strikes me in particular are the actual objects themselves and how they've been worked into the environment. It seems that each object Monkey can interact with has been designed to blend naturally with the surrounding environment, with some of the interactive objects more obvious than others (for example a horizontal pole offers more directional guidance than a loose brick in a wall). It seems that by applying more realism in the environment the developers found it necessary to artificially point out climbable objects with a shimmering graphical effect. I found this system gave the traversal mechanic a pedestrian feel after experiencing it for an hour or so; all the tension and fear I should feel by leaping over chasms and scaling vertical surfaces evaporated.
One alternative to this would be to create a more cohesive visual language for objects that the player can climb. An excellent example of this is in the Uncharted games, where interactive traversal objects have a distinct visual style but are also modelled into the environment. Another alternative would be to only show the shimmering visual for the 'tutorial' levels.
2. Tech orbs
Enslaved encourages exploration by placing Tech orbs off the beaten track, the orbs function as in-game currency and allow players to purchase upgrades from a shop. I found the orb's visual style and the way they sit in the environment abrasive to say the least; there's something about floating balls of energy that doesn't gel in a world otherwise preoccupied with realism. They really end up representing a video game trope.
The designers obviously wanted players to be able to see the orbs from some distance, maybe in hard to reach areas, to draw the player toward them. I think a better solution would have been to build the orbs into the world rather than them being disembodied glowing things. The narrative explains the orbs as sources of energy, so perhaps modelling a few different items capable of storing 'energy' (e.g. fuel tanks, cannisters, engines etc), placing them around the environment and getting players to smash them open to receive the orbs would have been less incongruous. Again, to return to Uncharted, its own collectables are part of the game's world: artifacts, statues, antiques etc, all of which adds to the sense of a believable world and not just a transparent mechanic laid out by a designer. Similarly the God of War series stores orbs in detritus; pots, barrels etc – all objects that fit in with the environment the player's exploring.
3. Enemy attacks are difficult to distinguish from each other.
Each enemy in the game has a set of combat moves, but I found learning which move the enemy was about to use on me difficult, leaving me unsure of how to react. This seems in part due to the animations for each attack being quite similar (not to mention most of the enemies bear a huge resemblance to one another, making distinguishing even harder).
When creating a combat system it's vital that players are able to learn enemy attack patterns, for example in the Halo series players are made aware that a grenade is about to be thrown at them through distinctive visual and audible cues: i) when an enemy is about the throw a grenade we briefly see it glow bright blue in their hands, ii) there's about a 1 second animation for the enemy actually throwing the grenade, which we can clearly see from a distance because of the grenade's colour intensity, iii) the grenade is thrown toward the player at a constant speed each time, so the player learns how to avoid it. iv) the grenade has a very clear and distinct sound, so even if players can't actually see the grenade they can still hear it.
4. Twitchy controls on the 'cloud' vehicle don't mix with instant-death and long gaps between checkpoints.
Monkey's 'cloud' vehicle (basically a hover-board) is primarily used for traversing large open spaces, however some of these sections require players to navigate tight spaces between bombs that instantly kill the player if they touch one. This feels like the cloud 's functionality is being extended beyond its original purpose. The issue here is that in order to navigate the tight spaces often requires the player move the cloud from a standing start. The acceleration from a standing start is quite high and the smallest movement of the analogue stick causes the cloud to move, leading to imprecision. This in itself could be forgiveable but coupled with the fact the player is killed for taking a wrong step and the lengthy spaces between checkpoints can be frustrating.
If the designers felt it necessary to include sections that require the vehicle to be used for different purposes then it's important the vehicle be able to handle them. In this instance there are several possible solutions: i) make the cloud less sensitive when moving from a standing start, ii) make the spaces between the bombs larger, iii) bombs cause less damage, iv) make gaps between checkpoints much shorter.
5. The Trip Shop doesn't expand Monkey's abilities, rather just incrementally improves his existing abilities.
The 'Trip Shop' gives a way for players to spend the resources they've collected, i.e. energy orbs, on upgrading their abilities. One thing I found surprising about the shop was how little the variety it offered in terms of providing opportunities for players to change the way play. The shop essentially allows players to incrementally improve their existing moves by perhaps increasing melee or ranged damage or shield duration. This is a very cost effective way for the designers to create an incentive for players to vest an interest in the game's economy; it's easy to implement and simple to balance. I find it to be a false economy though, as the lack of real variety or depth to combat scenarios is apparent after a few hours of play, especially in the later levels where combat provides a lot of the gameplay.
By creating more unique skills for the player to buy, the game's economy immediately becomes more relevant and more rewarding to invest in. For example in the Devil May Cry series the player collects red orbs by slaying enemies and exploring environments, the player is able to spend the orbs on different combat techniques that may appeal to the player's style. It's all about giving the player the choice of whether to save up for an upgrade they think sounds cool or perhaps investing in something a little more mundane but recognisably useful like more health, and although Enslaved has this system, the lack of new skills that the player can purchase limits the shop's appeal.
So, introductions over let's take a look at Ninja Theory's Enslaved: Odyssey to the West. It's a third-person action adventure with emphasis on environment traversal, platform mechanics and combat. The game's story is an adaptation of the classic Chinese text Journey to the West, written by screen-writer and novelist Alex Garland. Taking place in a post-apocalyptic near-future New York, the player takes the role of Monkey; a grizzled anti-hero with exceptional acrobatic abilities. The early moments of the game see Monkey team up with a young girl named Trip, whose great skill in manipulating gadgets and machinery can be used in tandem with Monkey's combat prowess to overcome puzzles and combat scenarios. Much of the core experience is in the player navigating environments while making use of Trip's special abilities remotely (the narrative explains this by allowing Monkey to communicate with Trip through his headband and vice-versa). Without further ado here are the 5 design decisions I've opted to discuss:
1.Objects the player can climb are highlighted, providing a breadcrumb trail to aid traversing environments.
Highlighting which objects can be climbed on helps stop players getting lost and generally gives them a nudge in the right direction while they navigate the game's vertical spaces. What strikes me in particular are the actual objects themselves and how they've been worked into the environment. It seems that each object Monkey can interact with has been designed to blend naturally with the surrounding environment, with some of the interactive objects more obvious than others (for example a horizontal pole offers more directional guidance than a loose brick in a wall). It seems that by applying more realism in the environment the developers found it necessary to artificially point out climbable objects with a shimmering graphical effect. I found this system gave the traversal mechanic a pedestrian feel after experiencing it for an hour or so; all the tension and fear I should feel by leaping over chasms and scaling vertical surfaces evaporated.
One alternative to this would be to create a more cohesive visual language for objects that the player can climb. An excellent example of this is in the Uncharted games, where interactive traversal objects have a distinct visual style but are also modelled into the environment. Another alternative would be to only show the shimmering visual for the 'tutorial' levels.
2. Tech orbs
Enslaved encourages exploration by placing Tech orbs off the beaten track, the orbs function as in-game currency and allow players to purchase upgrades from a shop. I found the orb's visual style and the way they sit in the environment abrasive to say the least; there's something about floating balls of energy that doesn't gel in a world otherwise preoccupied with realism. They really end up representing a video game trope.
The designers obviously wanted players to be able to see the orbs from some distance, maybe in hard to reach areas, to draw the player toward them. I think a better solution would have been to build the orbs into the world rather than them being disembodied glowing things. The narrative explains the orbs as sources of energy, so perhaps modelling a few different items capable of storing 'energy' (e.g. fuel tanks, cannisters, engines etc), placing them around the environment and getting players to smash them open to receive the orbs would have been less incongruous. Again, to return to Uncharted, its own collectables are part of the game's world: artifacts, statues, antiques etc, all of which adds to the sense of a believable world and not just a transparent mechanic laid out by a designer. Similarly the God of War series stores orbs in detritus; pots, barrels etc – all objects that fit in with the environment the player's exploring.
3. Enemy attacks are difficult to distinguish from each other.
Each enemy in the game has a set of combat moves, but I found learning which move the enemy was about to use on me difficult, leaving me unsure of how to react. This seems in part due to the animations for each attack being quite similar (not to mention most of the enemies bear a huge resemblance to one another, making distinguishing even harder).
When creating a combat system it's vital that players are able to learn enemy attack patterns, for example in the Halo series players are made aware that a grenade is about to be thrown at them through distinctive visual and audible cues: i) when an enemy is about the throw a grenade we briefly see it glow bright blue in their hands, ii) there's about a 1 second animation for the enemy actually throwing the grenade, which we can clearly see from a distance because of the grenade's colour intensity, iii) the grenade is thrown toward the player at a constant speed each time, so the player learns how to avoid it. iv) the grenade has a very clear and distinct sound, so even if players can't actually see the grenade they can still hear it.
4. Twitchy controls on the 'cloud' vehicle don't mix with instant-death and long gaps between checkpoints.
Monkey's 'cloud' vehicle (basically a hover-board) is primarily used for traversing large open spaces, however some of these sections require players to navigate tight spaces between bombs that instantly kill the player if they touch one. This feels like the cloud 's functionality is being extended beyond its original purpose. The issue here is that in order to navigate the tight spaces often requires the player move the cloud from a standing start. The acceleration from a standing start is quite high and the smallest movement of the analogue stick causes the cloud to move, leading to imprecision. This in itself could be forgiveable but coupled with the fact the player is killed for taking a wrong step and the lengthy spaces between checkpoints can be frustrating.
If the designers felt it necessary to include sections that require the vehicle to be used for different purposes then it's important the vehicle be able to handle them. In this instance there are several possible solutions: i) make the cloud less sensitive when moving from a standing start, ii) make the spaces between the bombs larger, iii) bombs cause less damage, iv) make gaps between checkpoints much shorter.
5. The Trip Shop doesn't expand Monkey's abilities, rather just incrementally improves his existing abilities.
The 'Trip Shop' gives a way for players to spend the resources they've collected, i.e. energy orbs, on upgrading their abilities. One thing I found surprising about the shop was how little the variety it offered in terms of providing opportunities for players to change the way play. The shop essentially allows players to incrementally improve their existing moves by perhaps increasing melee or ranged damage or shield duration. This is a very cost effective way for the designers to create an incentive for players to vest an interest in the game's economy; it's easy to implement and simple to balance. I find it to be a false economy though, as the lack of real variety or depth to combat scenarios is apparent after a few hours of play, especially in the later levels where combat provides a lot of the gameplay.
By creating more unique skills for the player to buy, the game's economy immediately becomes more relevant and more rewarding to invest in. For example in the Devil May Cry series the player collects red orbs by slaying enemies and exploring environments, the player is able to spend the orbs on different combat techniques that may appeal to the player's style. It's all about giving the player the choice of whether to save up for an upgrade they think sounds cool or perhaps investing in something a little more mundane but recognisably useful like more health, and although Enslaved has this system, the lack of new skills that the player can purchase limits the shop's appeal.
Tuesday, 9 November 2010
Why you should care about...paper iteration
Our two-man indie studio is currently prototyping a game we've codenamed ZOMG. In this post I'd like to share our experience of prototyping and iterating ZOMG's early design, what went right, wrong and how we can improve this process in the future.
Starting out as a junior designer for a big development studio I was keen to prove myself, coming up with impressive and complicated solutions for the features I was working on. They were going to be the best, most awesome features that would change the state of play forever! Of course, when reality hit and the features were already half-implemented I realised they weren't the most awesome things ever. The whole team was in serious crunch so ripping out the code for a redesign simply wasn't an option. All that was left to do was clumsily edit the features as best as possible, which lead to some incongruity with the rest of the game.
At the time I felt pretty crappy but I came away from that experience with a better understanding of the importance of paper iteration. It seems obvious, but you don't need to wait until a feature makes it into the game to start the process of iterating and refining. Iteration on paper can save you a lot of headaches; it's cheap, can give you a clear picture on what you're trying to create and saves programmers' valuable time by not having to overhaul your system when it doesn't work out (and trust me, it won't work out first time).
You can design anything on paper so don't be put off by the fact your game is action oriented. Be creative during this process, for example if you want to see how a particular puzzle plays out in a third-person action game you can lay out the environment top-down on graph paper, use cardboard cut-outs to represent moving scenery and Warhammer figures to represent the player or enemies. You may know roughly how fast the player-character runs or climbs or takes to perform certain animations so try and recreate that in your paper prototype – use anything that can help express the experience you want to make. If you have the time and skills you could even use other game engines to mock-up your designs – whatever works! Xbox Live Arcade hit Shadow Complex used nothing more complex than cardboard and graph paper to allow the designers to play the entire game before anything was committed to code.
There is, of course, a downside. Just because something looks good on paper doesn't necessarily guarantee it'll be fun when it makes it into the game. Our initial designs of ZOMG went through several paper iterations and when we were confident we'd hit the money we made a first pass getting something playable in-game. The prototype raised more questions than it answered and eventually lead us to completely rethink the core experience.
So, what could we have done to prevent this? Well, it's difficult to be sure if additional time spent on the paper prototype could have told us the design was effectively no fun but I think if we were more thorough we'd have spotted some of the more glaring usability problems. The initial design we coded was essentially a 2D platformer where all movement and jumping was handled by the game (yep, we actually made a game that played itself - that's how we roll) and it was up to the player to control whether the character was facing forward, therefore in obstacle avoidance mode, or facing backwards, therefore shooting his pursuers. It was designed to be fast paced with twitch gameplay. What we found almost immediately was that players had no reference point to how close to an obstacle or pit they needed to be for the game to avoid it for them. There were some solutions we entertained, such as marking out 'jump zones' to indicate where the player needed to be to jump, but really it just solidified the fact that it wasn't a great idea. We were fortunate in the sense that a lot of what we'd prototyped wasn't wasted, for example the procedural terrain generator and the 2D platform engine were both proven in the initial prototype.
It's important not to treat in-game prototypes as dumping grounds for whatever ideas crop up in brainstorm sessions and to keep revising ideas until you're confident they can work in-game, but don't be afraid to discard ideas if they don't cut the mustard.
One last pointer, if you're not the one coding the feature into the game don't forget to take your paper prototype to the person who's actually doing the work. There's nothing worse than a programmer receiving a doc just dictating what they should do. It's imperative that they have ownership of the feature too, they may even come up with better solutions or spot flaws you haven't!
Starting out as a junior designer for a big development studio I was keen to prove myself, coming up with impressive and complicated solutions for the features I was working on. They were going to be the best, most awesome features that would change the state of play forever! Of course, when reality hit and the features were already half-implemented I realised they weren't the most awesome things ever. The whole team was in serious crunch so ripping out the code for a redesign simply wasn't an option. All that was left to do was clumsily edit the features as best as possible, which lead to some incongruity with the rest of the game.
At the time I felt pretty crappy but I came away from that experience with a better understanding of the importance of paper iteration. It seems obvious, but you don't need to wait until a feature makes it into the game to start the process of iterating and refining. Iteration on paper can save you a lot of headaches; it's cheap, can give you a clear picture on what you're trying to create and saves programmers' valuable time by not having to overhaul your system when it doesn't work out (and trust me, it won't work out first time).
You can design anything on paper so don't be put off by the fact your game is action oriented. Be creative during this process, for example if you want to see how a particular puzzle plays out in a third-person action game you can lay out the environment top-down on graph paper, use cardboard cut-outs to represent moving scenery and Warhammer figures to represent the player or enemies. You may know roughly how fast the player-character runs or climbs or takes to perform certain animations so try and recreate that in your paper prototype – use anything that can help express the experience you want to make. If you have the time and skills you could even use other game engines to mock-up your designs – whatever works! Xbox Live Arcade hit Shadow Complex used nothing more complex than cardboard and graph paper to allow the designers to play the entire game before anything was committed to code.
There is, of course, a downside. Just because something looks good on paper doesn't necessarily guarantee it'll be fun when it makes it into the game. Our initial designs of ZOMG went through several paper iterations and when we were confident we'd hit the money we made a first pass getting something playable in-game. The prototype raised more questions than it answered and eventually lead us to completely rethink the core experience.
So, what could we have done to prevent this? Well, it's difficult to be sure if additional time spent on the paper prototype could have told us the design was effectively no fun but I think if we were more thorough we'd have spotted some of the more glaring usability problems. The initial design we coded was essentially a 2D platformer where all movement and jumping was handled by the game (yep, we actually made a game that played itself - that's how we roll) and it was up to the player to control whether the character was facing forward, therefore in obstacle avoidance mode, or facing backwards, therefore shooting his pursuers. It was designed to be fast paced with twitch gameplay. What we found almost immediately was that players had no reference point to how close to an obstacle or pit they needed to be for the game to avoid it for them. There were some solutions we entertained, such as marking out 'jump zones' to indicate where the player needed to be to jump, but really it just solidified the fact that it wasn't a great idea. We were fortunate in the sense that a lot of what we'd prototyped wasn't wasted, for example the procedural terrain generator and the 2D platform engine were both proven in the initial prototype.
It's important not to treat in-game prototypes as dumping grounds for whatever ideas crop up in brainstorm sessions and to keep revising ideas until you're confident they can work in-game, but don't be afraid to discard ideas if they don't cut the mustard.
One last pointer, if you're not the one coding the feature into the game don't forget to take your paper prototype to the person who's actually doing the work. There's nothing worse than a programmer receiving a doc just dictating what they should do. It's imperative that they have ownership of the feature too, they may even come up with better solutions or spot flaws you haven't!
Saturday, 6 November 2010
The trouble with trials.
I'm rather surprised at how unsophisticated the App Store is when it comes to trial versions of software. Right now the only option for customers to try before they buy is the 'Lite' version of an App; a separate free download that reserves certain content for the full version, or in some cases is the full version but funded by in-game ads. Inevitably some developers opt out of creating two separate SKU's, leaving consumers to chance a purchase.
I write about this in particular as I recently made a purchase on the App Store using my iPod Touch. The game in question is rendered in 3D (though has '2D gameplay') and runs quite poorly on my iPod, enough to negatively impact the 'twitch' gameplay experience at any rate. With no free Lite version available I had to purchase the game to find out it was effectively unplayable. You could argue that at £1.19 it wasn't much of a loss but that shouldn't even enter into it; had I known this beforehand I wouldn't have bought the game.
In this respect the App Store seems completely backwards, especially in comparison to the more elegant Xbox Live Indie Games trial system where you download the full game right away but until you unlock the full version you can only play for a limited time. Of course, this wouldn't necessarily be appropriate for digital distribution services like Steam where games can run into the giga-bytes, but for the App Store or other services it's baffling why consumers don't have a clear way to try the product they're buying.
I'm not entirely sure of Apple's mentality behind a system that encourages developers to release two SKU's to allow consumers to try their product. Having a 'trial' option similar to XBLIG's, where consumers are prompted to make a purchase after a set time would surely translate into more sales, especially if the player is already hooked on the game when they receive the message.
UPDATE: Check here for some conversion rates from trial to full game (courtesy of Mommy's Best Games): http://mommysbest.blogspot.com/2010/04/shoot-1up-daily-sales.html
I write about this in particular as I recently made a purchase on the App Store using my iPod Touch. The game in question is rendered in 3D (though has '2D gameplay') and runs quite poorly on my iPod, enough to negatively impact the 'twitch' gameplay experience at any rate. With no free Lite version available I had to purchase the game to find out it was effectively unplayable. You could argue that at £1.19 it wasn't much of a loss but that shouldn't even enter into it; had I known this beforehand I wouldn't have bought the game.
In this respect the App Store seems completely backwards, especially in comparison to the more elegant Xbox Live Indie Games trial system where you download the full game right away but until you unlock the full version you can only play for a limited time. Of course, this wouldn't necessarily be appropriate for digital distribution services like Steam where games can run into the giga-bytes, but for the App Store or other services it's baffling why consumers don't have a clear way to try the product they're buying.
I'm not entirely sure of Apple's mentality behind a system that encourages developers to release two SKU's to allow consumers to try their product. Having a 'trial' option similar to XBLIG's, where consumers are prompted to make a purchase after a set time would surely translate into more sales, especially if the player is already hooked on the game when they receive the message.
UPDATE: Check here for some conversion rates from trial to full game (courtesy of Mommy's Best Games): http://mommysbest.blogspot.com/2010/04/shoot-1up-daily-sales.html
Subscribe to:
Posts (Atom)