Mark Brown released a new Game Maker's Toolkit, which you can find here. This is largely a response to that video.
The basic premise is that the "Nintendo approach" to level design is to take one core challenge and follow the same set of progressive difficulty enhancements: safe introduction, slightly less safe thing, unsafe thing, then a few dozen twists to change the challenge somewhat.
He uses the design of Donkey Kong Country: Tropical Freeze to offer a counter-example, where ideas and themes are largely mixed together in clever ways. For example, sawblades don't just threaten you, they also carve out platforms. This level has leaves and horns, etc.
... Those are the same design philosophy.
There are differences in implementation, sure. Mostly because the mainline Super Mario games are extreeeeemely tired.
Tropical Freeze seems to be more creative in their theming, using a broader variety of themed challenges and better spectacle setpieces. This is probably because they A) have better technology and B) aren't exhausted and tired like the mainline Super Mario games. Other Mario games like Paper Mario, Mario Galaxy, and Mario Sunshine tend to have more creative levels with strong theming - comparing their best levels to Tropical Freeze's seems more evenly matched, with levels where island rise from the water, exploding volcanoes, collapsing buildings, and so on being far more common.
It may sound like I think the video is baseless, but I don't think that's true. I simply think he's comparing bad and good implementations of the same level design philosophy.
It's good to discuss pacing, and the limits of theming. Unfortunately, that's not how the video was pitched, at least not to my ears. It sounds like he's talking about things "Mario doesn't do". Mario doesn't do them in the mainline games because those are tired, not because they're not part of Nintendo's arsenal.
I'm not arguing that the basic idea of themed rising challenges mixed with spectacle is good or bad. It's one approach, and it's a fairly well-understood and robust approach. There are lots of other approaches with other priorities, and they're not mutually exclusive: an open-world game would have a hard time sticking to this formula, but they can certainly use the formula as a foundation to pace the player's entrance into a new area with its new themes and challenges.
Showing posts with label level design. Show all posts
Showing posts with label level design. Show all posts
Friday, June 16, 2017
Thursday, July 31, 2014
Star Trek Interiors
One of the things I like to do is think about interior spaces in video games.
If you look up "interior spaces in video games", you'll find a lot of guides about level design, but that's not what I'm talking about. I'm talking about places where people work and live.
If you study interior spaces as where people work and live, you'll find a lot of real-world interior decorating/architecture stuff, but it's only mildly applicable to video game spaces. An avatar that appears to live in a space needs to be treated differently than a person who actually lives in a space.
I started thinking about other kinds of interior design, and the answer was obvious: set design.
Of course I'll start with Star Trek, because Star Trek had a whole lot of interiors. The audience had to believe that the crew could live in the ship, 24/7, for months on end. Because of that, the interiors were often surprisingly well-designed.
In TOS, the sets were designed pretty freely, and the result is that the original Enterprise had a claustrophobic feel. While it is believable that people could operate in that environment, it was a bit too cluttered to "feel right", especially for a video game. Recreations of interiors in TOS-style have been done many times in video games, but they are usually scaled up dramatically. This backfires: while they no longer feel cluttered, they also no longer feel coherent.
To talk about a specific example, in TOS the quarters were a lovingly-crafted "L" shape with a signature curved half-wall between the bed and the living space. This room is very practical and makes a huge amount of sense for a crewmember living alone, eating in the cafeteria. In STO Academy, these rooms are recreated, but they are scaled way, way up to hilarious sizes. The whole point of the original room was it was tiny, cozy, utilitarian. The same room scaled up appears bizarrely empty, with a tiny bed surrounded by acres of empty space on either side, then the signature half-wall.
Another problem with the TOS sets is that they aren't third-person-camera ready. While they work pretty well for TV cameras, even then there were times when the directors were clearly struggling to find a good angle.
Along comes TNG, and all these problems went away.
The hallways are gently curved and organic. The gentle curve was a boon, keeping scenes intimate without making the corridor feel chopped up or confined.
The rooms in TNG were huuuuge. This was a ship with families on board, not a military vehicle, so it was quite posh. Even small, functional rooms like the transporter bay were much larger than they needed to be. This was a huge boon to the directors and cameramen, of course, but it's also a huge boon to game designers: upscaled spaces are much easier to navigate and understand when playing a game.
To counteract the naturally "boxy" feel of large rooms, outside walls tended to be curved both vertically and horizontally - a conceit that fits the ship's saucer section design. This completely destroys the squareness of the rooms and gives them a futuristic feel at the same time. In fantasy games, this same sort of thing would be accomplished using wooden structural beams and canted ceilings.
The quarters in TNG were a stark contrast to those in TOS, and were so much better that Kirk would have cried. In general they were split into several rooms by open, full-height gateways. Although it was never made clear, it looked as if the wings of the gateways could be slid shut to create proper rooms. It was a very livable design for crewmembers not living alone and eating inside.
Strangely, nobody's quarters were ever messy.
The signature half-walls made a reappearance as dividers against the curved wall. They worked to break space up without closing space off, making them a boon to the cameramen.
Video games continued to scale these spaces up, leaving vast swaths of empty carpet.
Babylon 5 had most of the same concerns as TNG in terms of living space, but took everything a lot further. They didn't modify the walls or ceilings to diminish the box-like effect of their interior spaces. Instead, none of their spaces were box-like. They bent over backwards to make nearly every interior space a jumble of curved and straight spaces, with plenty of oddball "pocket rooms" that weren't actually separate, but completely broke up the room's footprint.
Back to Star Trek. DS9 took another approach, breaking up the shape of the room by creating little landings above and below the typical floor height. When that didn't fit, they went with an aggressively curvy look and very high ceilings. The good news is that this approach worked well when scaled up for the video games, as the platforms, curved walls, and vaulted ceilings all scaled up at the same rate as the amount of carpet.
Now, if we're going to think about video game interior spaces, we need to take these lessons into account.
Again, not talking about "level design". Talking about virtual spaces virtual people live in.
What will work will probably depend on what sort of camera the game has. A first-person camera will always be able to see the ceiling, for example, but a third-person camera will only rarely see the ceiling. Similarly, a third-person camera means that the camera can get "caught", leaving pieces of the level geometry obscuring your view of your character... and contrariwise, you can slide it around to get a much better view of the area than your character might actually have. This means that islands work well in first person view, while L-shapes are clearer in third-person view.
I don't being these up for game balance purposes, but for design purposes. What the player will see will be what the player notices. A third-person game can employ L-shapes and pocket rooms as part of the general design, but in a first-person game those would be secret corners you would need to scout out manually. On the other hand, the ceiling and the height of the floor are critical parts of the room design in a first-person game, but in a third person game one is invisible and the other is played way down due to the higher camera angle.
The other aspect of this is the NPCs that inhabit the space. Right now, I'm busily building a library to help them feel like they actually live in these spaces by giving them various kinds of clutter, but there's also just the way they use the space while you're around.
This is one thing Skyrim did very well for its time, and came in two pieces.
The first thing was that the NPCs would putter around. Especially in Riverwood (the first village), people would move through their houses in ways that made the houses feel real, such as the way they would cut around the table and interact with a bureau in a nook, or stand at the top of the stairs to watch you as you rummaged around their basement.
The second thing was that the design of the houses gave rise to certain kinds of interactions between the player and the NPCs. This was a delicate thing, and if you didn't play a thief you may not have noticed.
For example, most houses had the upper floor overlook the lower floor, giving NPCs a much wider range of vision. This added a very nice, rustic feel to the houses in addition to adding texture to your attempts to look around or hide. Many places had multiple beds in clear proximity to each other, making it a high-risk situation to navigate around or steal things at night.
These could be punched up considerably if we understand what we're trying to do.
In general, here are some ideas I want to explore as I develop houses for this fantasy prototype:
1) Structural beams, both horizontal and vertical.
2) Complex ceilings - vaulted, canted, curved, etc. Structural beams integrated, of course.
3) No heating ducts, so most areas have open connections.
4) Raised/sunken areas, perhaps integrated with features such as plumbing, natural rock, stowage, tables, etc.
5) Second floors which are openly connected to the first floor, not walled off.
6) "Light" doorways, such as beads, sliding doors, or curtains. Allow NPCs to adjust them properly.
7) Partial walls such as half-walls, integrated counters, folding screens, etc. Allow NPCs to adjust them if possible.
8) Variable room configurations - bedding that gets put away, or has screens erected between beds only at night.
9) Adjustable ventilation such as windows, liftable walls, and propped-open "skylight" ceilings. Below-floor too, perhaps.
10) Large, glassless windows that swing open, lever outward, etc. Drapery across them for cold times. Again, NPC-useable.
11) Pocket rooms that break up the footprint of the house. Integrate them into exterior spaces if possible.
12) Curved regions, most vertical, but some horizontal. Horizontal curves are probably made of rock or brick, not wood.
13) Non-orthogonal walls to break up boxiness.
14) Multiple kinds of walls. Mix bricks/rocks, wood, plaster, etc. This was actually pretty common, and would look neat.
15) Organic shapes, probably mostly due to draped cloth or wooden "ribs".
16) Focus on which spaces belong to which NPCs and how much that is respected.
17) Focus on how the NPC's behavior interacts with and keeps an eye on other NPCs, including through windows. Ideally, make them interact with each other across these spaces instead of standing toe to toe and chatting every time.
If you look up "interior spaces in video games", you'll find a lot of guides about level design, but that's not what I'm talking about. I'm talking about places where people work and live.
If you study interior spaces as where people work and live, you'll find a lot of real-world interior decorating/architecture stuff, but it's only mildly applicable to video game spaces. An avatar that appears to live in a space needs to be treated differently than a person who actually lives in a space.
I started thinking about other kinds of interior design, and the answer was obvious: set design.
Of course I'll start with Star Trek, because Star Trek had a whole lot of interiors. The audience had to believe that the crew could live in the ship, 24/7, for months on end. Because of that, the interiors were often surprisingly well-designed.
In TOS, the sets were designed pretty freely, and the result is that the original Enterprise had a claustrophobic feel. While it is believable that people could operate in that environment, it was a bit too cluttered to "feel right", especially for a video game. Recreations of interiors in TOS-style have been done many times in video games, but they are usually scaled up dramatically. This backfires: while they no longer feel cluttered, they also no longer feel coherent.
To talk about a specific example, in TOS the quarters were a lovingly-crafted "L" shape with a signature curved half-wall between the bed and the living space. This room is very practical and makes a huge amount of sense for a crewmember living alone, eating in the cafeteria. In STO Academy, these rooms are recreated, but they are scaled way, way up to hilarious sizes. The whole point of the original room was it was tiny, cozy, utilitarian. The same room scaled up appears bizarrely empty, with a tiny bed surrounded by acres of empty space on either side, then the signature half-wall.
Another problem with the TOS sets is that they aren't third-person-camera ready. While they work pretty well for TV cameras, even then there were times when the directors were clearly struggling to find a good angle.
Along comes TNG, and all these problems went away.
The hallways are gently curved and organic. The gentle curve was a boon, keeping scenes intimate without making the corridor feel chopped up or confined.
The rooms in TNG were huuuuge. This was a ship with families on board, not a military vehicle, so it was quite posh. Even small, functional rooms like the transporter bay were much larger than they needed to be. This was a huge boon to the directors and cameramen, of course, but it's also a huge boon to game designers: upscaled spaces are much easier to navigate and understand when playing a game.
To counteract the naturally "boxy" feel of large rooms, outside walls tended to be curved both vertically and horizontally - a conceit that fits the ship's saucer section design. This completely destroys the squareness of the rooms and gives them a futuristic feel at the same time. In fantasy games, this same sort of thing would be accomplished using wooden structural beams and canted ceilings.
The quarters in TNG were a stark contrast to those in TOS, and were so much better that Kirk would have cried. In general they were split into several rooms by open, full-height gateways. Although it was never made clear, it looked as if the wings of the gateways could be slid shut to create proper rooms. It was a very livable design for crewmembers not living alone and eating inside.
Strangely, nobody's quarters were ever messy.
The signature half-walls made a reappearance as dividers against the curved wall. They worked to break space up without closing space off, making them a boon to the cameramen.
Video games continued to scale these spaces up, leaving vast swaths of empty carpet.
Babylon 5 had most of the same concerns as TNG in terms of living space, but took everything a lot further. They didn't modify the walls or ceilings to diminish the box-like effect of their interior spaces. Instead, none of their spaces were box-like. They bent over backwards to make nearly every interior space a jumble of curved and straight spaces, with plenty of oddball "pocket rooms" that weren't actually separate, but completely broke up the room's footprint.
Back to Star Trek. DS9 took another approach, breaking up the shape of the room by creating little landings above and below the typical floor height. When that didn't fit, they went with an aggressively curvy look and very high ceilings. The good news is that this approach worked well when scaled up for the video games, as the platforms, curved walls, and vaulted ceilings all scaled up at the same rate as the amount of carpet.
Now, if we're going to think about video game interior spaces, we need to take these lessons into account.
Again, not talking about "level design". Talking about virtual spaces virtual people live in.
What will work will probably depend on what sort of camera the game has. A first-person camera will always be able to see the ceiling, for example, but a third-person camera will only rarely see the ceiling. Similarly, a third-person camera means that the camera can get "caught", leaving pieces of the level geometry obscuring your view of your character... and contrariwise, you can slide it around to get a much better view of the area than your character might actually have. This means that islands work well in first person view, while L-shapes are clearer in third-person view.
I don't being these up for game balance purposes, but for design purposes. What the player will see will be what the player notices. A third-person game can employ L-shapes and pocket rooms as part of the general design, but in a first-person game those would be secret corners you would need to scout out manually. On the other hand, the ceiling and the height of the floor are critical parts of the room design in a first-person game, but in a third person game one is invisible and the other is played way down due to the higher camera angle.
The other aspect of this is the NPCs that inhabit the space. Right now, I'm busily building a library to help them feel like they actually live in these spaces by giving them various kinds of clutter, but there's also just the way they use the space while you're around.
This is one thing Skyrim did very well for its time, and came in two pieces.
The first thing was that the NPCs would putter around. Especially in Riverwood (the first village), people would move through their houses in ways that made the houses feel real, such as the way they would cut around the table and interact with a bureau in a nook, or stand at the top of the stairs to watch you as you rummaged around their basement.
The second thing was that the design of the houses gave rise to certain kinds of interactions between the player and the NPCs. This was a delicate thing, and if you didn't play a thief you may not have noticed.
For example, most houses had the upper floor overlook the lower floor, giving NPCs a much wider range of vision. This added a very nice, rustic feel to the houses in addition to adding texture to your attempts to look around or hide. Many places had multiple beds in clear proximity to each other, making it a high-risk situation to navigate around or steal things at night.
These could be punched up considerably if we understand what we're trying to do.
In general, here are some ideas I want to explore as I develop houses for this fantasy prototype:
1) Structural beams, both horizontal and vertical.
2) Complex ceilings - vaulted, canted, curved, etc. Structural beams integrated, of course.
3) No heating ducts, so most areas have open connections.
4) Raised/sunken areas, perhaps integrated with features such as plumbing, natural rock, stowage, tables, etc.
5) Second floors which are openly connected to the first floor, not walled off.
6) "Light" doorways, such as beads, sliding doors, or curtains. Allow NPCs to adjust them properly.
7) Partial walls such as half-walls, integrated counters, folding screens, etc. Allow NPCs to adjust them if possible.
8) Variable room configurations - bedding that gets put away, or has screens erected between beds only at night.
9) Adjustable ventilation such as windows, liftable walls, and propped-open "skylight" ceilings. Below-floor too, perhaps.
10) Large, glassless windows that swing open, lever outward, etc. Drapery across them for cold times. Again, NPC-useable.
11) Pocket rooms that break up the footprint of the house. Integrate them into exterior spaces if possible.
12) Curved regions, most vertical, but some horizontal. Horizontal curves are probably made of rock or brick, not wood.
13) Non-orthogonal walls to break up boxiness.
14) Multiple kinds of walls. Mix bricks/rocks, wood, plaster, etc. This was actually pretty common, and would look neat.
15) Organic shapes, probably mostly due to draped cloth or wooden "ribs".
16) Focus on which spaces belong to which NPCs and how much that is respected.
17) Focus on how the NPC's behavior interacts with and keeps an eye on other NPCs, including through windows. Ideally, make them interact with each other across these spaces instead of standing toe to toe and chatting every time.
Friday, November 23, 2012
The Nature of a Stage
Let's talk about stages in a video game.
Let's start by talking about the difference between an old game and a new game. The most obvious difference is that in a modern game, you're generally regenerated 100% after each fight.
This difference is not as straightforward as you might think, but it is a good place to start.
If we imagine the power level of the party as it fights through a stage, in a modern game the curve goes up. The party gets stronger as they move through the stage, with occasional dips for minibosses and heavyweight encounters.
If we imagine the power level of the party in an oldschool game like Doom or Final Fantasy 1, it goes down. Occasionally it might pop up a bit if you find a resource cache, but in general the encounters wear on you.
This difference... is unfortunately not entirely straightforward. For example, in Final Fantasy 1, you actually are gaining power as you fight enemies. It's just that you're gaining long-term power while losing short-term power. This is a typical RPG situation.
So let's consider stages in a slightly different light: as treadmills or one-offs.
Treadmill stages are stages that can be farmed. For example, in an RPG you might exit a dungeon and re-enter it to farm the enemies. Or you might just get into umpteen million random encounters. This grinding is very much like an MMORPG - the stages are not really part of the plot, they're just parts of the world that maybe have some handwave towards being part of the plot.
It doesn't matter whether your power level goes up or down as you get into fights in a treadmill stage. Instead, what matters is how much time you spend to raise your long-term power level, and how unique/useful your level-ups (equipment, loot, etc) are.
One-off stages are stages that you can only visit once. If they are part of the world, once you've gone through them they are typically husks without any particular challenges. The point of a one-off stage is to squeeze as much out of them as possible in the limited amount of time you have with them.
Nearly all shooters are like this - you want to find the various caches and secret collectibles scattered throughout the stage, and you only get to go through the stage once. FTL has an interesting take, where you have to plot the least efficient path through the sector you can, while still not getting caught by the marching wall of death that moves ever right.
One-offs can also squeeze in the opposite direction, where you need to get through and hit the objectives while losing as few resources as possible. This is exceptionally rare outside of survival horror, but it is possible.
There are a few other pieces to designing a stage. So, let's hit them quick.
1) Is this a one-off stage or a treadmill stage? If a one-off stage, the stage can be built to have a progression (pieces of it explode, collapse, etc) while if it is a treadmill stage it has to remain relatively static.
2) Is the stage the challenge, or is the stage where you prepare to meet a final challenge? You don't actually need a boss if the stage itself is the challenge.
3) Is the stage window dressing, or does the aesthetic/conceit of the stage actually influence the nature of the stage's challenges and progressions?
4) Are the encounters bite-size servings or are they part of an ongoing challenge? If they are part of a cohesive challenge, they need to have long-lasting effects.
5) Is the stage progression interesting enough that the player cares? This is both the variety of the challenges and the way the plot unfolds.
6) Can the player interact with the stage itself, or is the stage just rails the player travels down? This means - can the player express himself by interacting with the stage? Not can he open doors or flush toilets, but can he actually change the way the stage plays out some? This can be taking alternate approaches (sniping from the rafters vs rushing in) or in altering the stage itself (using rockets to blow away walls like in XCOM).
There we go. Next time, we'll talk about party composition!
Let's start by talking about the difference between an old game and a new game. The most obvious difference is that in a modern game, you're generally regenerated 100% after each fight.
This difference is not as straightforward as you might think, but it is a good place to start.
If we imagine the power level of the party as it fights through a stage, in a modern game the curve goes up. The party gets stronger as they move through the stage, with occasional dips for minibosses and heavyweight encounters.
If we imagine the power level of the party in an oldschool game like Doom or Final Fantasy 1, it goes down. Occasionally it might pop up a bit if you find a resource cache, but in general the encounters wear on you.
This difference... is unfortunately not entirely straightforward. For example, in Final Fantasy 1, you actually are gaining power as you fight enemies. It's just that you're gaining long-term power while losing short-term power. This is a typical RPG situation.
So let's consider stages in a slightly different light: as treadmills or one-offs.
Treadmill stages are stages that can be farmed. For example, in an RPG you might exit a dungeon and re-enter it to farm the enemies. Or you might just get into umpteen million random encounters. This grinding is very much like an MMORPG - the stages are not really part of the plot, they're just parts of the world that maybe have some handwave towards being part of the plot.
It doesn't matter whether your power level goes up or down as you get into fights in a treadmill stage. Instead, what matters is how much time you spend to raise your long-term power level, and how unique/useful your level-ups (equipment, loot, etc) are.
One-off stages are stages that you can only visit once. If they are part of the world, once you've gone through them they are typically husks without any particular challenges. The point of a one-off stage is to squeeze as much out of them as possible in the limited amount of time you have with them.
Nearly all shooters are like this - you want to find the various caches and secret collectibles scattered throughout the stage, and you only get to go through the stage once. FTL has an interesting take, where you have to plot the least efficient path through the sector you can, while still not getting caught by the marching wall of death that moves ever right.
One-offs can also squeeze in the opposite direction, where you need to get through and hit the objectives while losing as few resources as possible. This is exceptionally rare outside of survival horror, but it is possible.
There are a few other pieces to designing a stage. So, let's hit them quick.
1) Is this a one-off stage or a treadmill stage? If a one-off stage, the stage can be built to have a progression (pieces of it explode, collapse, etc) while if it is a treadmill stage it has to remain relatively static.
2) Is the stage the challenge, or is the stage where you prepare to meet a final challenge? You don't actually need a boss if the stage itself is the challenge.
3) Is the stage window dressing, or does the aesthetic/conceit of the stage actually influence the nature of the stage's challenges and progressions?
4) Are the encounters bite-size servings or are they part of an ongoing challenge? If they are part of a cohesive challenge, they need to have long-lasting effects.
5) Is the stage progression interesting enough that the player cares? This is both the variety of the challenges and the way the plot unfolds.
6) Can the player interact with the stage itself, or is the stage just rails the player travels down? This means - can the player express himself by interacting with the stage? Not can he open doors or flush toilets, but can he actually change the way the stage plays out some? This can be taking alternate approaches (sniping from the rafters vs rushing in) or in altering the stage itself (using rockets to blow away walls like in XCOM).
There we go. Next time, we'll talk about party composition!
Saturday, November 15, 2008
Mirror's Edge
This is in two parts. The first part is me making my typical whiny review of a game (no spoilers). The second is me discussing design details. If you don't care to hear my whining, skip to the "***". The other "***", obviously. I mean, uh, the FOURTH "***".
So I'm playing Mirror's Edge. I'd like to remind everyone that I love moving in games. I love my avatar maneuvering through levels. It's a passion. So, I would say that I am their target audience.
It's not a game I can give a numeric rating to. Like the first Sly Cooper, there's nothing else in the niche to rate it against. Unfortunately, Unlike Sly Cooper, it is a pretty badly flawed game.
It's not a BAD game. It's just that, like its main character, it tends to fall short a lot.
First, the cutscenes are mostly 2D animations done by the Esurance guys. That style works well for snappy commercials, but is ill-suited for anything faster, slower, or more fluid. When they can tween, they run at full frames, but when they actually have to redraw a frame, they drop to animating on twos. There's nothing wrong with animating on twos IF YOU STICK TO IT, but switching framerates mid-scene is horribly jarring. Also, they don't use any animator's tricks, so things like sprinting appear very disjointed and jumpy instead of appearing properly fluid.
If I had to describe their animation style, it would be a graphical quality slightly below that of Teen Titans with the animation quality of South Park. So, not very impressed.
Also not impressed by the character design. All the characters are painfully bog-standard except the main character, who is painfully bog-standard and ugly. I'm impressed by the shoe design, and by the way that the level designers played around with color and luminescence.
Graphically, the game is glitchy even on the 360, with numerous dropped polies and thin black origin lines flickering around. It also features The Return of the Long Ass Elevator Rides Two: Electric Boogaloo.
The story has only one upside: they didn't try to write a romance plot in. Unfortunately, everything they DID write in was painfully stereotypical. The only surprises in this game are in the level design - you won't find any in the plot. The "big twists" were evidently shocking to my avatar, but they only served to make me think Faith is a bit of a retard.
No, I take that back. There were surprises in the plot: when I overestimated them, they consistently surprised me by falling short.
Only bloody-mindedness kept me from skipping the cut scenes, which are badly written and animated in a style I don't much like. At least the audio is solid, with decent voice actors, decent sound effects, and very suitable and listenable-toable music.
The setting is a painfully bland police state with painfully bland corruption running its painfully bland course. At least it doesn't look so standard, thanks to the graphics used in the levels. It's a very CLEAN painfully bland city, you see, which actually adds to the experience.
"But that's all besides the point! It's all about the gameplay! How's this first-person free-running game PLAY?"
Weeeeelllllll... let's leave the bulk of that for the design section. But lets briefly talk about level design and pacing.
The game features a lot of classic navigation puzzlers a'la Prince of Persia, but the pacing is awkward unless you've memorized the levels. The fighting is a shame, included just because nobody can imagine releasing a noncombat game. It's terrible, whether you're kung-fu fighting with ninja (AKA "strafe, slide-kick, press Y") or fighting cops (AKA "Press X, press Y, hold the trigger"). It's not terrible in that it's EASY - you die like a dog - it's terrible in that it's NOT FUN.
The game is laser-focused on its linear path. There is no side exploration, no bonuses, no nothing. The closest you can get to expressing yourself as a player is to find little bags which serve ABSOLUTELY NO PURPOSE. There are no interesting secret zones, very little secret information (a few screens with a bit of text hidden in a corner, a few voice mail messages), very little of interest. There are occasionally multiple paths to your goal, but one is obviously better than the other and neither is particularly interesting.
***
Let's talk about the design details.
Moving a platformer into first-person view is a dangerous move, but one that's been brewing for a while. Games have become more and more free-running-esque as the years go by and our hardware improves. Prince of Persia has become a nostalgic look into the days when swinging from flagpoles was new and amazing. These days, even the (surprisingly good) TMNT game features more advanced motion than PoP, and games like Assassin's Creed and Crackdown make PoP look like a tinkertoy.
All of these games are third-person for a reason. As you know, Bob, platformer games are mostly about where you are in relation to other things. Like, say, the platforms.
If you can see where you are in relation to other things (IE, you can see your feet), you can know when and how to jump, land, and so forth. This is, as you might have guessed, an important part of your balanced daily not-falling-to-your-deathfast.
So moving to a first-person view offers some serious challenges. You have to keep in mind that your players don't have as clear a view as they normally do. It's very hard to chain motions together because first-person view means they'll only be looking at whatever they are about to hit instead of being able to see everything around them.
Mirror's Edge tried to solve this problem in two ways. First, it painted things red. Red means "jump here", and if you see something red, you'll remember where it is even if you can't see it precisely at the moment. In the game it is used primarily to tell you where it is safe to make blind jumps, but it is occasionally (and in my mind, more importantly) useful in highlighting a path through puzzling terrain. In either way it works to offset the limited view of the player, although in the former application (jumping off buildings) it offsets a limited view that even 3rd-person players have. Crackdown had to zoom pretty far out and up to give you a decent view of where you were jumping to in such situations, and it still wasn't perfect.
The second way Mirror's Edge tries to solve the problem is through level design. Most of the levels consist of climbing up sheer, blind faces (or staircases) for a while, and then running and jumping in a generally downward direction. This is helpful because if you're looking down at where you're about to go, you can get a pretty good mental map of the place even if your viewpoint will be too limited to see much when you're actually in it. This considerably offsets the blindness, especially since you can usually see the red marker showing you where you ought to go next.
However, these methods (and other aspects of their level design) take most of the spontaneity out of navigating the levels. It's all made very linear, mostly a matter of pressing the left bumper at the right times, occasionally while fiddling with the control sticks. When you are "free" to move around (say, on a rooftop), your freedom is pointless as the only things worth doing are moving to whatever is red or climbing to the highest point so you can see where you're going.
My problem isn't that such movement is boring: it isn't. Or, rather, it doesn't have to be. My problem is that they didn't really embrace it at all.
In most modern movement games (Assassin's Creed, for example) a big part of the gameplay is figuring out how to work your way to some location. Sometimes, it's painfully linear, but there's usually a rewarding rhythm and sense of progress - for example, finding a new plot element, getting an upgrade, climbing to someplace high, or finding something weird. Unfortunately, Mirror's Edge tries to do this, but there is never any sense of progress because they wanted to focus on relentless forward movement rather than the slow figuring-and-working-forward pace of normal movement games. They wanted to be more like Sonic, so they don't ever give you any roses to stop and smell.
In other movement games, flow is the point. TMNT and Crackdown are good examples. When these are linear, they are linear in a really obvious way to allow you to know well in advance what buttons you should press when, giving your avatar a continuous stream of uninterrupted forward movement. When they aren't linear, they allow you to freely explore an INTERESTING terrain, rather than a tiny rooftop. Mirror's Edge tried to do this with red things but they didn't take it very far: they wanted to be more like Assassin's Creed.
This has the added problem that Mirror's Edge is entirely first person, which means you are mostly good at seeing places you AREN'T. Fundamentally, I think it's a rotten choice for a movement-based game, because movement-based games are about changing where you are, not changing where you aren't.
Another big issue is that the players are limited by what they can recognize in addition to what they can see. Games like Crackdown make it easy because your method of movement is actually pretty simple and limited, just amped up to silliness. But in a proper free running game, your movement capabilities are going to be a lot more nuanced: you aren't just jumping the fence, you're scrambling over it, or maybe it's low enough to Kong. Similarly, maybe you need to wall jump up to the lattice across the way.
This would be almost impossible to properly see using third-person view, and it IS impossible to see using first-person view. This is why real parkour and free runner folks carefully familiarize themselves with wherever they are before they do anything dangerous: they need to know the "grooves" in the local space, places where their capabilities will allow them to fluidly move through. It's not something that can really be done on the fly.
Most games try to get around this with level design. Oh, look, it's a wall of exactly that height, so I know I can scramble up it, every time. And I know there will never be a wall of ALMOST that height, or a wall of that height I can't scramble up for some reason... and I know that if I vault that wall, I will land safely on the other side, no matter what the terrain.
But this doesn't help chains of movements. You know you can vault the wall, but you don't realize that you need to spring off the wall to the chandelier and then swing across through the window. The only way you can know that is if you've seen all the parts of the chain and have them mapped out in your head. That's much easier to do from third person.
Well, there are a few other options, I think. One is touched on in Mirror's Edge: important elements can stand out (in this case, be colored red). If used more excessively, they can form an unbroken chain of where you SHOULD be going, allowing you to maintain flow. I would actually suggest something a bit less world-centric, such as lines of flowing, floating pips.
This limits the puzzle-ability of your game, though. If there's always an obvious path to get where you want to go, you're not going to have to think about it much. Instead, you'll be more like Sonic or TMNT or Crackdown: navigating is a lot of fun, but many of the challenges come from exploration or combat rather than navigation.
Another option is to remove the realtime element from the game. If you "draw" your path in space rather than navigating it personally, it will allow you to analyze exactly what the situation is in a more relaxed way, allowing your avatar's progress to be fluid and sequenced even if YOUR progress involves tweaking paths for a minute.
Anyhow, either or both of these options would get rid of one of the stupidest parts of Mirror's Edge: DYING. Whoops, I died. Respawn. Whoops, I died. Respawn. Often five, six times in a row. Unlike TMNT, the respawn is a significant irritation which often takes you back forty or fifty seconds (this doesn't sound irritating until you realize that you have to repeat that minute many times if you're trying for a difficult jump). Also unlike TMNT, it MAKES NO SENSE. There is absolutely no reason given for your amazing respawn talent. It's not part of the game world in any way. It's just there to let the designers create levels that you have to play through several times to be able to beat.
Nothing breaks immersion like inexplicable and unrewarding failure mechanics. :P
All that aside, I think that there IS some potential here. First-person mechanics are inherently more immersive, and you could make a very exciting game if only you could figure out how the player would navigate it.
So I'm playing Mirror's Edge. I'd like to remind everyone that I love moving in games. I love my avatar maneuvering through levels. It's a passion. So, I would say that I am their target audience.
It's not a game I can give a numeric rating to. Like the first Sly Cooper, there's nothing else in the niche to rate it against. Unfortunately, Unlike Sly Cooper, it is a pretty badly flawed game.
It's not a BAD game. It's just that, like its main character, it tends to fall short a lot.
First, the cutscenes are mostly 2D animations done by the Esurance guys. That style works well for snappy commercials, but is ill-suited for anything faster, slower, or more fluid. When they can tween, they run at full frames, but when they actually have to redraw a frame, they drop to animating on twos. There's nothing wrong with animating on twos IF YOU STICK TO IT, but switching framerates mid-scene is horribly jarring. Also, they don't use any animator's tricks, so things like sprinting appear very disjointed and jumpy instead of appearing properly fluid.
If I had to describe their animation style, it would be a graphical quality slightly below that of Teen Titans with the animation quality of South Park. So, not very impressed.
Also not impressed by the character design. All the characters are painfully bog-standard except the main character, who is painfully bog-standard and ugly. I'm impressed by the shoe design, and by the way that the level designers played around with color and luminescence.
Graphically, the game is glitchy even on the 360, with numerous dropped polies and thin black origin lines flickering around. It also features The Return of the Long Ass Elevator Rides Two: Electric Boogaloo.
The story has only one upside: they didn't try to write a romance plot in. Unfortunately, everything they DID write in was painfully stereotypical. The only surprises in this game are in the level design - you won't find any in the plot. The "big twists" were evidently shocking to my avatar, but they only served to make me think Faith is a bit of a retard.
No, I take that back. There were surprises in the plot: when I overestimated them, they consistently surprised me by falling short.
Only bloody-mindedness kept me from skipping the cut scenes, which are badly written and animated in a style I don't much like. At least the audio is solid, with decent voice actors, decent sound effects, and very suitable and listenable-toable music.
The setting is a painfully bland police state with painfully bland corruption running its painfully bland course. At least it doesn't look so standard, thanks to the graphics used in the levels. It's a very CLEAN painfully bland city, you see, which actually adds to the experience.
"But that's all besides the point! It's all about the gameplay! How's this first-person free-running game PLAY?"
Weeeeelllllll... let's leave the bulk of that for the design section. But lets briefly talk about level design and pacing.
The game features a lot of classic navigation puzzlers a'la Prince of Persia, but the pacing is awkward unless you've memorized the levels. The fighting is a shame, included just because nobody can imagine releasing a noncombat game. It's terrible, whether you're kung-fu fighting with ninja (AKA "strafe, slide-kick, press Y") or fighting cops (AKA "Press X, press Y, hold the trigger"). It's not terrible in that it's EASY - you die like a dog - it's terrible in that it's NOT FUN.
The game is laser-focused on its linear path. There is no side exploration, no bonuses, no nothing. The closest you can get to expressing yourself as a player is to find little bags which serve ABSOLUTELY NO PURPOSE. There are no interesting secret zones, very little secret information (a few screens with a bit of text hidden in a corner, a few voice mail messages), very little of interest. There are occasionally multiple paths to your goal, but one is obviously better than the other and neither is particularly interesting.
***
Let's talk about the design details.
Moving a platformer into first-person view is a dangerous move, but one that's been brewing for a while. Games have become more and more free-running-esque as the years go by and our hardware improves. Prince of Persia has become a nostalgic look into the days when swinging from flagpoles was new and amazing. These days, even the (surprisingly good) TMNT game features more advanced motion than PoP, and games like Assassin's Creed and Crackdown make PoP look like a tinkertoy.
All of these games are third-person for a reason. As you know, Bob, platformer games are mostly about where you are in relation to other things. Like, say, the platforms.
If you can see where you are in relation to other things (IE, you can see your feet), you can know when and how to jump, land, and so forth. This is, as you might have guessed, an important part of your balanced daily not-falling-to-your-deathfast.
So moving to a first-person view offers some serious challenges. You have to keep in mind that your players don't have as clear a view as they normally do. It's very hard to chain motions together because first-person view means they'll only be looking at whatever they are about to hit instead of being able to see everything around them.
Mirror's Edge tried to solve this problem in two ways. First, it painted things red. Red means "jump here", and if you see something red, you'll remember where it is even if you can't see it precisely at the moment. In the game it is used primarily to tell you where it is safe to make blind jumps, but it is occasionally (and in my mind, more importantly) useful in highlighting a path through puzzling terrain. In either way it works to offset the limited view of the player, although in the former application (jumping off buildings) it offsets a limited view that even 3rd-person players have. Crackdown had to zoom pretty far out and up to give you a decent view of where you were jumping to in such situations, and it still wasn't perfect.
The second way Mirror's Edge tries to solve the problem is through level design. Most of the levels consist of climbing up sheer, blind faces (or staircases) for a while, and then running and jumping in a generally downward direction. This is helpful because if you're looking down at where you're about to go, you can get a pretty good mental map of the place even if your viewpoint will be too limited to see much when you're actually in it. This considerably offsets the blindness, especially since you can usually see the red marker showing you where you ought to go next.
However, these methods (and other aspects of their level design) take most of the spontaneity out of navigating the levels. It's all made very linear, mostly a matter of pressing the left bumper at the right times, occasionally while fiddling with the control sticks. When you are "free" to move around (say, on a rooftop), your freedom is pointless as the only things worth doing are moving to whatever is red or climbing to the highest point so you can see where you're going.
My problem isn't that such movement is boring: it isn't. Or, rather, it doesn't have to be. My problem is that they didn't really embrace it at all.
In most modern movement games (Assassin's Creed, for example) a big part of the gameplay is figuring out how to work your way to some location. Sometimes, it's painfully linear, but there's usually a rewarding rhythm and sense of progress - for example, finding a new plot element, getting an upgrade, climbing to someplace high, or finding something weird. Unfortunately, Mirror's Edge tries to do this, but there is never any sense of progress because they wanted to focus on relentless forward movement rather than the slow figuring-and-working-forward pace of normal movement games. They wanted to be more like Sonic, so they don't ever give you any roses to stop and smell.
In other movement games, flow is the point. TMNT and Crackdown are good examples. When these are linear, they are linear in a really obvious way to allow you to know well in advance what buttons you should press when, giving your avatar a continuous stream of uninterrupted forward movement. When they aren't linear, they allow you to freely explore an INTERESTING terrain, rather than a tiny rooftop. Mirror's Edge tried to do this with red things but they didn't take it very far: they wanted to be more like Assassin's Creed.
This has the added problem that Mirror's Edge is entirely first person, which means you are mostly good at seeing places you AREN'T. Fundamentally, I think it's a rotten choice for a movement-based game, because movement-based games are about changing where you are, not changing where you aren't.
Another big issue is that the players are limited by what they can recognize in addition to what they can see. Games like Crackdown make it easy because your method of movement is actually pretty simple and limited, just amped up to silliness. But in a proper free running game, your movement capabilities are going to be a lot more nuanced: you aren't just jumping the fence, you're scrambling over it, or maybe it's low enough to Kong. Similarly, maybe you need to wall jump up to the lattice across the way.
This would be almost impossible to properly see using third-person view, and it IS impossible to see using first-person view. This is why real parkour and free runner folks carefully familiarize themselves with wherever they are before they do anything dangerous: they need to know the "grooves" in the local space, places where their capabilities will allow them to fluidly move through. It's not something that can really be done on the fly.
Most games try to get around this with level design. Oh, look, it's a wall of exactly that height, so I know I can scramble up it, every time. And I know there will never be a wall of ALMOST that height, or a wall of that height I can't scramble up for some reason... and I know that if I vault that wall, I will land safely on the other side, no matter what the terrain.
But this doesn't help chains of movements. You know you can vault the wall, but you don't realize that you need to spring off the wall to the chandelier and then swing across through the window. The only way you can know that is if you've seen all the parts of the chain and have them mapped out in your head. That's much easier to do from third person.
Well, there are a few other options, I think. One is touched on in Mirror's Edge: important elements can stand out (in this case, be colored red). If used more excessively, they can form an unbroken chain of where you SHOULD be going, allowing you to maintain flow. I would actually suggest something a bit less world-centric, such as lines of flowing, floating pips.
This limits the puzzle-ability of your game, though. If there's always an obvious path to get where you want to go, you're not going to have to think about it much. Instead, you'll be more like Sonic or TMNT or Crackdown: navigating is a lot of fun, but many of the challenges come from exploration or combat rather than navigation.
Another option is to remove the realtime element from the game. If you "draw" your path in space rather than navigating it personally, it will allow you to analyze exactly what the situation is in a more relaxed way, allowing your avatar's progress to be fluid and sequenced even if YOUR progress involves tweaking paths for a minute.
Anyhow, either or both of these options would get rid of one of the stupidest parts of Mirror's Edge: DYING. Whoops, I died. Respawn. Whoops, I died. Respawn. Often five, six times in a row. Unlike TMNT, the respawn is a significant irritation which often takes you back forty or fifty seconds (this doesn't sound irritating until you realize that you have to repeat that minute many times if you're trying for a difficult jump). Also unlike TMNT, it MAKES NO SENSE. There is absolutely no reason given for your amazing respawn talent. It's not part of the game world in any way. It's just there to let the designers create levels that you have to play through several times to be able to beat.
Nothing breaks immersion like inexplicable and unrewarding failure mechanics. :P
All that aside, I think that there IS some potential here. First-person mechanics are inherently more immersive, and you could make a very exciting game if only you could figure out how the player would navigate it.
Sunday, September 21, 2008
Grooved Space
I posted a Jedi Thought Experiment last time, and it got some good comments. TickledBlue points out that if we use the Force to mark opportunities ("trust in the Force") then we get something that, on the surface, seems like a quick time event. In the words of Brog: "If you're being chased near a cliff edge and suddenly the force flashes a safe colour over the cliff edge, you should know instantly that this means it is safe to jump off it RIGHT NOW and do it without hesitation, because in a seconds time it might no longer be safe."
While that does sound like a quick time event ("PRESS A NOW OR YOU TAKE DAMAGE!!!"), there is a huge difference in design philosophy, and this runs as deep as the difference between Dark Side and Light Side, yeah?
The difference is player agency.
The above example isn't the best example, but I'll use it because it's been established.
If this was a quick time event, when you don't PRESS A RIGHT GODDAMN NOW NO U PRESSED SWORDY BUTTON BECAUSE U WERE IN THE MIDDLE OF A KILLER COMBO U LOSE!!!!11!!! then you take damage and are required to do everything you just did again.
If you miss this "Force Opportunity", then... you miss the opportunity. The game keeps playing.
This can lead to incredibly irritating game design. The obvious example is if you need to jump off a railway and land on a flying car (I mean, duh, OBVIOUSLY). If you miss it... are you stuck on the railway? It can also be abused for single-time bonuses - oh, you didn't jump on that particular car, so you didn't get the easter egg/bonus points.
But just because it can be used for bad design doesn't mean it has to be. The philosophy of the Force is pretty similar to the idea of a benevolent and vaguely all-powerful god: trust it, it will provide, etc, etc. If your design is full of one-shot "tests" and tricky, unclear Force patterns, then you are a shitty god. The Jedi order wouldn't have formed, because the two sides of the Force would be Dark and Irritating.
In our example, what the Force does is "groove" space. Let me see if I can explain:
In Sly Cooper, space was grooved. The game could tell if you were trying to jump to a specific spot - say, the top of a spire - and it would helpfully land you there. But, at the same time, it didn't force you to jump to the spire. It's not "PRESS A TO JUMP NOWWWWW OR U FALL AN DIE!!!!!11!!!!!111!!!!1111!!", it's "Hey, you're jumping to the spire? Don't sweat the small stuff, I'll get you there." "Grooved" space, completely without any extraneous capitalization or exclamation points, because as it turns out, Sly is quite nimble.
Our example is similar: as a Jedi, if you want to jump off a spire and land on a passing car, the Force will show you the "grooves" that will let you. If you press the right direction and jump at vaguely the right time, it'll make sure you get there. The Jedi has some slight automation to give us that fluid, Force-following sensation.
But it still leaves all the control in the hands of the player...
See?
This is actually a topic I want to talk a lot more about: how "chunky" your game controls are is a very interesting topic. Games run from things like that Simon Says toy, which is essentially a quick time event with batteries, to something like Quake, where you are free to move and aim very precisely in any number of increments.
But... let's not talk about it in this essay. I think grooved space is enough for now.
While that does sound like a quick time event ("PRESS A NOW OR YOU TAKE DAMAGE!!!"), there is a huge difference in design philosophy, and this runs as deep as the difference between Dark Side and Light Side, yeah?
The difference is player agency.
The above example isn't the best example, but I'll use it because it's been established.
If this was a quick time event, when you don't PRESS A RIGHT GODDAMN NOW NO U PRESSED SWORDY BUTTON BECAUSE U WERE IN THE MIDDLE OF A KILLER COMBO U LOSE!!!!11!!! then you take damage and are required to do everything you just did again.
If you miss this "Force Opportunity", then... you miss the opportunity. The game keeps playing.
This can lead to incredibly irritating game design. The obvious example is if you need to jump off a railway and land on a flying car (I mean, duh, OBVIOUSLY). If you miss it... are you stuck on the railway? It can also be abused for single-time bonuses - oh, you didn't jump on that particular car, so you didn't get the easter egg/bonus points.
But just because it can be used for bad design doesn't mean it has to be. The philosophy of the Force is pretty similar to the idea of a benevolent and vaguely all-powerful god: trust it, it will provide, etc, etc. If your design is full of one-shot "tests" and tricky, unclear Force patterns, then you are a shitty god. The Jedi order wouldn't have formed, because the two sides of the Force would be Dark and Irritating.
In our example, what the Force does is "groove" space. Let me see if I can explain:
In Sly Cooper, space was grooved. The game could tell if you were trying to jump to a specific spot - say, the top of a spire - and it would helpfully land you there. But, at the same time, it didn't force you to jump to the spire. It's not "PRESS A TO JUMP NOWWWWW OR U FALL AN DIE!!!!!11!!!!!111!!!!1111!!", it's "Hey, you're jumping to the spire? Don't sweat the small stuff, I'll get you there." "Grooved" space, completely without any extraneous capitalization or exclamation points, because as it turns out, Sly is quite nimble.
Our example is similar: as a Jedi, if you want to jump off a spire and land on a passing car, the Force will show you the "grooves" that will let you. If you press the right direction and jump at vaguely the right time, it'll make sure you get there. The Jedi has some slight automation to give us that fluid, Force-following sensation.
But it still leaves all the control in the hands of the player...
See?
This is actually a topic I want to talk a lot more about: how "chunky" your game controls are is a very interesting topic. Games run from things like that Simon Says toy, which is essentially a quick time event with batteries, to something like Quake, where you are free to move and aim very precisely in any number of increments.
But... let's not talk about it in this essay. I think grooved space is enough for now.
Monday, July 07, 2008
Landscapes and Level Designs: The Boring Part
Well, I went and wrote the little blurb, but then Matthew Rundle went and requested all the boring stuff. Here are some of the nitpicky little details about line of sight and terrain.
One thing you have to keep in mind from the start is that there is no fundamental difference between designing motion and level design (in considering vision). WEIRD. Lemme sup up.
Most games focus on controlling player vision by putting up walls and doors and other large, opaque barriers. The player is then allowed to move as he sees fit. Well, not entirely: he's channeled into various halls and cannot proceed unless he opens specific doors and so forth. But he's allowed to progress at his own pace.
Some games (especially old "rails shooters") focus on controlling player vision by the simple expedient of controlling every aspect of player movement. Sometimes they mix in some opaque stuff, but it's just to break things up a bit: the same basic level of obstruction could be done by simply having the bad guys peek in from the side of the screen.
The two are mathematically equivalent.
Even in situations where the player is given complete freedom of movement (a minimum of funneling and forced door-opening), they are still equivalent. Because the player line-of-sight calculations only care about how long a player has to meaningfully react to a newly spotted challenge.
It doesn't matter whether you spin their camera to reveal a bunch of guys standing in a field or whether they turn the corner of a twisty maze manually and see a bunch of dudes hiding behind rocks. In both cases, the challenge is the same.
... well, according to the simple formula:
challenge = player_response_time / required_reaction_time
However, both player_response_time and required_reaction_time are complicated beasts.
In a game where you control your own progress, how long a player takes to notice an enemy is going to usually be fairly low, because they know what areas they are revealing and therefore can focus on them. A lot of free-moving games like this shake things up by having "forced forward" challenges: you fall through the floor, the door seals behind you, wolves jump through the walls around you... anything to keep you from always being in control.
HOWEVER, in free-moving games, actually reacting to what you've noticed generally takes longer. You can aim and shoot a lot faster with a gun controller than with two thumb pads and a trigger.
Do they come out equivalent, then? Rail-shooters having longer reaction times but shorter response times?
Hell no! There's no equivalence! It all depends on everything!
Many free-movement games have auto-locking, for example. But even more importantly, a "response" isn't necessarily "shoot the commie bastards!" Although that's the only response in a rails shooter, in a free-movement shooter maneuvering is pretty important. If you see a bunch of guys as you turn the corner, you can UN-turn the corner (unless you're "forced forward").
That response is a whole lot faster than trying to aim, to the point where it's barely above your reaction speed itself! In fact, in many cases, I've ducked back around corners without even seeing an enemy - you can say that the response in those cases is actually faster than my reaction speed.
Of course, once spotted and run from, the rules change... let's not get into that.
At this point, we're only considering the simplest half of the formula, but there's a few more things that need to be mentioned:
Games that aren't shooters - such as RPGs or roguelikes - tend to be "on your own time" - usually turn-based or, at least, not bothering to have the enemy engage in real time. In these situations, the first half of the formula is broken up funny.
Usually, player_response_time = reaction_time + response_activation_time.
However, we've already seen that, in a free-motion game, you can dramatically "squish" player_reaction_time and take panicky, effective responses before you would have reacted at all.
"On your own time" games simply take that a step further and squish it to zero, leaving you with only the response activation time... which is usually measured in game units (turns) rather than seconds. This is often further simplified to be ONE. One turn.
Iteration will make a mess of this sort of thing, so we'll ignore it for now.
Required_reaction_time is simply how long the player has to react before something goes south. Before he gets shot. Before the timer hits zero and he explodes.
Already we can start to see our nice, simple formula falling apart. Required reaction times are not cement. If you don't achieve them, you usually don't die: you simply lose some resources. This is true in virtually every kind of game.
Similarly, the required_reaction_time can't simply be listed by enemy in a free-movement game. What about the enemy you backpedal to delay? There, you can backpedal until you run out of level. When you run out of level isn't determined by the enemy! The enemies' options may also be constrained, such as an archer stuck on an island, or a horde of fat blobs trying to squirm across a narrow bridge.
Well, that's pretty detailed... and I'm not really trying to replace common designer sense with formula. So let's just use common sense: if it matters, it matters, screw the formula.
However, formula are handy for focusing our minds, so lets return to ours.
What we have is actually an iterative situation. We have two cyclic elements, not a simple formula.
murglflorp = (Player Response Cycle) ~ (Enemy Response Cycle)
With the first iteration in both player and enemy cycles involving how long it takes you to notice and orient on the target.
The formula is meaningless, because how do you compare cycles? Well... you can always frame it in DPS:
player_DPS = Player_Average_Damage / Player_Cycle_Speed
Except DPS is notoriously bad. "Front-weighted" DPS, such as a barbarian hitting someone with an ax and then having a four second recovery, is much more effective than a wizard who does the same DPS over the course of four seconds - because the enemy won't be stabbing the barbarian as his HP dwindles.
Also, of course, unless you're in an "on your own time" game, usually you'll have to aim and hit, which changes your DPS... and it's important, because some enemies are easy to hit (large, slow blobs) and some are hard to hit (fast little insects).
player_DPS_simple = Player_Hit_Chances * ( (Player_Average_Instant_Damage + Player_Average_Slow_Damage * constant) / Player_Cycle_Speed)
Obviously, the player's average slow damage only counts over a single cycle: if the DPS from, say, poison triggers once per player cycle, it counts as instant damage... BUT it deals free damage next cycle! (We'll call it "bleed".) So...
player_DPS_complex = player_DPS_simple + cycle_number * (Player_Average_Bleed_Damage * Player_Bleed_Likelyhood)
Not all bleed lasts forever, so...
if cycle_number > max_bleed_length, cycle_number = max_bleed_length.
All of this stuff depends heavily enemy resistances and so forth, but we'll skim over that.
The enemy's half is exactly the same equation, just replace "player" with "enemy".
So, we end up with
player_DPS_complex vs enemy_DPS_complex
but we need to add a bit more...
average_time_to_kill = enemy_HP / player_DPS_complex + player_reaction_speed
attrition = enemy_DPS_complex * (average_time_to_kill - enemy_reaction_speed)
And that's it. We can stack the enemies up, in which case the player reaction speed is judged as excruciatingly low because he has to shoot each enemy unless he switches to a grenade or something.
Except... what do these formula leave out?
LINE OF SIGHT AND TERRAIN, yeah. Remember those?
We've calculated out all of this stuff, but we didn't bother to take into account the max range of engagement for each side, the level of cover available, and so forth.
To some extent, the reaction speeds rely on this sort of thing: a player surprised from behind will have a worse reaction speed, an enemy who doesn't see you will have a terrible reaction speed...
But it's still very loose, very improper. It's important to consider the level as its own living, breathing thing.
So, let's presume we assign attrition values (and ranges) to each enemy (with each of the player's weapons and error bars for good/bad players). From there, we can plug THOSE values into something level-based.
Levels have the unfortunate tendency to be two or even three dimensional, with a very wishy-washy "time" dimension tacked on. (Remember, we're not talking about a specific play-through, which has concrete time, but a potential play-through or the aggregate of all our player's play-throughs.)
If you picture a map from above (we're not actually doing this, but pretend), you'll see all the various rooms and hallways and hills and trees and so forth. Now, if you were going to try to build a heat map of danger, how would you do it?
Aside from running testers or bots through it and recording it all, there's really no useful way to do so. The real problem is that the progression of the player is so important: enemies do not exist for all time, they only exist from the moment they are created until the moment they are killed, at which point the player frequently uses whatever terrain advantage they held against whoever's next.
This means that any analysis you use has to take into account how the player proceeds through the level!
... Ahhhh... but... Instead of treating the level as a contiguous, three-and-a-half dimensional beastie, let's break it down into a series of challenges. After all, that's how they face it.
Thinking of it this way also negates any need to try to take actual timing into account. If the player dallies, or runs off and explores a side area, your planning is undamaged. They will EVENTUALLY reach this challenge, at which point it will begin.
Of course, the challenge may react differently to characters with various resources, and if they go off and explore a side area, they may very well have different resources... but we'll get to that.
After any given challenge, the important thing to know is how many resources were used - ammo, health, etc. To do this, we can't calculate quite as simply as we would like, because things like cover, numbers, range, and so forth will change our calculations dramatically.
So we'll use what is basically Feynman's approach: we'll add up the probabilities, starting with the simplest path through the challenge and moving to the more complex (less likely) paths.
To do this, you need to make sure you're dealing with single, tiny challenges. While in your mind you might be lumping a series of conflicts through a twisty passage as a single challenge, to add it up you should really split it up and add the results (and the error bars) together. Otherwise it gets too complex too quickly.
As an example, the player emerges into a room. On the far side are three soldiers who are, for mysterious reasons, idly smoking near an explosive barrel.
Adding up the paths we take is pretty simple. Most likely path: player shoots the crates, soldiers die. Expenditure: 3 bullets (machine gun or pistol) or 1 bullet (anything else).
Next less likely path is the player not having quite that much speed, and so a few of the soldiers get shots off at him before the barrel goes up. Expenditure: as above, plus 0-15% health, as calculated from the enemy's advanced DPS formula.
Next likely path is one of the soldiers managing to get away from the barrels and engaging in a typical attrition combat - use the attrition values calculated above. Next likely, two soldiers. This means the first soldier is standard attrition level, but the second soldier is standard attrition level PLUS enemy advanced DPS * average time to kill.
All three soldiers escaping death by barrel means the same thing, with another standard attrition level plus enemy advanced DPS * 2 * average time to kill.
Let's assume that EADPS (enemy advanced DPS) is 5% per second. Let's assume average time to kill is 2 seconds. Therefore, average attrition is 10%. We'll also say that the barrel late explosion time is 1 second, giving each soldier 5% if you don't blow the barrel up immediately.
This means that in the end we have (in average, no error bars, not including ammo expenditures):
No damage (all soldiers die instantly)
15% damage (1 second delay)
25% damage (ditto plus one escaped soldier)
45% damage (ditto plus another escapee that gets 2 extra seconds)
75% damage (ditto plus another escapee that gets 4 extra seconds)
Adding them up isn't really necessary, but if you want to, make sure you weight it towards the first value - so our final score would be around 10-20%, depending on your weighting scheme. That last score is very unlikely, after all.
These soldiers are serious business, you can see: an enemy that takes two seconds to kill is a significant enemy. But we've used standard attrition values. If there's any significant cover, all the attrition values would be reduced to half or even lower, especially the "extra seconds", during which a soldier may be completely blocked from attack by good maneuvering.
To account for this, we could reduce non-engaged enemies ("extra seconds") to half or even a quarter effectiveness, which would end up reducing those high-attrition, unlikely results considerably.
Now, let's do the same basic thing, but no barrel. Instead, the player has a rocket launcher.
The first values are the same: kill all the soldiers instantly with a rocket launcher, or kill two but not the third. In addition, the low probabilities are the same: kill the soldiers one at a time.
But there are probabilities in the middle where soldiers escape, but are killed more than one at a time, much reducing their number of free seconds. Except, of course, that your rocket isn't going to work out the same because it runs with a different average time to kill (probably much faster than the machine gun). Chances are high that, unless you set up the initial situation to avoid insta-gibbing, having a rocket with no barrel will actually result in less attrition than having a barrel and machine gun.
Of course, rockets should be a significantly rarer resource than machine gun bullets... and if the player has a rocket launcher and a machine gun, which will he use? It's not instant-switch: he'll probably use whichever he has equipped...
This adding-up of probabilities doesn't have to be exact. It just has to be good enough - everything will be tweaked on QA anyway.
The idea is, however, that you can string these things together. More importantly, you can string their error bars together.
So, for example, if you had three of these exploding-barrel groups one after another (each unique enough to be more than snap and shoot), you would say:
30% attrition, error bars at 100% and 0%
20 bullets, error bars at 140 and 0
0 rockets, error bars at 15 and 0
(people could do worse than this, but they would be considered outliers...
By tracking the "edges", you can contain the experience to things which are numerically interesting. You see that they could have used up 140 bullets, so you make sure there are only 75 bullets available. They could use 15 rockets, so make sure they only have 8.
This means an expert will get by sticking to bullets and rockets, because he's not going to use very many. The average player will use up a fair number, but have enough left to feel safe. The weak player will be in the dregs.
You can add in negative feedback systems if you like, giving weak players more stuff, but generally I find that a player-chosen difficulty system works fine for that.
If you were doing a boss encounter or a more harrowing experience, you'd want to restrict them to near the labeled average, rather than halfway between the label and the maximum. So if this was meant to be harrowing, you would give out 25 bullets and 2 rockets.
(It's not a very good experience to make harrowing, though: the error bars are too large. For bosses and other harrowing experiences, you want to make the error bars as small as possible to allow you to more accurately predict the player's resources. Therefore, you need to avoid chaotic elements such as exploding barrels (unless they are the only thing that can kill the boss).)
You can add any number of challenges together, so long as you keep the error bars intact. Eventually, you're going to have to face the fact that your error bars are way too big. You need to fix that either by fiat (new level, lose your weapons, etc) or by handing out so many resources that everything is always pegged at max. (Not such a good idea.)
Still, once you have the overall challenge rating, you may like to see what the overall LEVEL's rating is. You can get this by repeating the process for challenges: add together the most likely progressions through the level, then the less likely ones, and so forth. Weight the exact same way you did before, although you may have to take into account certain things - like the player who picks up a rocket launcher vs the player who doesn't. That skews your stats, but it's not hard to handle: just recalculate the challenge using the rocket launcher.
Anyway, there are a lot of other things you should also take into account, such as pacing (ah, my article on pacing is gone with my hosting space...) and aesthetics and variation. These formula are really just interesting doo-dads, not some kind of actual solution.
...
Told you it was boring.
One thing you have to keep in mind from the start is that there is no fundamental difference between designing motion and level design (in considering vision). WEIRD. Lemme sup up.
Most games focus on controlling player vision by putting up walls and doors and other large, opaque barriers. The player is then allowed to move as he sees fit. Well, not entirely: he's channeled into various halls and cannot proceed unless he opens specific doors and so forth. But he's allowed to progress at his own pace.
Some games (especially old "rails shooters") focus on controlling player vision by the simple expedient of controlling every aspect of player movement. Sometimes they mix in some opaque stuff, but it's just to break things up a bit: the same basic level of obstruction could be done by simply having the bad guys peek in from the side of the screen.
The two are mathematically equivalent.
Even in situations where the player is given complete freedom of movement (a minimum of funneling and forced door-opening), they are still equivalent. Because the player line-of-sight calculations only care about how long a player has to meaningfully react to a newly spotted challenge.
It doesn't matter whether you spin their camera to reveal a bunch of guys standing in a field or whether they turn the corner of a twisty maze manually and see a bunch of dudes hiding behind rocks. In both cases, the challenge is the same.
... well, according to the simple formula:
challenge = player_response_time / required_reaction_time
However, both player_response_time and required_reaction_time are complicated beasts.
In a game where you control your own progress, how long a player takes to notice an enemy is going to usually be fairly low, because they know what areas they are revealing and therefore can focus on them. A lot of free-moving games like this shake things up by having "forced forward" challenges: you fall through the floor, the door seals behind you, wolves jump through the walls around you... anything to keep you from always being in control.
HOWEVER, in free-moving games, actually reacting to what you've noticed generally takes longer. You can aim and shoot a lot faster with a gun controller than with two thumb pads and a trigger.
Do they come out equivalent, then? Rail-shooters having longer reaction times but shorter response times?
Hell no! There's no equivalence! It all depends on everything!
Many free-movement games have auto-locking, for example. But even more importantly, a "response" isn't necessarily "shoot the commie bastards!" Although that's the only response in a rails shooter, in a free-movement shooter maneuvering is pretty important. If you see a bunch of guys as you turn the corner, you can UN-turn the corner (unless you're "forced forward").
That response is a whole lot faster than trying to aim, to the point where it's barely above your reaction speed itself! In fact, in many cases, I've ducked back around corners without even seeing an enemy - you can say that the response in those cases is actually faster than my reaction speed.
Of course, once spotted and run from, the rules change... let's not get into that.
At this point, we're only considering the simplest half of the formula, but there's a few more things that need to be mentioned:
Games that aren't shooters - such as RPGs or roguelikes - tend to be "on your own time" - usually turn-based or, at least, not bothering to have the enemy engage in real time. In these situations, the first half of the formula is broken up funny.
Usually, player_response_time = reaction_time + response_activation_time.
However, we've already seen that, in a free-motion game, you can dramatically "squish" player_reaction_time and take panicky, effective responses before you would have reacted at all.
"On your own time" games simply take that a step further and squish it to zero, leaving you with only the response activation time... which is usually measured in game units (turns) rather than seconds. This is often further simplified to be ONE. One turn.
Iteration will make a mess of this sort of thing, so we'll ignore it for now.
Required_reaction_time is simply how long the player has to react before something goes south. Before he gets shot. Before the timer hits zero and he explodes.
Already we can start to see our nice, simple formula falling apart. Required reaction times are not cement. If you don't achieve them, you usually don't die: you simply lose some resources. This is true in virtually every kind of game.
Similarly, the required_reaction_time can't simply be listed by enemy in a free-movement game. What about the enemy you backpedal to delay? There, you can backpedal until you run out of level. When you run out of level isn't determined by the enemy! The enemies' options may also be constrained, such as an archer stuck on an island, or a horde of fat blobs trying to squirm across a narrow bridge.
Well, that's pretty detailed... and I'm not really trying to replace common designer sense with formula. So let's just use common sense: if it matters, it matters, screw the formula.
However, formula are handy for focusing our minds, so lets return to ours.
What we have is actually an iterative situation. We have two cyclic elements, not a simple formula.
murglflorp = (Player Response Cycle) ~ (Enemy Response Cycle)
With the first iteration in both player and enemy cycles involving how long it takes you to notice and orient on the target.
The formula is meaningless, because how do you compare cycles? Well... you can always frame it in DPS:
player_DPS = Player_Average_Damage / Player_Cycle_Speed
Except DPS is notoriously bad. "Front-weighted" DPS, such as a barbarian hitting someone with an ax and then having a four second recovery, is much more effective than a wizard who does the same DPS over the course of four seconds - because the enemy won't be stabbing the barbarian as his HP dwindles.
Also, of course, unless you're in an "on your own time" game, usually you'll have to aim and hit, which changes your DPS... and it's important, because some enemies are easy to hit (large, slow blobs) and some are hard to hit (fast little insects).
player_DPS_simple = Player_Hit_Chances * ( (Player_Average_Instant_Damage + Player_Average_Slow_Damage * constant) / Player_Cycle_Speed)
Obviously, the player's average slow damage only counts over a single cycle: if the DPS from, say, poison triggers once per player cycle, it counts as instant damage... BUT it deals free damage next cycle! (We'll call it "bleed".) So...
player_DPS_complex = player_DPS_simple + cycle_number * (Player_Average_Bleed_Damage * Player_Bleed_Likelyhood)
Not all bleed lasts forever, so...
if cycle_number > max_bleed_length, cycle_number = max_bleed_length.
All of this stuff depends heavily enemy resistances and so forth, but we'll skim over that.
The enemy's half is exactly the same equation, just replace "player" with "enemy".
So, we end up with
player_DPS_complex vs enemy_DPS_complex
but we need to add a bit more...
average_time_to_kill = enemy_HP / player_DPS_complex + player_reaction_speed
attrition = enemy_DPS_complex * (average_time_to_kill - enemy_reaction_speed)
And that's it. We can stack the enemies up, in which case the player reaction speed is judged as excruciatingly low because he has to shoot each enemy unless he switches to a grenade or something.
Except... what do these formula leave out?
LINE OF SIGHT AND TERRAIN, yeah. Remember those?
We've calculated out all of this stuff, but we didn't bother to take into account the max range of engagement for each side, the level of cover available, and so forth.
To some extent, the reaction speeds rely on this sort of thing: a player surprised from behind will have a worse reaction speed, an enemy who doesn't see you will have a terrible reaction speed...
But it's still very loose, very improper. It's important to consider the level as its own living, breathing thing.
So, let's presume we assign attrition values (and ranges) to each enemy (with each of the player's weapons and error bars for good/bad players). From there, we can plug THOSE values into something level-based.
Levels have the unfortunate tendency to be two or even three dimensional, with a very wishy-washy "time" dimension tacked on. (Remember, we're not talking about a specific play-through, which has concrete time, but a potential play-through or the aggregate of all our player's play-throughs.)
If you picture a map from above (we're not actually doing this, but pretend), you'll see all the various rooms and hallways and hills and trees and so forth. Now, if you were going to try to build a heat map of danger, how would you do it?
Aside from running testers or bots through it and recording it all, there's really no useful way to do so. The real problem is that the progression of the player is so important: enemies do not exist for all time, they only exist from the moment they are created until the moment they are killed, at which point the player frequently uses whatever terrain advantage they held against whoever's next.
This means that any analysis you use has to take into account how the player proceeds through the level!
... Ahhhh... but... Instead of treating the level as a contiguous, three-and-a-half dimensional beastie, let's break it down into a series of challenges. After all, that's how they face it.
Thinking of it this way also negates any need to try to take actual timing into account. If the player dallies, or runs off and explores a side area, your planning is undamaged. They will EVENTUALLY reach this challenge, at which point it will begin.
Of course, the challenge may react differently to characters with various resources, and if they go off and explore a side area, they may very well have different resources... but we'll get to that.
After any given challenge, the important thing to know is how many resources were used - ammo, health, etc. To do this, we can't calculate quite as simply as we would like, because things like cover, numbers, range, and so forth will change our calculations dramatically.
So we'll use what is basically Feynman's approach: we'll add up the probabilities, starting with the simplest path through the challenge and moving to the more complex (less likely) paths.
To do this, you need to make sure you're dealing with single, tiny challenges. While in your mind you might be lumping a series of conflicts through a twisty passage as a single challenge, to add it up you should really split it up and add the results (and the error bars) together. Otherwise it gets too complex too quickly.
As an example, the player emerges into a room. On the far side are three soldiers who are, for mysterious reasons, idly smoking near an explosive barrel.
Adding up the paths we take is pretty simple. Most likely path: player shoots the crates, soldiers die. Expenditure: 3 bullets (machine gun or pistol) or 1 bullet (anything else).
Next less likely path is the player not having quite that much speed, and so a few of the soldiers get shots off at him before the barrel goes up. Expenditure: as above, plus 0-15% health, as calculated from the enemy's advanced DPS formula.
Next likely path is one of the soldiers managing to get away from the barrels and engaging in a typical attrition combat - use the attrition values calculated above. Next likely, two soldiers. This means the first soldier is standard attrition level, but the second soldier is standard attrition level PLUS enemy advanced DPS * average time to kill.
All three soldiers escaping death by barrel means the same thing, with another standard attrition level plus enemy advanced DPS * 2 * average time to kill.
Let's assume that EADPS (enemy advanced DPS) is 5% per second. Let's assume average time to kill is 2 seconds. Therefore, average attrition is 10%. We'll also say that the barrel late explosion time is 1 second, giving each soldier 5% if you don't blow the barrel up immediately.
This means that in the end we have (in average, no error bars, not including ammo expenditures):
No damage (all soldiers die instantly)
15% damage (1 second delay)
25% damage (ditto plus one escaped soldier)
45% damage (ditto plus another escapee that gets 2 extra seconds)
75% damage (ditto plus another escapee that gets 4 extra seconds)
Adding them up isn't really necessary, but if you want to, make sure you weight it towards the first value - so our final score would be around 10-20%, depending on your weighting scheme. That last score is very unlikely, after all.
These soldiers are serious business, you can see: an enemy that takes two seconds to kill is a significant enemy. But we've used standard attrition values. If there's any significant cover, all the attrition values would be reduced to half or even lower, especially the "extra seconds", during which a soldier may be completely blocked from attack by good maneuvering.
To account for this, we could reduce non-engaged enemies ("extra seconds") to half or even a quarter effectiveness, which would end up reducing those high-attrition, unlikely results considerably.
Now, let's do the same basic thing, but no barrel. Instead, the player has a rocket launcher.
The first values are the same: kill all the soldiers instantly with a rocket launcher, or kill two but not the third. In addition, the low probabilities are the same: kill the soldiers one at a time.
But there are probabilities in the middle where soldiers escape, but are killed more than one at a time, much reducing their number of free seconds. Except, of course, that your rocket isn't going to work out the same because it runs with a different average time to kill (probably much faster than the machine gun). Chances are high that, unless you set up the initial situation to avoid insta-gibbing, having a rocket with no barrel will actually result in less attrition than having a barrel and machine gun.
Of course, rockets should be a significantly rarer resource than machine gun bullets... and if the player has a rocket launcher and a machine gun, which will he use? It's not instant-switch: he'll probably use whichever he has equipped...
This adding-up of probabilities doesn't have to be exact. It just has to be good enough - everything will be tweaked on QA anyway.
The idea is, however, that you can string these things together. More importantly, you can string their error bars together.
So, for example, if you had three of these exploding-barrel groups one after another (each unique enough to be more than snap and shoot), you would say:
30% attrition, error bars at 100% and 0%
20 bullets, error bars at 140 and 0
0 rockets, error bars at 15 and 0
(people could do worse than this, but they would be considered outliers...
By tracking the "edges", you can contain the experience to things which are numerically interesting. You see that they could have used up 140 bullets, so you make sure there are only 75 bullets available. They could use 15 rockets, so make sure they only have 8.
This means an expert will get by sticking to bullets and rockets, because he's not going to use very many. The average player will use up a fair number, but have enough left to feel safe. The weak player will be in the dregs.
You can add in negative feedback systems if you like, giving weak players more stuff, but generally I find that a player-chosen difficulty system works fine for that.
If you were doing a boss encounter or a more harrowing experience, you'd want to restrict them to near the labeled average, rather than halfway between the label and the maximum. So if this was meant to be harrowing, you would give out 25 bullets and 2 rockets.
(It's not a very good experience to make harrowing, though: the error bars are too large. For bosses and other harrowing experiences, you want to make the error bars as small as possible to allow you to more accurately predict the player's resources. Therefore, you need to avoid chaotic elements such as exploding barrels (unless they are the only thing that can kill the boss).)
You can add any number of challenges together, so long as you keep the error bars intact. Eventually, you're going to have to face the fact that your error bars are way too big. You need to fix that either by fiat (new level, lose your weapons, etc) or by handing out so many resources that everything is always pegged at max. (Not such a good idea.)
Still, once you have the overall challenge rating, you may like to see what the overall LEVEL's rating is. You can get this by repeating the process for challenges: add together the most likely progressions through the level, then the less likely ones, and so forth. Weight the exact same way you did before, although you may have to take into account certain things - like the player who picks up a rocket launcher vs the player who doesn't. That skews your stats, but it's not hard to handle: just recalculate the challenge using the rocket launcher.
Anyway, there are a lot of other things you should also take into account, such as pacing (ah, my article on pacing is gone with my hosting space...) and aesthetics and variation. These formula are really just interesting doo-dads, not some kind of actual solution.
...
Told you it was boring.
Sunday, July 06, 2008
Landscapes and Level Designs
So, I was in Ireland for a bit, and one thing I noticed was how well its levels were designed.
There's a strong aesthetic to Ireland which doesn't actually come from the fact that it's green. It comes from the fact that it's got lots of different sized hillocks all over it, and is spotted with lakes and cliffs just for kicks.
As you're driving along - or even just walking along - there is a very strong, panoramic parallax. Much of the time, the stuff in front is large but not totally obscuring the view, so as it parallaxes in and out you gain or lose significant chunks of the scenery behind it.
More interesting to me than that was the way that the roads would hug a hill. Coming around a corner would reveal a whole new vista as the hill falls towards one side.
These are pretty basic ideas, and I'm certainly aware of these kinds of things when I design levels. But not, perhaps, as much as I should be.
Terrain and line-of-sight are very powerful factors in any game, whether you're playing a space marine or a jellyfish or an elf. Recently there's been a tendency to disregard these things - especially in RPGs or MMORPGs... which I think is because this kind of thing takes player skill to handle, and those kinds of games generally don't much like requiring their players to have any skill. But it's critical, it's immersive, it's good juju.
That's why most of the best levels have a mix of open areas, enclosed halls, twisty passages, lookouts, rubble... lots of things to change how you can see and how you can move around the level. Wise designers make the lee sides of walls, doors, and rubble dangerous - that's where smart enemies tend to hide and wait for you. Some games focus on controlling your movement (Sly Cooper) while others focus on controlling your vision (Gears of War).
...
I guess this is really just a reminder. I actually worked out a lot of formulas and suggestions for various kinds of games and players, but they seem pretty boring now that I'm looking at them.
So... I guess that's it.
There's a strong aesthetic to Ireland which doesn't actually come from the fact that it's green. It comes from the fact that it's got lots of different sized hillocks all over it, and is spotted with lakes and cliffs just for kicks.
As you're driving along - or even just walking along - there is a very strong, panoramic parallax. Much of the time, the stuff in front is large but not totally obscuring the view, so as it parallaxes in and out you gain or lose significant chunks of the scenery behind it.
More interesting to me than that was the way that the roads would hug a hill. Coming around a corner would reveal a whole new vista as the hill falls towards one side.
These are pretty basic ideas, and I'm certainly aware of these kinds of things when I design levels. But not, perhaps, as much as I should be.
Terrain and line-of-sight are very powerful factors in any game, whether you're playing a space marine or a jellyfish or an elf. Recently there's been a tendency to disregard these things - especially in RPGs or MMORPGs... which I think is because this kind of thing takes player skill to handle, and those kinds of games generally don't much like requiring their players to have any skill. But it's critical, it's immersive, it's good juju.
That's why most of the best levels have a mix of open areas, enclosed halls, twisty passages, lookouts, rubble... lots of things to change how you can see and how you can move around the level. Wise designers make the lee sides of walls, doors, and rubble dangerous - that's where smart enemies tend to hide and wait for you. Some games focus on controlling your movement (Sly Cooper) while others focus on controlling your vision (Gears of War).
...
I guess this is really just a reminder. I actually worked out a lot of formulas and suggestions for various kinds of games and players, but they seem pretty boring now that I'm looking at them.
So... I guess that's it.
Thursday, August 09, 2007
Generative History and Ecologies of Sentient Beings
These days, games are getting larger and larger. Some games have many square miles of terrain and city. Sometimes, this is generated by hand, sometimes, it is largely generated algorithmically.
The problem with these large settings is that they ultimately end up feeling very empty. If there are people in them, they say the same boring non-things that the people in other places say. Also, if generated algorithmically, there's nothing particularly entrancing about the topography of the area, either.
Creating vast amounts of content has become one of the major challenges in modern game design, and most teams try to restrict themselves to well-known kinds of content - graphics, sound, levels, quests. These are expensive, but tools exist to help you create them effectively.
I think that, before too long, we'll have tools for creating other kinds of content, and one of the kinds of content I want to see more of is generative history/ecologies of sentient beings.
Whenever you see ecologies implemented in a game, it means that deer eat grass and wolves eat deer and adventurers eat wolves. It's simply a method for providing content which makes sense and adapts slightly. The adaptation quickly makes wolves either extinct or ubiquitous, but at least it's adaptation.
There are two problems with this approach. First, ecologies are really long-term things, whereas adventures are really short-term things. No adventure should feature the main character exterminating every wolf in the forest. Unless this is a MMOG, that's just insane.
Second, animals aren't very interesting. The difference between encounter wolves in forest A and bears in forest B is pretty minimal, and there's really not much punch to simply changing the number of critters you encounter. Also, unless artificially forced, there's no real balance: a low-level character can easily be attacked by a thirty-strong pack of wolves if your simulation is a bit more realistic.
What's more exciting are sentient beings and the fruits of their labor. These are also a bit more balanced, because the larger a group of sentient beings is, the less likely they are to simply kill off travelers.
The funny thing is that, on the most basic level, sentient beings are just as easy to simulate as flora and fauna. Sentient beings pop up wherever there are resources, just like animals and plants. They are also resources to other sentient beings, just like animals and plants.
Easy example: all people require food.
There is a gold deposit. The gold deposit has value, but miners require food.
There is a verdant valley nearby. People settle there because there is food. They are farmers.
Now miners show up at the gold deposit, and begin to send gold to the farmers in exchange for food.
This is much the same as "Grass grows where it is wet, deer eat grass, wolves eat deer". Except you're building groups of people.
Obviously, you'll want stronger rules that allow for economies, tech, trading, nations, conquest, and so forth. But the AI can be pretty simplistic. You can also have just one race, or multiple sentient races, or whatever.
Walking around in this world might not be any more entertaining, though. It would be busier, but is the difference between a fishing village and a mining town of much interest to the player?
Well, you can certainly add some easy things: the resources a place has to offer is based on what they do and who they trade with. But that's kind of shallow and ultimately uninteresting.
It's better to introduce history.
See, what makes things interesting isn't what's there now, but what used to be there. People aren't simply married. They are married because... they fell in love on a cruise? Their parents arranged it to unite their houses? There was an accidental pregnancy? It's the history of their marriage that makes it more interesting.
Similarly, a city bears its history on every street. This building used to be an opera house, but it went out of business back when this district got hit by that typhoon... this corner is the one where all the coffee shops are, because everyone walks by on their way to and from work...
History generally follows a few basic rules. An aspect can be introduced, grow stronger, or grow weaker. As an aspect changes, it causes at least one other change.
For example, a fishing village is introduced to the gold miners. The gold miners want food, and give gold for food. Gold gets stronger. Because gold gets stronger, something happens.
Maybe food gets stronger: people get into the industry because there is money in it. Maybe food gets weaker: the river is overtaxed and there aren't enough fish. Maybe a new facet is involved: textiles or banking.
This can be random, because any result can be explained with only minimal effort and nobody is going to be looking very closely. But it provides a lot of hooks.
For example, when you talk to someone, they'll be involved in one of the facets, and they'll know the history of the facet. "Well, my family's always been in the textiles industry, but the market is falling off because the gold mines are dwindling... so I'm thinking about being a fisherman. Or maybe going on an adventure."
Cities would grow organically. The docks are all fisherman's docks, but then the city grows and they are replaced largely with commercial freighter docks. You can still see the history of the city, in the layout and remaining fishermen's boats... a layout that is completely different from a city that has commercial docks without having a major fishing industry first. How fast the industry grew will also change the way the docks expanded: more rapid growth means more aggressive, larger, often slipshod construction.
With the right algorithms, this could theoretically automatically build the entire level for you. But in practice, it would still be human built... however, the humans would be able to say, "Okay, this area is mainly a commercial docks area, but there are a lot of old fishermen still around, and the commercial docks are really just kind of tossed up..."
You can keep expanding, of course: international politics, technological development, factions...
It's also easy to do with individuals rather than cities, or scale in the reverse and do it with nations or even planets. The philosophy is the same: you evolve an ecology of sentient beings and have them remember how their ecology/economy has changed over time. NPC 30322 will have something interesting to say, and city 192 will have a unique and sensical situation. You can even fill in-world books with ACTUAL STUFF instead of empty pages.
I don't suggest this is the best way to do things. However, I think it might be a good way to "flesh out" your world. You might say that city 192 is being invaded by Martians and has no standing army. The ecological simulation fills out the rest.
The problem with these large settings is that they ultimately end up feeling very empty. If there are people in them, they say the same boring non-things that the people in other places say. Also, if generated algorithmically, there's nothing particularly entrancing about the topography of the area, either.
Creating vast amounts of content has become one of the major challenges in modern game design, and most teams try to restrict themselves to well-known kinds of content - graphics, sound, levels, quests. These are expensive, but tools exist to help you create them effectively.
I think that, before too long, we'll have tools for creating other kinds of content, and one of the kinds of content I want to see more of is generative history/ecologies of sentient beings.
Whenever you see ecologies implemented in a game, it means that deer eat grass and wolves eat deer and adventurers eat wolves. It's simply a method for providing content which makes sense and adapts slightly. The adaptation quickly makes wolves either extinct or ubiquitous, but at least it's adaptation.
There are two problems with this approach. First, ecologies are really long-term things, whereas adventures are really short-term things. No adventure should feature the main character exterminating every wolf in the forest. Unless this is a MMOG, that's just insane.
Second, animals aren't very interesting. The difference between encounter wolves in forest A and bears in forest B is pretty minimal, and there's really not much punch to simply changing the number of critters you encounter. Also, unless artificially forced, there's no real balance: a low-level character can easily be attacked by a thirty-strong pack of wolves if your simulation is a bit more realistic.
What's more exciting are sentient beings and the fruits of their labor. These are also a bit more balanced, because the larger a group of sentient beings is, the less likely they are to simply kill off travelers.
The funny thing is that, on the most basic level, sentient beings are just as easy to simulate as flora and fauna. Sentient beings pop up wherever there are resources, just like animals and plants. They are also resources to other sentient beings, just like animals and plants.
Easy example: all people require food.
There is a gold deposit. The gold deposit has value, but miners require food.
There is a verdant valley nearby. People settle there because there is food. They are farmers.
Now miners show up at the gold deposit, and begin to send gold to the farmers in exchange for food.
This is much the same as "Grass grows where it is wet, deer eat grass, wolves eat deer". Except you're building groups of people.
Obviously, you'll want stronger rules that allow for economies, tech, trading, nations, conquest, and so forth. But the AI can be pretty simplistic. You can also have just one race, or multiple sentient races, or whatever.
Walking around in this world might not be any more entertaining, though. It would be busier, but is the difference between a fishing village and a mining town of much interest to the player?
Well, you can certainly add some easy things: the resources a place has to offer is based on what they do and who they trade with. But that's kind of shallow and ultimately uninteresting.
It's better to introduce history.
See, what makes things interesting isn't what's there now, but what used to be there. People aren't simply married. They are married because... they fell in love on a cruise? Their parents arranged it to unite their houses? There was an accidental pregnancy? It's the history of their marriage that makes it more interesting.
Similarly, a city bears its history on every street. This building used to be an opera house, but it went out of business back when this district got hit by that typhoon... this corner is the one where all the coffee shops are, because everyone walks by on their way to and from work...
History generally follows a few basic rules. An aspect can be introduced, grow stronger, or grow weaker. As an aspect changes, it causes at least one other change.
For example, a fishing village is introduced to the gold miners. The gold miners want food, and give gold for food. Gold gets stronger. Because gold gets stronger, something happens.
Maybe food gets stronger: people get into the industry because there is money in it. Maybe food gets weaker: the river is overtaxed and there aren't enough fish. Maybe a new facet is involved: textiles or banking.
This can be random, because any result can be explained with only minimal effort and nobody is going to be looking very closely. But it provides a lot of hooks.
For example, when you talk to someone, they'll be involved in one of the facets, and they'll know the history of the facet. "Well, my family's always been in the textiles industry, but the market is falling off because the gold mines are dwindling... so I'm thinking about being a fisherman. Or maybe going on an adventure."
Cities would grow organically. The docks are all fisherman's docks, but then the city grows and they are replaced largely with commercial freighter docks. You can still see the history of the city, in the layout and remaining fishermen's boats... a layout that is completely different from a city that has commercial docks without having a major fishing industry first. How fast the industry grew will also change the way the docks expanded: more rapid growth means more aggressive, larger, often slipshod construction.
With the right algorithms, this could theoretically automatically build the entire level for you. But in practice, it would still be human built... however, the humans would be able to say, "Okay, this area is mainly a commercial docks area, but there are a lot of old fishermen still around, and the commercial docks are really just kind of tossed up..."
You can keep expanding, of course: international politics, technological development, factions...
It's also easy to do with individuals rather than cities, or scale in the reverse and do it with nations or even planets. The philosophy is the same: you evolve an ecology of sentient beings and have them remember how their ecology/economy has changed over time. NPC 30322 will have something interesting to say, and city 192 will have a unique and sensical situation. You can even fill in-world books with ACTUAL STUFF instead of empty pages.
I don't suggest this is the best way to do things. However, I think it might be a good way to "flesh out" your world. You might say that city 192 is being invaded by Martians and has no standing army. The ecological simulation fills out the rest.
Monday, June 04, 2007
Choke Points and Vantages
I find that, in level design, the interesting elements are choke points and vantages. For example, having a view of the bridge puts you in a strong defensive position, while having to cross the bridge puts you in a bit of a bind.
Of course, bridges aren't the only kind of choke point. An open plain can be a choke point, or a single doorway, or a teleporter, or a roof... a choke point is simply any area where players can't pass through without encountering other players in the area. The terrain of your chokepoints depends on how far the players can see/affect and how obstructed the view is. A forest is not likely a choke point, but cut down all the trees, suddenly passerby are easy to see.
Some choke points have no vantage - such as an important but twisty hallway. Some vantages can see multiple choke points - or no choke points at all. Some games create "fictional" vantages by allowing enemies to teleport into choke points. Some vantages are also choke points. Some choke points can be bypassed, others cannot. There are lots of options.
The pacing of a level is largely determined by how the players encounter choke points, vantages, and "neutral" territory. Since the players are interactive, when the enemy encounters a vantage or choke point, that changes the "value" of the vantage or choke point. You don't want to try to break through a choke point that the enemy has a vantage over. But standing around on a vantage while nobody uses the choke point is pretty useless...
Now: Automated level generators generally don't think in this way. They usually build things pretty much at random, although they may occasionally create a choke point by accident (or something that is supposed to be a choke point, but isn't). In a 1P game this kind of iffyness can be partially dealt with by enemy placement. For example, in Diablo II, the levels were generated with choke points and vantages, and even though the placement made absolutely no sense, they were definitely choke points and vantages because the game put enemies in them.
I don't really think that's the best way we can do it. I think we can generate maps that are much more meaningful by creating meaningful choke points and vantages. If we can "tell" what a choke point controls/limits, we can even create a little story around it - a janitor complaining, or someone who wants to be closer to the action, or a tall tale of a battle, or whatever we please.
Choke points are created because people want to get from point A to point B in a reasonably efficient manner. Choke points are usually the result of natural terrain - either conforming to it (a road) or surpassing it (a bridge over a river). Some choke points are caused as a result of unnatural terrain - such as a castle gate to get through the "natural" castle terrain of being surrounded by a wall. But they still follow the same rule: there is a wall, and the choke point is to surpass it.
You can even go much further with a little more data. The castle is surrounded by a wall. Now we have to decide how easy the owners want people to be able to surpass that wall. Some castles are fortresses with only one, heavily fortified entrance. Others are more marketplaces and palaces, often with dozens of entrances that are barely secured at all. Wealth and size of wall also play a part in how the entrances actually look: a poor keep might only be able to afford a portcullis, while the emperor's treasure fortress might have a fifty-foot-long "airlock" with multiple portculli and lots of places for boiling oil and archers.
This sort of calculation gets more interesting once you realize that things change over time. It isn't at all uncommon for some places to get less popular and others to get more popular, which changes the stress on the various choke points (and, therefore, vantage points). For example, a new city built on the sea might have a serviceable port - until there's suddenly a gold rush and fleets of ships start pouring in with get-rich-quickers. This not only taxes the choke point of the docks, but also the various roads and resources of the city, causing resources to bulge and rearrange in different ways, causing a big change in which people want to go where from where.
I support this kind of "iterative" level construction, whether for a city or an office building. Put down resources and (optionally) a 'natural terrain'. Take turns building barricades to protect the resources; facilities to exploit and transform them; and creating bypasses and roads to get to and from the resources (new and old). You can even make a little bit of history while you're doing this, if you feel up to it.
Hrm.
What does everyone think?
Of course, bridges aren't the only kind of choke point. An open plain can be a choke point, or a single doorway, or a teleporter, or a roof... a choke point is simply any area where players can't pass through without encountering other players in the area. The terrain of your chokepoints depends on how far the players can see/affect and how obstructed the view is. A forest is not likely a choke point, but cut down all the trees, suddenly passerby are easy to see.
Some choke points have no vantage - such as an important but twisty hallway. Some vantages can see multiple choke points - or no choke points at all. Some games create "fictional" vantages by allowing enemies to teleport into choke points. Some vantages are also choke points. Some choke points can be bypassed, others cannot. There are lots of options.
The pacing of a level is largely determined by how the players encounter choke points, vantages, and "neutral" territory. Since the players are interactive, when the enemy encounters a vantage or choke point, that changes the "value" of the vantage or choke point. You don't want to try to break through a choke point that the enemy has a vantage over. But standing around on a vantage while nobody uses the choke point is pretty useless...
Now: Automated level generators generally don't think in this way. They usually build things pretty much at random, although they may occasionally create a choke point by accident (or something that is supposed to be a choke point, but isn't). In a 1P game this kind of iffyness can be partially dealt with by enemy placement. For example, in Diablo II, the levels were generated with choke points and vantages, and even though the placement made absolutely no sense, they were definitely choke points and vantages because the game put enemies in them.
I don't really think that's the best way we can do it. I think we can generate maps that are much more meaningful by creating meaningful choke points and vantages. If we can "tell" what a choke point controls/limits, we can even create a little story around it - a janitor complaining, or someone who wants to be closer to the action, or a tall tale of a battle, or whatever we please.
Choke points are created because people want to get from point A to point B in a reasonably efficient manner. Choke points are usually the result of natural terrain - either conforming to it (a road) or surpassing it (a bridge over a river). Some choke points are caused as a result of unnatural terrain - such as a castle gate to get through the "natural" castle terrain of being surrounded by a wall. But they still follow the same rule: there is a wall, and the choke point is to surpass it.
You can even go much further with a little more data. The castle is surrounded by a wall. Now we have to decide how easy the owners want people to be able to surpass that wall. Some castles are fortresses with only one, heavily fortified entrance. Others are more marketplaces and palaces, often with dozens of entrances that are barely secured at all. Wealth and size of wall also play a part in how the entrances actually look: a poor keep might only be able to afford a portcullis, while the emperor's treasure fortress might have a fifty-foot-long "airlock" with multiple portculli and lots of places for boiling oil and archers.
This sort of calculation gets more interesting once you realize that things change over time. It isn't at all uncommon for some places to get less popular and others to get more popular, which changes the stress on the various choke points (and, therefore, vantage points). For example, a new city built on the sea might have a serviceable port - until there's suddenly a gold rush and fleets of ships start pouring in with get-rich-quickers. This not only taxes the choke point of the docks, but also the various roads and resources of the city, causing resources to bulge and rearrange in different ways, causing a big change in which people want to go where from where.
I support this kind of "iterative" level construction, whether for a city or an office building. Put down resources and (optionally) a 'natural terrain'. Take turns building barricades to protect the resources; facilities to exploit and transform them; and creating bypasses and roads to get to and from the resources (new and old). You can even make a little bit of history while you're doing this, if you feel up to it.
Hrm.
What does everyone think?
Monday, January 01, 2007
Hardly Hard
Jeff made a post about difficulty in games. He says that the game should always be just barely beatable. Then he says that the game's difficulty should continuously increase. I assume he assumes that the players will be getting more skilled, so the difficulty increase should be just fast enough to pace their improvement.
I disagree, however. First, it very much depends on the game what kind of difficulty I'm looking for. RPGs are typically very easy. This doesn't make me dislike them: there are a bunch of optional goals that scale in difficulty (buying the cool sword, beating the optional boss, collecting all the widgets).
RPGs wouldn't be better if they were "just barely beatable", at least, not usually. This is because different players have different levels of skill, and what is barely beatable to one person is likely to be a cakewalk to another. You can have adaptive difficulty or some kind of difficulty setting, sure, but that's usually considered an inelegant solution for an RPG. Instead, you have optional things that the players can do if they want a challenge or want to lower the challenge by leveling up. In essense, you give the player direct control over the difficulty they face.
RPGs are not alone in this. Nearly every game allows you to spend extra time to lower the difficulty of the game. Even games like Halo or Quake do this: take a few moments to grab a weapon or a shield recharge before running into the fray. Or take a lot more moments and run all the way out to the rocket launcher, because you suck too badly to do anything useful with any other weapon.
This ability for any player to beat the game in his or her own way is very important, says I. More important than making it "just barely beatable". How much challenge you want to offer within that spectrum is, of course, up to you.
However, above and beyond this idea of letting players take different routes to change the difficulty is the idea of changing the necessary skills a player has to use.
Because players grow more skilled at very different rates and typically start with massive skill differences, it's extremely hard to "scale up" the difficulty to match their skill improvement. I doubt I've improved one iota over the last four or five FPS games I've played.
Instead what games often do - and I think we should see more of this - is cycle through skill variations. This level, you have a pistol. That level, you have a rocket launcher. That level, you have a disk-thrower. Each requires you to change your tactical methodology - to use your skill in a different way. This happens in virtually every kind of modern game, and for good reason. It gives the players, good or bad, a sudden kick of something new and interesting.
It's not that any given level is going to be more hard or less hard, necessarily. There might be more enemies, or harder enemies, but you'll usually have cooler equipment to take them down with. The levels are designed to be the same difficulty, but using different techniques.
If you simply increase the difficulty, a lot of players are going to find themselves totally hosed. A good example of this is Psychonauts. I waltzed through that game. Until the last level, which had challenges roughly three times harder than the earlier levels. I barely cleared it, after many hours of dying. That wasn't too bad for me - I enjoyed most of it - but my roomate simply quit playing because the levels were too difficult to even beat.
Up until that point, Psychonauts had been simply giving you new powers and letting you use them in interesting ways. The levels were getting "harder", but you were getting meaner at the same rate. For the last level, they continued to get harder, but you didn't get any meaner. That alienates players.
So, that's my essay on why a game doesn't have to continuously increase the difficulty level.
I disagree, however. First, it very much depends on the game what kind of difficulty I'm looking for. RPGs are typically very easy. This doesn't make me dislike them: there are a bunch of optional goals that scale in difficulty (buying the cool sword, beating the optional boss, collecting all the widgets).
RPGs wouldn't be better if they were "just barely beatable", at least, not usually. This is because different players have different levels of skill, and what is barely beatable to one person is likely to be a cakewalk to another. You can have adaptive difficulty or some kind of difficulty setting, sure, but that's usually considered an inelegant solution for an RPG. Instead, you have optional things that the players can do if they want a challenge or want to lower the challenge by leveling up. In essense, you give the player direct control over the difficulty they face.
RPGs are not alone in this. Nearly every game allows you to spend extra time to lower the difficulty of the game. Even games like Halo or Quake do this: take a few moments to grab a weapon or a shield recharge before running into the fray. Or take a lot more moments and run all the way out to the rocket launcher, because you suck too badly to do anything useful with any other weapon.
This ability for any player to beat the game in his or her own way is very important, says I. More important than making it "just barely beatable". How much challenge you want to offer within that spectrum is, of course, up to you.
However, above and beyond this idea of letting players take different routes to change the difficulty is the idea of changing the necessary skills a player has to use.
Because players grow more skilled at very different rates and typically start with massive skill differences, it's extremely hard to "scale up" the difficulty to match their skill improvement. I doubt I've improved one iota over the last four or five FPS games I've played.
Instead what games often do - and I think we should see more of this - is cycle through skill variations. This level, you have a pistol. That level, you have a rocket launcher. That level, you have a disk-thrower. Each requires you to change your tactical methodology - to use your skill in a different way. This happens in virtually every kind of modern game, and for good reason. It gives the players, good or bad, a sudden kick of something new and interesting.
It's not that any given level is going to be more hard or less hard, necessarily. There might be more enemies, or harder enemies, but you'll usually have cooler equipment to take them down with. The levels are designed to be the same difficulty, but using different techniques.
If you simply increase the difficulty, a lot of players are going to find themselves totally hosed. A good example of this is Psychonauts. I waltzed through that game. Until the last level, which had challenges roughly three times harder than the earlier levels. I barely cleared it, after many hours of dying. That wasn't too bad for me - I enjoyed most of it - but my roomate simply quit playing because the levels were too difficult to even beat.
Up until that point, Psychonauts had been simply giving you new powers and letting you use them in interesting ways. The levels were getting "harder", but you were getting meaner at the same rate. For the last level, they continued to get harder, but you didn't get any meaner. That alienates players.
So, that's my essay on why a game doesn't have to continuously increase the difficulty level.
Thursday, October 26, 2006
Designing Levels
There's a very interesting article on Gamasutra about multiplayer level design.
Of course, he starts with: "The rules that govern single player level design are becoming more and more well known."
Known by who? Actually, the rules governing single player level design are still in their loose primordial stages. Some of the basics are well-known, such as "you need big/long/open rooms for long-range conflicts" and "jumping puzzles in FPS games need to be extremely forgiving". But aside from the obvious stuff, there are a lot of conflicting "cross your fingers and hope" methodologies.
That doesn't keep the article from being insightful, though: there's a lot of good data. But I would like to talk briefly about designing cooperative levels instead of competitive levels.
There is a steady rise in the number of cooperative computer games, and there are hella lot of cooperative tabletops and LARPs. But I find that, with few exceptions, these games simply don't support the rich tactical play that they should.
I've written on this basic concept before, but kind of tangentally. One of the things you might remember me talking about is how to make combat in tabletop games extremely fast yet tactically very strong.
Aside from optimizing for speed using chits, cards, and anything other than a fistful of dice, one of the most critical things mentioned was maps. Very few things communicate tactical play as quickly, naturally, and in as much detail as a map.
But a map isn't a level.
We're talking about cooperative level design. But when the players get into a firefight, the map they play on is a tiny subset of the "map" of the area they are in. It punches up the tactical play, but it isn't a "level". It's an encounter.
The "level" is how they play through that chunk of session. In a tabletop, we frequently pass on level design, preferring to wing it with vague blockades and challenges such as "there's security goons in... whatever hall it is that you're in" and "the elevator is broken". It is pretty damn rare to, say, draw out a compound or building map. If we do, it's just a quick overview: "the lab is here, the barracks here..." Otherwise, it's too much effort.
In a LARP the situation is even worse: it's extremely rare for a LARP to have levels at all. LARPs usually exist with a few specific places and anybody can really visit any of them at any time. I did get to see a LARP which used a whole building as a kind of "Aliens" run, and it looked incredibly fun. But we normally don't see that, because it takes up too much space.
In a computer game, you definitely have a level. But the level is hardcoded, so it suffers from the exact opposite problem. You give the players their strategic data, but the level cannot stretch to suit the players.
Okay, so, let's think about what we want in a cooperative level.
The purpose of having a slightly more "rigid" level is to give the players a range of strategic options and challenges, instead of limiting them to a few generic challenges tossed out by a GM. A level can tell us that not only is the elevator stuck, but the situation all around us is X, Y, and Z.
We want a level which can support a range of players. Say, 2-8. The level needs to be able to "stretch" or "shrink" to facilitate the greater threats required for larger groups. In addition, some thought needs to be given towards splitting larger parties while leaving smaller parties more whole, and to the fact that secondary challenges with less players are likely to be extremely difficult. After all, with eight players you'll probably have someone who can do anything. But with three, you'll be missing huge chunks of secondary skills - the players simply won't be able to complete objectives that require skills they do not have.
(Obviously, that last bit isn't a problem if you're running a game with no secondary skills. But that sounds like kind of a dull game.)
Okay, the level polymorphs to suit the players. Right there, that says "no map". How in the world could you build a map?
But how can you build complex strategic situations without a map? Even if you could, how could you get the players to remember the situation?
So I thought: card game.
I build a lot of crappy little games, and recently I've been dabbling in "build the board as you proceed" games. It seems to me that this dynamic is perfectly suited towards building levels.
Lets say we start with a deck. The cards in the deck represent challenges and challenge modifiers of various kinds. Guards, computerized doors, dragons in 10' rooms, whatever. Each challenge has a skill which applies and a difficulty rating.
Lets say you build a character. For every point of a skill you buy, you make a card that is a challenge of that type and hand it to the GM. For example, if you buy combat skills, you pass the GM "mook" cards, at a difficulty level of twice the skill level you just bought. If you buy science skills, you pass the GM "scientific mystery" cards. And so on, for each point of each skill you buy.
Challenging a card is simple. Each round you fight a card, you reduce its difficulty by your combined skills of that type. And each round you don't kill it, everyone involved takes a point of exhaustion. If you run out of exhaustion, you die.
Every round, you do one of three things. You can choose to fight a challenge (you must have at least a 1 in the suitable skill), in which case you draw no cards. You can choose to move, in which case you draw and place a location card and draw and place a challenge card for it. Lastly, you can just bide your time or move on existing terrain, in which case you draw a challenge card. Most challenge cards are discarded if not drawn in regards to a location, but some aren't.
Every time the GM's turn comes around, he may adjust one challenge per two players, moving it one tile if it is mobile. He may not adjust challenges currently in conflict.
Different kinds of challenges can react in different ways. For example, mooks won't attack you if the alarm hasn't gone off. This offers multiple strategic options. And, of course, challenges you "leave behind" aren't exactly inactive, as the GM can move them and specific challenge cards can turn them monstrous.
Of course, this is just a rough idea. It obviously needs tweaking. For example, hidden challenges, the set-up phase, a third deck for corporal form of challenge, goals, escape routes...
But the basic idea is that you build the level as you proceed, and have a strategic set of options.
It's not suitable as is for anything other than a simple game, but it could be modified and used for a backbone for a more serious RPG.
Anyhow, just kind of muddling along. Feel free to comment if you had a thought.
I find posts ramble more the sicker I am. I'm not entirely sure I've ever had a week where I've slept more. :P
Of course, he starts with: "The rules that govern single player level design are becoming more and more well known."
Known by who? Actually, the rules governing single player level design are still in their loose primordial stages. Some of the basics are well-known, such as "you need big/long/open rooms for long-range conflicts" and "jumping puzzles in FPS games need to be extremely forgiving". But aside from the obvious stuff, there are a lot of conflicting "cross your fingers and hope" methodologies.
That doesn't keep the article from being insightful, though: there's a lot of good data. But I would like to talk briefly about designing cooperative levels instead of competitive levels.
There is a steady rise in the number of cooperative computer games, and there are hella lot of cooperative tabletops and LARPs. But I find that, with few exceptions, these games simply don't support the rich tactical play that they should.
I've written on this basic concept before, but kind of tangentally. One of the things you might remember me talking about is how to make combat in tabletop games extremely fast yet tactically very strong.
Aside from optimizing for speed using chits, cards, and anything other than a fistful of dice, one of the most critical things mentioned was maps. Very few things communicate tactical play as quickly, naturally, and in as much detail as a map.
But a map isn't a level.
We're talking about cooperative level design. But when the players get into a firefight, the map they play on is a tiny subset of the "map" of the area they are in. It punches up the tactical play, but it isn't a "level". It's an encounter.
The "level" is how they play through that chunk of session. In a tabletop, we frequently pass on level design, preferring to wing it with vague blockades and challenges such as "there's security goons in... whatever hall it is that you're in" and "the elevator is broken". It is pretty damn rare to, say, draw out a compound or building map. If we do, it's just a quick overview: "the lab is here, the barracks here..." Otherwise, it's too much effort.
In a LARP the situation is even worse: it's extremely rare for a LARP to have levels at all. LARPs usually exist with a few specific places and anybody can really visit any of them at any time. I did get to see a LARP which used a whole building as a kind of "Aliens" run, and it looked incredibly fun. But we normally don't see that, because it takes up too much space.
In a computer game, you definitely have a level. But the level is hardcoded, so it suffers from the exact opposite problem. You give the players their strategic data, but the level cannot stretch to suit the players.
Okay, so, let's think about what we want in a cooperative level.
The purpose of having a slightly more "rigid" level is to give the players a range of strategic options and challenges, instead of limiting them to a few generic challenges tossed out by a GM. A level can tell us that not only is the elevator stuck, but the situation all around us is X, Y, and Z.
We want a level which can support a range of players. Say, 2-8. The level needs to be able to "stretch" or "shrink" to facilitate the greater threats required for larger groups. In addition, some thought needs to be given towards splitting larger parties while leaving smaller parties more whole, and to the fact that secondary challenges with less players are likely to be extremely difficult. After all, with eight players you'll probably have someone who can do anything. But with three, you'll be missing huge chunks of secondary skills - the players simply won't be able to complete objectives that require skills they do not have.
(Obviously, that last bit isn't a problem if you're running a game with no secondary skills. But that sounds like kind of a dull game.)
Okay, the level polymorphs to suit the players. Right there, that says "no map". How in the world could you build a map?
But how can you build complex strategic situations without a map? Even if you could, how could you get the players to remember the situation?
So I thought: card game.
I build a lot of crappy little games, and recently I've been dabbling in "build the board as you proceed" games. It seems to me that this dynamic is perfectly suited towards building levels.
Lets say we start with a deck. The cards in the deck represent challenges and challenge modifiers of various kinds. Guards, computerized doors, dragons in 10' rooms, whatever. Each challenge has a skill which applies and a difficulty rating.
Lets say you build a character. For every point of a skill you buy, you make a card that is a challenge of that type and hand it to the GM. For example, if you buy combat skills, you pass the GM "mook" cards, at a difficulty level of twice the skill level you just bought. If you buy science skills, you pass the GM "scientific mystery" cards. And so on, for each point of each skill you buy.
Challenging a card is simple. Each round you fight a card, you reduce its difficulty by your combined skills of that type. And each round you don't kill it, everyone involved takes a point of exhaustion. If you run out of exhaustion, you die.
Every round, you do one of three things. You can choose to fight a challenge (you must have at least a 1 in the suitable skill), in which case you draw no cards. You can choose to move, in which case you draw and place a location card and draw and place a challenge card for it. Lastly, you can just bide your time or move on existing terrain, in which case you draw a challenge card. Most challenge cards are discarded if not drawn in regards to a location, but some aren't.
Every time the GM's turn comes around, he may adjust one challenge per two players, moving it one tile if it is mobile. He may not adjust challenges currently in conflict.
Different kinds of challenges can react in different ways. For example, mooks won't attack you if the alarm hasn't gone off. This offers multiple strategic options. And, of course, challenges you "leave behind" aren't exactly inactive, as the GM can move them and specific challenge cards can turn them monstrous.
Of course, this is just a rough idea. It obviously needs tweaking. For example, hidden challenges, the set-up phase, a third deck for corporal form of challenge, goals, escape routes...
But the basic idea is that you build the level as you proceed, and have a strategic set of options.
It's not suitable as is for anything other than a simple game, but it could be modified and used for a backbone for a more serious RPG.
Anyhow, just kind of muddling along. Feel free to comment if you had a thought.
I find posts ramble more the sicker I am. I'm not entirely sure I've ever had a week where I've slept more. :P
Subscribe to:
Posts (Atom)