Well, I wrote a big long post on enemy design, and the only thing anyone noticed was that I lumped skill-based challenges and luck-based challenges into a single challenge type. Caught some flak for that, so I figured I'd explain in more detail why I did that.
Not too long ago, I had them separated - luck and skill, that is. It's patently obvious that they are completely distinct, after all. One is luck, one is skill. You can get better at skill, but you can't get better at luck. So on so on so on.
The problem is that what is patently obvious isn't patently correct, and over time I shifted towards the opinion I hold now, which is that skill and luck are largely interchangeable from a game design standpoint. I don't expect to convince anyone, because it's a patently absurd statement. But I'll give it a shot.
First, to be a little more precise, I don't mean skill in general. I mean physical skill. Precision, reaction speed, spatial awareness. Skills such as tactical analysis, pattern recognition, and math are not really the same category. Those are "information challenges", or whatever term you prefer.
With that in mind, when I design, in my head things move. And they move in specific ways. So if I design a game, I see the fundamental mechanics and imagery boiling or spinning or changing colors as they bounce into each other and lock together. So the framework of a game has a distinct set of characteristics. By paying attention, I can usually produce what seems like more fun play, deeper immersion. Of course, being that I'm just toying around and prototyping, it could also just be wishful thinking.
Either way, the pieces "plunk" together in particular ways. The dynamics of a game, how it moves and spins and changes, is defined by how these pieces fit together. So I think in terms of what each piece of the design adds to the whole.
What I've come to realize is that a mechanic based on luck and a mechanic based on skill both serve the same purpose in this final framework. They both act as a "scattering" agent: they push the player in somewhat unexpected vectors, allowing them to explore the gameplay "terrain" with a quick and interesting feedback loop.
This sets them apart from information challenges, which are a far slower and more deliberate piece that usually forms the "backbone" of the game. The heuristics and thought you use in information dynamics can be very deep and interesting, but they move differently and don't contribute in the same way. The player will tend to "pool" in the valleys of an information challenge, but the velocity he gets from a gamble will often take him up and over various ridges, to new vistas.
They are certainly different from puzzle challenges, which are like little gems in the framework that unfold when you touch them.
The point is that, from a design standpoint, luck and skill serve the same driving role in a game's overall structure. They cause the player to interact with the game's framework in a very similar way. Just because one spins a bit differently from the other is no reason to call them different kinds of things: a penguin is still a bird, even though it can't fly.
They do serve slightly different purposes. Skill challenges can be stacked like a long chain of revolving gears, but doing that with strong luck mechanics will end up grinding itself to pieces. So, in order to use luck mechanics, you need to make sure there's padding between them and the next set of luck interactions, or you lose all agency. That's not as necessary with physical skill, which has a more orderly and agency-filled outgoing vector cloud.
But there's that much deviation within the other kinds of mechanics as well. Mental skill challenges include a variety of types that are just as distinct: memory challenges versus analysis challenges versus spatial challenges versus heuristic challenges... they also have somewhat distinct effects on the game. However, they are all fundamentally the same kind of thing.
That's where I'm coming from: the structure of the game, NOT the player's conscious experience.
Wednesday, April 21, 2010
Tuesday, April 20, 2010
Interesting Enemies 101
The last couple of posts have made me realized that some of the knowledge I take for granted as "basic" really isn't. So this post is about the basics: what makes a game challenging, what makes enemies fun.
When I design a game - typically a tabletop RPG or board game, but sometimes computer games - there are four kinds of challenges I generally consider.
The first kind of challenge is the puzzle. This is when the scenario set up by the developer has a specific path to resolution. For example, a crate-pushing room. A fetch quest is technically a puzzle, but it's a crappy one.
The second kind of challenge is the information challenge. An info challenge is different from a puzzle because there is no "boolean" solution: there are many paths you can take and the results will vary in different ways. There is typically very little randomness in this kind of challenge, aside from that required to define the scenario. A good example is Civilization city-building: where you put your cities and what you build in/around them is not affected by randomness, but it's not a single-solution puzzle, either.
The third kind of challenge is the gamble. Gambles are typically simpler than information challenges and make up for it by having either randomness or real-time skill be a major component. This is the kind of challenge most enemies present: in an FPS, the accuracy and speed of the play is challenged, while in an RPG weighted dice rolls are substituted for real-time player skill. Same kind of challenge, either way.
The last kind of challenge is a fulfillment challenge, where you allow the player to alter a scenario in ways not usually tied directly to game mechanics. For example, allowing someone to dress in whatever way they want, or to add knickknacks to their house.
Of these four, the gamble is obviously where your enemies fit in easiest. The "standard five" model (eggshell, skirmisher, heavy, sniper, spawner) are built to challenge the general kinds of real-time skill a player can have.
However, it's important not to get too caught up in such a simplistic view. The gamble challenge isn't entirely served by enemies. For example, in Guitar Hero, the gamble challenge is the stream of notes. You don't need enemies, because the stream of notes serves the exact same purpose.
In other situations, the reverse happens, and enemies can (and should) bleed over into other challenge types. For example, a turtle in Super Mario Bros leaves behind a shell when you kill it. The shell is a tool used to turn gamble challenges (hopping on the goombas requires a fair amount of agility) to an information challenge (hitting the lot of them with a turtle shell normally doesn't require such agility).
I think most of the memorable games actually have that kind of very muddy situation, where it's hard to say that something is A or B. The information and gambling challenges often cross over each other. For example, in Tetris, dropping the blocks is obviously real-time skill, but it requires advanced pattern recognition as well, which is an information challenge component. It straddles the two.
Similarly, the strength of a tabletop RPG is that a puzzle challenge often converts over to an information challenge or gamble as the players go outside the expected conditions. The flexibility offered by an actual GM is one of the reasons that tabletop RPGs are still so popular despite their poor mechanical design and irritating interface.
To go a little philosophical, when I'm designing a new game, I lock down some images in my head to use as a kind of vision to drive my design. I say "images" because English is not a very good language: they're not simply images, but processes, potentials, and emotions as well.
Once I have a clear idea of the kind of thing I want to make, I try to come up with a core set of mechanics that will support all four kinds of challenges, or at least the latter three (not puzzles). As I'm doing this, I try to come up with specific situations where I can see the mechanics crossing: interesting play always happens where the mechanics collide. That's the "mixing" of challenge types I'm talking about, although you can also have collisions between different mechanics for the same kind of challenge.
All of this has been a pretty roundabout way of reaching this final point, which is how to make interesting enemies.
The way to make interesting enemies, as you may have guessed by reading about that mixing and colliding, is to make enemies that collide with other game mechanics. This is usually not done in AAA titles because it can make large games hopelessly complex and impossible to balance. But for indie games and mods, it's a must if you want to have interesting play.
As an example, let's look at a side-scrolling action game such as the Contra series. At its core, the navigation on the screen is an information challenge, while the interaction with enemies is a gamble.
If you're designing enemies for this kind of game, you'll probably start by simply considering the Fundamental Five. You create enemies that are eggshells, skirmishers, snipers, heavies, and spawners. But that's pretty dull. The best enemies collide the multiple kinds of challenges, the multiple kinds of mechanics. They create "boundary challenges", where the challenge is unusual because it interacts with multiple kinds of mechanics.
To some extent, this is placement. By putting enemies at specific points in a level, you can make them interact with the level layout, turning navigation from an information challenge into a gamble. For example, a section where an enemy is firing across an upper platform, and the player is required to jump up between the bullets to get up there and hit him. Another common variant is the "roller" which rolls along the top of the platform, then along the bottom and back up to the top in an endless circle.
On the opposite side of things are enemies that are platform navigation, such as a boss that has platforms on him, or a boss that requires you to jump to specific areas to dodge or hit him. It's normally only bosses that are built like this because it takes so long to actually play out the battle.
There's no reason to stick with the oldschool. For example, we can create enemies that can be stood on as if they were platforms, so luring them to a specific point so you can jump off them is important (or using them to cross spikes). Other enemies might only pop up and attack if you're standing on specific areas in the level - wall turrets, for example.
Still more options: enemies that destroy or create terrain, enemies that change the gravity in a region, enemies that deflect shots in unusual ways such that they might be able to hit a sniper if used correctly (or yourself, if used incorrectly).
Also, you can implement new mechanics to give you another thing to butt up against. As an example, if our game features a lot of swinging (Bionic Commando, Batman, Spider-Man) we can introduce enemies that butt into that: enemies that leave grease spots you can't attach to, enemies that cut your cable, enemies that swing, enemies you can swing from, etc, etc. And, of course, don't forget the normal level navigation, which can butt up against the swinging system as well.
There's no problem thinking of these kinds of fun enemies. I can think of them all day. The two problems related to these enemies are both easily manageable, if you keep them in mind.
The first problem is programming. Unless you think ahead, you can find yourself having to write very complex special-case code for every enemy in your game. Make sure to think ahead.
The second problem is complexity. It's easy to swamp a player with too many different kinds of boundary challenges, too quickly. Generally, I try to keep my players at one boundary condition per level. I go up to two if I feel that the boundary condition is suitably transparent. For example, I might use both the enemies-that-swing and the enemies-you-can-swing-from in the same level, because both of those are pretty straightforward. But combining enemies-that-are-platforms with enemies-that-generate-and-destroy-platforms would be sadistic, and only suitable for The Hard Boss.
This is basically an unwavering rule. If you revisit a particular boundary challenge in a later level, you want to make sure to get rid of one of the boundary challenges you were using. The human brain can only comprehend so much simultaneously. Later, if your boundary conditions become a genre, you can start to assume the player is completely familiar with them... but until then, make sure not to swamp the player with too many boundary conditions at the same time, even if they theoretically "learned" them earlier in the game.
To me, these are the basics of enemy design.
Enemies aren't the only thing in the game, however, and remember that those other mechanics aren't just fluff. They allow the player to do something, and that's critical. Level design, how the player moves, what the avatar's actions are, power progressions, etc, etc. All of that has to be considered as well.
But just covering enemy design is plenty for one essay.
When I design a game - typically a tabletop RPG or board game, but sometimes computer games - there are four kinds of challenges I generally consider.
The first kind of challenge is the puzzle. This is when the scenario set up by the developer has a specific path to resolution. For example, a crate-pushing room. A fetch quest is technically a puzzle, but it's a crappy one.
The second kind of challenge is the information challenge. An info challenge is different from a puzzle because there is no "boolean" solution: there are many paths you can take and the results will vary in different ways. There is typically very little randomness in this kind of challenge, aside from that required to define the scenario. A good example is Civilization city-building: where you put your cities and what you build in/around them is not affected by randomness, but it's not a single-solution puzzle, either.
The third kind of challenge is the gamble. Gambles are typically simpler than information challenges and make up for it by having either randomness or real-time skill be a major component. This is the kind of challenge most enemies present: in an FPS, the accuracy and speed of the play is challenged, while in an RPG weighted dice rolls are substituted for real-time player skill. Same kind of challenge, either way.
The last kind of challenge is a fulfillment challenge, where you allow the player to alter a scenario in ways not usually tied directly to game mechanics. For example, allowing someone to dress in whatever way they want, or to add knickknacks to their house.
Of these four, the gamble is obviously where your enemies fit in easiest. The "standard five" model (eggshell, skirmisher, heavy, sniper, spawner) are built to challenge the general kinds of real-time skill a player can have.
However, it's important not to get too caught up in such a simplistic view. The gamble challenge isn't entirely served by enemies. For example, in Guitar Hero, the gamble challenge is the stream of notes. You don't need enemies, because the stream of notes serves the exact same purpose.
In other situations, the reverse happens, and enemies can (and should) bleed over into other challenge types. For example, a turtle in Super Mario Bros leaves behind a shell when you kill it. The shell is a tool used to turn gamble challenges (hopping on the goombas requires a fair amount of agility) to an information challenge (hitting the lot of them with a turtle shell normally doesn't require such agility).
I think most of the memorable games actually have that kind of very muddy situation, where it's hard to say that something is A or B. The information and gambling challenges often cross over each other. For example, in Tetris, dropping the blocks is obviously real-time skill, but it requires advanced pattern recognition as well, which is an information challenge component. It straddles the two.
Similarly, the strength of a tabletop RPG is that a puzzle challenge often converts over to an information challenge or gamble as the players go outside the expected conditions. The flexibility offered by an actual GM is one of the reasons that tabletop RPGs are still so popular despite their poor mechanical design and irritating interface.
To go a little philosophical, when I'm designing a new game, I lock down some images in my head to use as a kind of vision to drive my design. I say "images" because English is not a very good language: they're not simply images, but processes, potentials, and emotions as well.
Once I have a clear idea of the kind of thing I want to make, I try to come up with a core set of mechanics that will support all four kinds of challenges, or at least the latter three (not puzzles). As I'm doing this, I try to come up with specific situations where I can see the mechanics crossing: interesting play always happens where the mechanics collide. That's the "mixing" of challenge types I'm talking about, although you can also have collisions between different mechanics for the same kind of challenge.
All of this has been a pretty roundabout way of reaching this final point, which is how to make interesting enemies.
The way to make interesting enemies, as you may have guessed by reading about that mixing and colliding, is to make enemies that collide with other game mechanics. This is usually not done in AAA titles because it can make large games hopelessly complex and impossible to balance. But for indie games and mods, it's a must if you want to have interesting play.
As an example, let's look at a side-scrolling action game such as the Contra series. At its core, the navigation on the screen is an information challenge, while the interaction with enemies is a gamble.
If you're designing enemies for this kind of game, you'll probably start by simply considering the Fundamental Five. You create enemies that are eggshells, skirmishers, snipers, heavies, and spawners. But that's pretty dull. The best enemies collide the multiple kinds of challenges, the multiple kinds of mechanics. They create "boundary challenges", where the challenge is unusual because it interacts with multiple kinds of mechanics.
To some extent, this is placement. By putting enemies at specific points in a level, you can make them interact with the level layout, turning navigation from an information challenge into a gamble. For example, a section where an enemy is firing across an upper platform, and the player is required to jump up between the bullets to get up there and hit him. Another common variant is the "roller" which rolls along the top of the platform, then along the bottom and back up to the top in an endless circle.
On the opposite side of things are enemies that are platform navigation, such as a boss that has platforms on him, or a boss that requires you to jump to specific areas to dodge or hit him. It's normally only bosses that are built like this because it takes so long to actually play out the battle.
There's no reason to stick with the oldschool. For example, we can create enemies that can be stood on as if they were platforms, so luring them to a specific point so you can jump off them is important (or using them to cross spikes). Other enemies might only pop up and attack if you're standing on specific areas in the level - wall turrets, for example.
Still more options: enemies that destroy or create terrain, enemies that change the gravity in a region, enemies that deflect shots in unusual ways such that they might be able to hit a sniper if used correctly (or yourself, if used incorrectly).
Also, you can implement new mechanics to give you another thing to butt up against. As an example, if our game features a lot of swinging (Bionic Commando, Batman, Spider-Man) we can introduce enemies that butt into that: enemies that leave grease spots you can't attach to, enemies that cut your cable, enemies that swing, enemies you can swing from, etc, etc. And, of course, don't forget the normal level navigation, which can butt up against the swinging system as well.
There's no problem thinking of these kinds of fun enemies. I can think of them all day. The two problems related to these enemies are both easily manageable, if you keep them in mind.
The first problem is programming. Unless you think ahead, you can find yourself having to write very complex special-case code for every enemy in your game. Make sure to think ahead.
The second problem is complexity. It's easy to swamp a player with too many different kinds of boundary challenges, too quickly. Generally, I try to keep my players at one boundary condition per level. I go up to two if I feel that the boundary condition is suitably transparent. For example, I might use both the enemies-that-swing and the enemies-you-can-swing-from in the same level, because both of those are pretty straightforward. But combining enemies-that-are-platforms with enemies-that-generate-and-destroy-platforms would be sadistic, and only suitable for The Hard Boss.
This is basically an unwavering rule. If you revisit a particular boundary challenge in a later level, you want to make sure to get rid of one of the boundary challenges you were using. The human brain can only comprehend so much simultaneously. Later, if your boundary conditions become a genre, you can start to assume the player is completely familiar with them... but until then, make sure not to swamp the player with too many boundary conditions at the same time, even if they theoretically "learned" them earlier in the game.
To me, these are the basics of enemy design.
Enemies aren't the only thing in the game, however, and remember that those other mechanics aren't just fluff. They allow the player to do something, and that's critical. Level design, how the player moves, what the avatar's actions are, power progressions, etc, etc. All of that has to be considered as well.
But just covering enemy design is plenty for one essay.
Wednesday, April 14, 2010
Base Building
Muh brain's on fire! Time to talk about base building.
There is a very underappreciated set of games I like to call the base-building games. These are things like Sim City, Dwarf Fortress, Evil Genius, and the Sims. That last one isn't underappreciated, I know.
These are games where the main point is to build a functioning base of some kind.
They are often lumped together with RTS games and tower-defense games, but both of those are about managing attacks and defenses instead of building a base. They are distinct from the sorts of games I'm talking about, where the whole point is to build a functioning base, not to build functioning defenses or armies (which might be incidentally possible, but aren't the point).
Base building games fall on a spectrum. To the left we have the construction games, which focus more on deep dynamics that allow you to focus on construction for a long, long time. SimCity is the ur-example. There is nothing besides base construction in SimCity: the most non-base-construction thing in the game is setting your budget, which consists of about five variables.
To the right we have base management games, which have shallower dynamics and instead rely on micromanagement to take up the slack. The thing about these is that the micromanagement has almost nothing to do with the base construction. The Sims is the best example on this end. While there is base building (you make a house), the game is actually about painstakingly clicking your little inhabitants through every moment of their day.
Somewhat to the right on this scale is Evil Genius, which features a fairly complex base dynamic but heavily focuses on defending against agents and micromanaging your assets abroad. The trap construction... I don't know whether to consider that base building or not.
Somewhat to the left on this scale is Dwarf Fortress, which has very, VERY good base construction dynamics. But the player spends much of his time designating trees to be chopped down, ores to be mined, shoes to be built... despite the fact that you could rely wholly on base building to result in an interesting game, there is an aspect of micro-management.
All of these micro-managing aspects in all of the games listed have very little to do with the actual construction of your base. Building shoes and cutting trees doesn't matter how your base is laid out. Assigning fifty troops to the Bahamas doesn't change base on base layout. Getting your sims through their morning ablution doesn't care about your base layout.
There is some interaction, sure. If your house is palatial in the sims, it will take your sims an extra thirty minutes to get from the bathroom to the bedroom (because it takes them freaking five minutes to go one tile). Your layout in Evil Genius matters because many of your enemies will try to come in through the front door, but many more will magically pop up in the middle of your base and defending the front door is only slightly variable based on your layout. Etc, etc.
These days, most games tend to be more and more micromanagy. The days when a complex base WAS the game seem to be over in favor of splitting into Tower Defense and Base Micromanagement genres.
However, I think this is not irreversible. Base construction is a deep kind of play, and there's no reason not to use it. The key problem is that most people who make base construction games tend to make boring ones. As an example: there are fully half a dozen space station/space base construction games from the last decade, and the better ones are the earlier ones. As time has progressed, they have gotten shallower and shallower, more and more boring. The designers have forgotten how to make base construction interesting because they've been dazzled by RTS and base micromanagement games.
That would be fine if that was the sort of game they were building, but you can't just take those games and say, "now let's get rid of this irritating micromanagement/base defense part". That irritating part is the main gameplay!
So let's talk briefly about the kind of gameplay that usually makes for good base construction games.
First and foremost, base construction games take place in space. Most base construction games (such as SimCity) take place in two dimensions. A few take place in three dimensions. This dimensionality is the core from which all complexity grows.
Tower defense games know this, and are an excellent example. With a tower defense game, your enemies will follow paths in space, and you set up your turrets in optimal spaces to fire on them. This spatial interaction is the core of base construction, distilled to purity. But instead of interacting with incoming enemies, base construction interacts with base construction.
Where you put thing A and road B matters, because they exist in space and exert a certain influence.
Oversimplifying this to a radius effect is problematic: you either end up with tower defense or Simcity Societies. Instead, you want to quantify vectors and paths for the effects. In most base construction games, the primary path is the road. All your resources and people have to travel along the road (or the hall or whatever), so you build your base to (A) have short roads and (B) have its road needs distributed such that the roads aren't overwhelmed.
(You don't have to use only roads, by the way, but that's the most common setup.)
The other aspect to most base building games is an element of infrastructure. In SimCity this is extremely apparent: you have to hook up wires and run plumbing in addition to the roads. These conduits are distinct from roads because there is no real concern about how much is traveling through them or the range the resources travel. You can put your power station on a far hill and run ten miles of wire, you'll get power just the same as if you had your station next door.
The key to infrastructure complexity isn't in shortening them or balancing their loads, it's in establishing them at all. Can you cross one kind of infrastructure over another? What situations happen when they break down at a random point? That sort of thing.
This is distinct from the "virtual infrastructure" many RTS games use, where you just need to generate enough resource and it is magically allocated to wherever it is needed.
Infrastructure and paths are both core elements of play, and it varies as to what kind of thing falls into which category.
But that's not the limit. There are a few other things that affect play.
One is scaling. As your base grows, you usually run into scaling issues. Sometimes these issues are simply that you have stuff in nonoptimal places, paths that can't handle the strain. Other times whole new elements start coming to the fore, such as pollution in SimCity and nobles in Dwarf Fortress. This scaling is often the primary cause of concern for experts, who carefully build their bases to scale easily right from the first module.
Another is deformations. While a base can be very complex using only self-reference, it is located in space and space has other things in it. It is common to have various resources or hazards scattered around, or even just presence or lack of ground. These will force the base into specific kinds of shapes, and can shake up an expert's carefully-planned optimal layout.
The last I can think of is progress. By introducing new components or having goals with in-world results, things can become available/change state during play. This changes how a base grows and interacts, and adds further late-game complexity.
There is also the aspect of time compression that these games frequently add. If there are individuals in the game, managing their schedules is going to be critical and it's going to take them an hour to go fifty feet. However, this is certainly not a core base construction play dynamic. It's a micromanagement dynamic that's simply become super-common.
Anyway, I think that's enough chattering. I just thought I should write about it because I've built some base-building toys recently, and learned this crap the hard way.
What do you think?
There is a very underappreciated set of games I like to call the base-building games. These are things like Sim City, Dwarf Fortress, Evil Genius, and the Sims. That last one isn't underappreciated, I know.
These are games where the main point is to build a functioning base of some kind.
They are often lumped together with RTS games and tower-defense games, but both of those are about managing attacks and defenses instead of building a base. They are distinct from the sorts of games I'm talking about, where the whole point is to build a functioning base, not to build functioning defenses or armies (which might be incidentally possible, but aren't the point).
Base building games fall on a spectrum. To the left we have the construction games, which focus more on deep dynamics that allow you to focus on construction for a long, long time. SimCity is the ur-example. There is nothing besides base construction in SimCity: the most non-base-construction thing in the game is setting your budget, which consists of about five variables.
To the right we have base management games, which have shallower dynamics and instead rely on micromanagement to take up the slack. The thing about these is that the micromanagement has almost nothing to do with the base construction. The Sims is the best example on this end. While there is base building (you make a house), the game is actually about painstakingly clicking your little inhabitants through every moment of their day.
Somewhat to the right on this scale is Evil Genius, which features a fairly complex base dynamic but heavily focuses on defending against agents and micromanaging your assets abroad. The trap construction... I don't know whether to consider that base building or not.
Somewhat to the left on this scale is Dwarf Fortress, which has very, VERY good base construction dynamics. But the player spends much of his time designating trees to be chopped down, ores to be mined, shoes to be built... despite the fact that you could rely wholly on base building to result in an interesting game, there is an aspect of micro-management.
All of these micro-managing aspects in all of the games listed have very little to do with the actual construction of your base. Building shoes and cutting trees doesn't matter how your base is laid out. Assigning fifty troops to the Bahamas doesn't change base on base layout. Getting your sims through their morning ablution doesn't care about your base layout.
There is some interaction, sure. If your house is palatial in the sims, it will take your sims an extra thirty minutes to get from the bathroom to the bedroom (because it takes them freaking five minutes to go one tile). Your layout in Evil Genius matters because many of your enemies will try to come in through the front door, but many more will magically pop up in the middle of your base and defending the front door is only slightly variable based on your layout. Etc, etc.
These days, most games tend to be more and more micromanagy. The days when a complex base WAS the game seem to be over in favor of splitting into Tower Defense and Base Micromanagement genres.
However, I think this is not irreversible. Base construction is a deep kind of play, and there's no reason not to use it. The key problem is that most people who make base construction games tend to make boring ones. As an example: there are fully half a dozen space station/space base construction games from the last decade, and the better ones are the earlier ones. As time has progressed, they have gotten shallower and shallower, more and more boring. The designers have forgotten how to make base construction interesting because they've been dazzled by RTS and base micromanagement games.
That would be fine if that was the sort of game they were building, but you can't just take those games and say, "now let's get rid of this irritating micromanagement/base defense part". That irritating part is the main gameplay!
So let's talk briefly about the kind of gameplay that usually makes for good base construction games.
First and foremost, base construction games take place in space. Most base construction games (such as SimCity) take place in two dimensions. A few take place in three dimensions. This dimensionality is the core from which all complexity grows.
Tower defense games know this, and are an excellent example. With a tower defense game, your enemies will follow paths in space, and you set up your turrets in optimal spaces to fire on them. This spatial interaction is the core of base construction, distilled to purity. But instead of interacting with incoming enemies, base construction interacts with base construction.
Where you put thing A and road B matters, because they exist in space and exert a certain influence.
Oversimplifying this to a radius effect is problematic: you either end up with tower defense or Simcity Societies. Instead, you want to quantify vectors and paths for the effects. In most base construction games, the primary path is the road. All your resources and people have to travel along the road (or the hall or whatever), so you build your base to (A) have short roads and (B) have its road needs distributed such that the roads aren't overwhelmed.
(You don't have to use only roads, by the way, but that's the most common setup.)
The other aspect to most base building games is an element of infrastructure. In SimCity this is extremely apparent: you have to hook up wires and run plumbing in addition to the roads. These conduits are distinct from roads because there is no real concern about how much is traveling through them or the range the resources travel. You can put your power station on a far hill and run ten miles of wire, you'll get power just the same as if you had your station next door.
The key to infrastructure complexity isn't in shortening them or balancing their loads, it's in establishing them at all. Can you cross one kind of infrastructure over another? What situations happen when they break down at a random point? That sort of thing.
This is distinct from the "virtual infrastructure" many RTS games use, where you just need to generate enough resource and it is magically allocated to wherever it is needed.
Infrastructure and paths are both core elements of play, and it varies as to what kind of thing falls into which category.
But that's not the limit. There are a few other things that affect play.
One is scaling. As your base grows, you usually run into scaling issues. Sometimes these issues are simply that you have stuff in nonoptimal places, paths that can't handle the strain. Other times whole new elements start coming to the fore, such as pollution in SimCity and nobles in Dwarf Fortress. This scaling is often the primary cause of concern for experts, who carefully build their bases to scale easily right from the first module.
Another is deformations. While a base can be very complex using only self-reference, it is located in space and space has other things in it. It is common to have various resources or hazards scattered around, or even just presence or lack of ground. These will force the base into specific kinds of shapes, and can shake up an expert's carefully-planned optimal layout.
The last I can think of is progress. By introducing new components or having goals with in-world results, things can become available/change state during play. This changes how a base grows and interacts, and adds further late-game complexity.
There is also the aspect of time compression that these games frequently add. If there are individuals in the game, managing their schedules is going to be critical and it's going to take them an hour to go fifty feet. However, this is certainly not a core base construction play dynamic. It's a micromanagement dynamic that's simply become super-common.
Anyway, I think that's enough chattering. I just thought I should write about it because I've built some base-building toys recently, and learned this crap the hard way.
What do you think?
Tuesday, April 13, 2010
The Standard Set
I've played a lot of games, and one thing I notice is that the enemies are all very "samey". Regardless of the kind of game, enemies tend to fall into the same five categories: the eggshell, the heavy, the skirmisher, the sniper, and the spawner. Whether the game is a first-person shooter, an RPG, or even a CCG, these hold true.
(Similarly, there are a common set of categories for players. It used to be the D&D standard, now it's the MMORPG standard, but it's the same rut.)
Just to show you more clearly what I mean, let me describe the Dead Space enemies. In dead space you have slow zombies, which are a really weak heavy. A stronger heavy is the rhino-thing.
You have those flying bat-things that make zombies, those are spawners. Another spawner is the fat-belly thing. The exploding arm guys are eggshells, as are the tiny insect swarms. The baby things are snipers, the scorpion-men are skirmishers, etc, etc. All the enemies slot neatly into these five categories.
And Dead Space was well known for its unique enemy design!
So this popped up a question in my head. Is it that there are only five kinds of enemy that can be made, or is it that people aren't very creative?
Let's take a look at another game: Super Mario Brothers.
In SMB just about none of the enemies fall into these categories. You have to really squint if you want to even try. Technically, I guess a Goomba is an eggshell. But what's a turtle? Even if you do decide it fits into a category, the enemy is not about offering a challenge of that type. It's about being a mobile obstacle and resource (as it drops a shell when you kill it).
Ah, there's the key for me.
The five enemy types I've listed are really kinds of challenges you can offer. It turns out that game designers have created a very stable platform for challenges, a nicely modular set-up that we almost invariably follow. It can be easily adapted to suit one-character or teams of heroes, any kind of setting, any kind of power level. It offers enough complexity to make things interesting but not enough to require careful thought. It is ideal for the kind of middle-of-the-road challenge that most games like.
But most of the games I remember best don't use that standard challenge platform. Sometimes they are close to the same kind of game, such as Shadows of the Colossus. Sometimes they are completely different kinds of game with completely different challenge types, such as Katamari Damacy.
So I'm a fan of not using the standard challenge set if you're making a game that can support it. By using an unusual challenge set when everyone else uses a standard one, you can make your game stand out, whether it's a tabletop RPG or a mod for Half Life.
Coming up with an unusual challenge can be difficult because your brain has likely fallen into a rut without realizing it. The key is to create a different fight dynamic. If your fight dynamic is the normal one, you can't change the normal enemy set very easily. Instead, you've got to make your fight dynamic really weird. Shadows of the Colossus and Katamari Damacy are both decent examples, as is the original Valkyrie Profile, the early survival horror games, and many other games that stand out as being unique. Changing the dynamic even slightly can result in very different kinds of enemies, because the challenge to the player is different.
Here is an example that occurred to me. I watched an LP of the new Spider-Man game, and it has some interesting fighting-on-walls stuff. Spider-Man has the unusual ability to stick to surfaces both with web and with his extremities, which makes him one of the few superheroes who can sensically exert huge amounts of force, such as lifting a car.
The combat seemed pretty normal in the game, but it got me thinking: what if the whole point of the game was this stick-to-stuff fighting? What if the point of many of the enemies wasn't to injure you, but to try to detach you from the wall, or make the wall too slippery to grab, or similarly affect your traction?
Suddenly you can play host to a whole new kind of dynamic, where fighting is not simply about attacking and blocking. Adding this new dimension of stickiness not only increases the player's options for attacking, but also increases the number of dimensions that you can create enemies on. Even if you want to use the same "standard five" (plus terrain-effector) enemy types, you can now make an enemy skirmisher-damage or skirmisher-destick, so you suddenly have twelve kinds of enemy instead of six.
Don't underestimate the depth of play that results from this. For example, Spidey may have to choose between a strongly-tethered set of attacks relying on his web-pull abilities and three anchored extremities, a medium-tethered set relying on kicks and punches while one extremity is always gripping, or a low-tether set where he swings or slides rapidly but has no direct grip on the wall and therefore cannot exert much force aside from momentum, and is at risk of being knocked off. This is a lot more depth than the Spider-Man game I saw offered: it just offered the standard set of attack, block, charge.
...
The other half of the coin is that you can make up really wonky settings and combat dynamics, but use the standard set for your actual mechanics. This allows you to ground your insane idea in a strong foundation.
For reference, the "expanded" standard set is the eggshell, the heavy, the skirmisher, the sniper, the spawner, the buffer, the terrain-effector, and the puzzle-enemy. All of these are viable, although the last three are usually reserved for bosses due to their high complexity level. Obviously, this list plays fast and loose, but it should serve to help you ground your play.
So lets say you decide to make a game about school politics. The "fight" dynamic is all about social maneuvering. And you say to yourself, "I really like this idea, but I'm having a hard time figuring out how to make it interesting enough to actually play!"
Well, the answer is to start coming up with enemies that fit the standard set, and a rule set that supports them.
Maybe the eggshell enemy is a lackey, someone who follows a more popular person but isn't popular on their own. The heavy is someone who is well-respected but not very interested in politics, so they move slowly to counter you but hit very hard, socially speaking. The football captain, maybe. A skirmisher moves fast and hits hard - someone who is very socially aware but has few merits to defend with. Say, a queen bitch.
The sniper is someone who excels at hitting your weak spot and using your past failings against you. They probably aren't popular on their own, but they can reveal devastating secrets or horrifyingly brutal insults if you let them. A spawner might be someone with a seemingly limitless supply of cronies, or it might be someone who really understands how to let loose a rumor that will spread across the whole school.
And so on and so on.
The point is that, from this standard set, you can shape your recalcitrant idea into a state where it has suitable depth and complexity.
Anyway, that's my rant on the standard set.
What do you think?
(Similarly, there are a common set of categories for players. It used to be the D&D standard, now it's the MMORPG standard, but it's the same rut.)
Just to show you more clearly what I mean, let me describe the Dead Space enemies. In dead space you have slow zombies, which are a really weak heavy. A stronger heavy is the rhino-thing.
You have those flying bat-things that make zombies, those are spawners. Another spawner is the fat-belly thing. The exploding arm guys are eggshells, as are the tiny insect swarms. The baby things are snipers, the scorpion-men are skirmishers, etc, etc. All the enemies slot neatly into these five categories.
And Dead Space was well known for its unique enemy design!
So this popped up a question in my head. Is it that there are only five kinds of enemy that can be made, or is it that people aren't very creative?
Let's take a look at another game: Super Mario Brothers.
In SMB just about none of the enemies fall into these categories. You have to really squint if you want to even try. Technically, I guess a Goomba is an eggshell. But what's a turtle? Even if you do decide it fits into a category, the enemy is not about offering a challenge of that type. It's about being a mobile obstacle and resource (as it drops a shell when you kill it).
Ah, there's the key for me.
The five enemy types I've listed are really kinds of challenges you can offer. It turns out that game designers have created a very stable platform for challenges, a nicely modular set-up that we almost invariably follow. It can be easily adapted to suit one-character or teams of heroes, any kind of setting, any kind of power level. It offers enough complexity to make things interesting but not enough to require careful thought. It is ideal for the kind of middle-of-the-road challenge that most games like.
But most of the games I remember best don't use that standard challenge platform. Sometimes they are close to the same kind of game, such as Shadows of the Colossus. Sometimes they are completely different kinds of game with completely different challenge types, such as Katamari Damacy.
So I'm a fan of not using the standard challenge set if you're making a game that can support it. By using an unusual challenge set when everyone else uses a standard one, you can make your game stand out, whether it's a tabletop RPG or a mod for Half Life.
Coming up with an unusual challenge can be difficult because your brain has likely fallen into a rut without realizing it. The key is to create a different fight dynamic. If your fight dynamic is the normal one, you can't change the normal enemy set very easily. Instead, you've got to make your fight dynamic really weird. Shadows of the Colossus and Katamari Damacy are both decent examples, as is the original Valkyrie Profile, the early survival horror games, and many other games that stand out as being unique. Changing the dynamic even slightly can result in very different kinds of enemies, because the challenge to the player is different.
Here is an example that occurred to me. I watched an LP of the new Spider-Man game, and it has some interesting fighting-on-walls stuff. Spider-Man has the unusual ability to stick to surfaces both with web and with his extremities, which makes him one of the few superheroes who can sensically exert huge amounts of force, such as lifting a car.
The combat seemed pretty normal in the game, but it got me thinking: what if the whole point of the game was this stick-to-stuff fighting? What if the point of many of the enemies wasn't to injure you, but to try to detach you from the wall, or make the wall too slippery to grab, or similarly affect your traction?
Suddenly you can play host to a whole new kind of dynamic, where fighting is not simply about attacking and blocking. Adding this new dimension of stickiness not only increases the player's options for attacking, but also increases the number of dimensions that you can create enemies on. Even if you want to use the same "standard five" (plus terrain-effector) enemy types, you can now make an enemy skirmisher-damage or skirmisher-destick, so you suddenly have twelve kinds of enemy instead of six.
Don't underestimate the depth of play that results from this. For example, Spidey may have to choose between a strongly-tethered set of attacks relying on his web-pull abilities and three anchored extremities, a medium-tethered set relying on kicks and punches while one extremity is always gripping, or a low-tether set where he swings or slides rapidly but has no direct grip on the wall and therefore cannot exert much force aside from momentum, and is at risk of being knocked off. This is a lot more depth than the Spider-Man game I saw offered: it just offered the standard set of attack, block, charge.
...
The other half of the coin is that you can make up really wonky settings and combat dynamics, but use the standard set for your actual mechanics. This allows you to ground your insane idea in a strong foundation.
For reference, the "expanded" standard set is the eggshell, the heavy, the skirmisher, the sniper, the spawner, the buffer, the terrain-effector, and the puzzle-enemy. All of these are viable, although the last three are usually reserved for bosses due to their high complexity level. Obviously, this list plays fast and loose, but it should serve to help you ground your play.
So lets say you decide to make a game about school politics. The "fight" dynamic is all about social maneuvering. And you say to yourself, "I really like this idea, but I'm having a hard time figuring out how to make it interesting enough to actually play!"
Well, the answer is to start coming up with enemies that fit the standard set, and a rule set that supports them.
Maybe the eggshell enemy is a lackey, someone who follows a more popular person but isn't popular on their own. The heavy is someone who is well-respected but not very interested in politics, so they move slowly to counter you but hit very hard, socially speaking. The football captain, maybe. A skirmisher moves fast and hits hard - someone who is very socially aware but has few merits to defend with. Say, a queen bitch.
The sniper is someone who excels at hitting your weak spot and using your past failings against you. They probably aren't popular on their own, but they can reveal devastating secrets or horrifyingly brutal insults if you let them. A spawner might be someone with a seemingly limitless supply of cronies, or it might be someone who really understands how to let loose a rumor that will spread across the whole school.
And so on and so on.
The point is that, from this standard set, you can shape your recalcitrant idea into a state where it has suitable depth and complexity.
Anyway, that's my rant on the standard set.
What do you think?
Sunday, March 28, 2010
Collective Rewinding
It's all too common that people just want to use the same mechanics with microscopic tweaks. Here's an example of taking a "samey" mechanic and making a very, very different kind of dynamic from it.
Let's think of a game like Prince of Persia or Braid, where you can rewind time. You get hit by a car, you rewind time and don't walk into the street just then.
Now make it multiplayer. If anyone gets hit by a car, they rewind time and don't walk into the street. However, this raises the question of "what do the other players see"?
What if all the players - and even the NPCs - could rewind time, but they all saw it rewinding? So, if you get hit by a car, you rewind time. The guy driving the car then drives by with an apologetic wave: "sorry for willen-haven hitted you with my car!" He also witnessed the rewind, either as a player or an NPC.
Ignoring the obvious "how can I do my murdering" issues, let's look at a bigger issue. Now we run into the trouble that, in any population larger than maybe 10, we're going to be rewinding all the time, in very irritating ways.
There are several solutions to this, but for this particular post I've decided to localize the effects. The car hits you, and you rewind 10 seconds. Let's say you rewind very fast: 10 seconds in one "witnessed second". You and the car pass amicably after that.
The man on the street corner doesn't see ten seconds rewind. In his second of rewind, he only sees two seconds rewind. The man in his fifth-story apartment only sees half a second of rewind in that second. And the man watching a movie in the nearby cinema sees time slow to half for that second.
This gives us a very weird and interesting game mechanic. I recommend thinking about it for a bit before continuing, because while I have some ideas I'll show, it's a big enough thing that there are probably loads of ways to get fun dynamics out of it.
...
Lets put aside the various physicsical stuff such as shear and reversed light. Lets put aside the sociological ramifications of a world without accidents.
Instead, let's think about killing.
Imagine a typical multiplayer "fragfest" with these mechanics in mind. How would it work? Well, if you shot someone, they'd rewind time and get un-shot.
However, assuming you're beyond their "event horizon" (where their field goes from rewinding time to slowing time) you can continue to move forward while they move backwards, and continue to shoot them even as they rewind time. This doesn't help: your bullets will slow as they approach the event horizon, so you'll never hit them.
We can also assume that you might "fast forward" time in an attempt to create a conflicting field. But it would, at best, push the event horizon back towards the target, never actually letting you hit them.
So, how would you get kills?
Well, you could kill them such that they couldn't rewind time. If we presume they need brains to rewind time, headshots are a good way to do that. But I don't like that mechanic, so let's say that they can rewind time even after death.
You could kill them while they're in a state that they can't rewind time, such as killing them in their sleep without waking them up. But that's not a very common situation in a video game, and it's really sleazy besides.
But you could simply run them out of rewind, either because rewind is limited or because you run them back all the way to their spawn point and they "un-spawn". In the latter case, it's probably not a point: they probably just re-spawn somewhere else. The former case is fun and interesting, so let's put a cap on rewind capability: say, fifteen seconds of rewind at a maximum of two seconds per second (thirty seconds of history, max). That'll give us a fun chase scene.
There's also the idea of killing them because they're rewinding. For example, what if they crossed a bridge, and we break the bridge, throwing it into the ravine. During their rewind, they'll un-cross the bridge. The bridge bits are outside their rewind field, so they'll basically walk backwards and fall to their doom. This is assuming that physics apply in that way: we could also argue that they would walk backwards across "nothing" in the exact same manner they walked forwards, but I don't like that idea, because this way is much more interesting.
Simply erecting a spike wall behind them wouldn't work, because the wall would begin to rewind as the player rewound near it, and it would roll out of the way in plenty of time, back towards wherever it came from. Instead, the core thing would be to make sure that something that was there isn't there.
The game becomes a tactical game where you need to either chase someone back through time long enough to kill them, or change where they ran such that their rewinding screws them over, or both. For example, create a small pit using a grenade behind them. As they rewind, they get stuck in the pit, giving you an easy time chasing them down because they're not moving.
There are a lot of deep things we could do with this. Skill-wise, players learn to either hide their past or move to maximize safety. For example, a random jump now and then will offer some protection against the kind of trap I set in the previous paragraph, even though it made no sense at the time you originally did it. It becomes common to drop from heights, so that when you rewind, you scale a cliff that your pursuer can't follow you up. Mashers and stampers are an important element of safety: difficult to go through moving forwards in time, but guaranteed safe once you've gotten through and want to move backwards again. Not so for your pursuer.
You can set-up counter-traps: lay down a turret or a friend, move across its line of fire. Later, when an enemy is chasing you through time, they step right into the line of fire and have to rewind themselves. Because they've probably been "fast-forwarding" to keep your field small and to help keep up with you, they're probably close to out of juice and are easy prey.
Also, there are some things we can do by making certain exceptions for time rules. For example, let's say players are also telekinetic. While something is being telekinetically affected, let's say it is always aligned with your time field no matter where it is. To keep this sane, let's say you can only telekinetically pull, not push.
Telekinetically grab that can from over there! Woo! Okay, drop it, who cares. But when you're rewinding, that becomes a 2x-speed "bullet" fired from your rewinding self. If you've angled it right, that could easily slam into a pursuer for serious harm, especially if he's also moving at double speed "forward" to chase you.
If a rewinding enemy passes between you and a saw blade, pull the saw blade. It cuts right through the rewinding, so keep your eyes open and if you're worried about whether an object might be used to kill you, grab it and put it somewhere safe.
Out of these rules we've created an extremely distinct (if completely imaginary) shooter game where everyone can rewind time... but it's still a viable shooter and a very unique one.
There are loads of other things you can do with this "localized rewind/fast forward", I've just scratched the surface. What would you make?
Let's think of a game like Prince of Persia or Braid, where you can rewind time. You get hit by a car, you rewind time and don't walk into the street just then.
Now make it multiplayer. If anyone gets hit by a car, they rewind time and don't walk into the street. However, this raises the question of "what do the other players see"?
What if all the players - and even the NPCs - could rewind time, but they all saw it rewinding? So, if you get hit by a car, you rewind time. The guy driving the car then drives by with an apologetic wave: "sorry for willen-haven hitted you with my car!" He also witnessed the rewind, either as a player or an NPC.
Ignoring the obvious "how can I do my murdering" issues, let's look at a bigger issue. Now we run into the trouble that, in any population larger than maybe 10, we're going to be rewinding all the time, in very irritating ways.
There are several solutions to this, but for this particular post I've decided to localize the effects. The car hits you, and you rewind 10 seconds. Let's say you rewind very fast: 10 seconds in one "witnessed second". You and the car pass amicably after that.
The man on the street corner doesn't see ten seconds rewind. In his second of rewind, he only sees two seconds rewind. The man in his fifth-story apartment only sees half a second of rewind in that second. And the man watching a movie in the nearby cinema sees time slow to half for that second.
This gives us a very weird and interesting game mechanic. I recommend thinking about it for a bit before continuing, because while I have some ideas I'll show, it's a big enough thing that there are probably loads of ways to get fun dynamics out of it.
...
Lets put aside the various physicsical stuff such as shear and reversed light. Lets put aside the sociological ramifications of a world without accidents.
Instead, let's think about killing.
Imagine a typical multiplayer "fragfest" with these mechanics in mind. How would it work? Well, if you shot someone, they'd rewind time and get un-shot.
However, assuming you're beyond their "event horizon" (where their field goes from rewinding time to slowing time) you can continue to move forward while they move backwards, and continue to shoot them even as they rewind time. This doesn't help: your bullets will slow as they approach the event horizon, so you'll never hit them.
We can also assume that you might "fast forward" time in an attempt to create a conflicting field. But it would, at best, push the event horizon back towards the target, never actually letting you hit them.
So, how would you get kills?
Well, you could kill them such that they couldn't rewind time. If we presume they need brains to rewind time, headshots are a good way to do that. But I don't like that mechanic, so let's say that they can rewind time even after death.
You could kill them while they're in a state that they can't rewind time, such as killing them in their sleep without waking them up. But that's not a very common situation in a video game, and it's really sleazy besides.
But you could simply run them out of rewind, either because rewind is limited or because you run them back all the way to their spawn point and they "un-spawn". In the latter case, it's probably not a point: they probably just re-spawn somewhere else. The former case is fun and interesting, so let's put a cap on rewind capability: say, fifteen seconds of rewind at a maximum of two seconds per second (thirty seconds of history, max). That'll give us a fun chase scene.
There's also the idea of killing them because they're rewinding. For example, what if they crossed a bridge, and we break the bridge, throwing it into the ravine. During their rewind, they'll un-cross the bridge. The bridge bits are outside their rewind field, so they'll basically walk backwards and fall to their doom. This is assuming that physics apply in that way: we could also argue that they would walk backwards across "nothing" in the exact same manner they walked forwards, but I don't like that idea, because this way is much more interesting.
Simply erecting a spike wall behind them wouldn't work, because the wall would begin to rewind as the player rewound near it, and it would roll out of the way in plenty of time, back towards wherever it came from. Instead, the core thing would be to make sure that something that was there isn't there.
The game becomes a tactical game where you need to either chase someone back through time long enough to kill them, or change where they ran such that their rewinding screws them over, or both. For example, create a small pit using a grenade behind them. As they rewind, they get stuck in the pit, giving you an easy time chasing them down because they're not moving.
There are a lot of deep things we could do with this. Skill-wise, players learn to either hide their past or move to maximize safety. For example, a random jump now and then will offer some protection against the kind of trap I set in the previous paragraph, even though it made no sense at the time you originally did it. It becomes common to drop from heights, so that when you rewind, you scale a cliff that your pursuer can't follow you up. Mashers and stampers are an important element of safety: difficult to go through moving forwards in time, but guaranteed safe once you've gotten through and want to move backwards again. Not so for your pursuer.
You can set-up counter-traps: lay down a turret or a friend, move across its line of fire. Later, when an enemy is chasing you through time, they step right into the line of fire and have to rewind themselves. Because they've probably been "fast-forwarding" to keep your field small and to help keep up with you, they're probably close to out of juice and are easy prey.
Also, there are some things we can do by making certain exceptions for time rules. For example, let's say players are also telekinetic. While something is being telekinetically affected, let's say it is always aligned with your time field no matter where it is. To keep this sane, let's say you can only telekinetically pull, not push.
Telekinetically grab that can from over there! Woo! Okay, drop it, who cares. But when you're rewinding, that becomes a 2x-speed "bullet" fired from your rewinding self. If you've angled it right, that could easily slam into a pursuer for serious harm, especially if he's also moving at double speed "forward" to chase you.
If a rewinding enemy passes between you and a saw blade, pull the saw blade. It cuts right through the rewinding, so keep your eyes open and if you're worried about whether an object might be used to kill you, grab it and put it somewhere safe.
Out of these rules we've created an extremely distinct (if completely imaginary) shooter game where everyone can rewind time... but it's still a viable shooter and a very unique one.
There are loads of other things you can do with this "localized rewind/fast forward", I've just scratched the surface. What would you make?
Tuesday, March 16, 2010
Seedlings
Because I feel like it, I'll post a little bit from an earlier speculative tabletop scifi RPG I wrote. In the previous post I explained how a game had funky laws about privacy and information, and in this post I'll talk about how the game before that had weird ideas about what an "information economy" really is.
The game was written by me when I was trying to figure out what the "killer app" for 3D printers would be. The final result had very little do with the question, but it might still be interesting.
Unlike the last game I talked about, this game (named 'Seedlings') was not about information for information's sake. Instead, it was about information that can be turned into something real. For example, the file embodying a chair: feed it into a 3D printer, and you get a chair. The file embodying a flower: print the DNA into a seeder, and you end up with that flower.
The difficulty was in the game mechanics. Most RPGs are about killing and looting. The inherently constructive nature of the game made that impossible. Killing someone and stealing their computer is weak compared to getting the file they used to print their computer, at which point you can print an unlimited number yourself.
The core idea is turning information into physical objects, but there's no recurring play in that. Once you've printed something out, you have it. Even if you posit that it breaks, you're still able to print up an identical one. Without some kind of ridiculous conceit, once you've printed something, you have it, done.
The same problem exists with real 3D printers. You just don't need to print that much stuff. The stuff you use new every day is largely food and packaging. The first can't be printed, the second makes no sense to print. If you do need to print something (such as a book shelf or a new iPhone case), you print it and you're done. There's no "rolling ball" to chase, like there is with our never-ending stream of lattes.
Every way I pushed the rule set I ran into trouble. I couldn't find any core mechanic that would sustain an entire RPG. I thought about making it a game about investigation, but those never fly. I thought about making it some kind of strategy/people-management game, but those are poorly suited for paper.
The only thing I could think of in the end was DNA. If instead of using fabricators, I used DNA, I could put in time delays.
Sure, you can print out anything you want, but it will take days or weeks to grow to full size.
This started getting really weird as I pushed it further and further. I drew sketches of the sorts of places you would encounter.
For example, you're walking through suburbia, and everyone's back yard is full of multicolored plants. One mom says to another, "oh, yeah, Jimmie tore up his pants, so I put them in the compost. The denim plants are in bloom, anyway, so I just had him pull new pants off the vine..."
The villainous Doctor Imevil is hidden away on a mountainside. He's growing a new base, and you can see the photovoltaic ferns blooming on his roof. To keep it from giving him away, he's carefully seeded the whole mountainside with them, pretending it's an uncontrolled propagation of a known product, blaming the original researchers who designed the plant.
The 'last mile' is covered by silk-thin tendrils of roots growing from house to house... to tap a phone, you would plant a "tap-plant" and wait for its roots to find the transmission roots.
Although classic pollution is not as much a problem as it was, the sky at night glitters with microscopic organisms battling it out as the city releases swarms of hunter-killer germs to counter today's diseases, brought in on the winds or the planes. These diseases don't affect the populace - the hunter-killers are extremely effective - but you will sometimes find the sidewalk covered in a glittering puddle. You don't want to know what caused the puddle, but you can be sure it's not contagious. Sure, there's no reason for it to glitter, but I take some license.
And, of course, living clothes, adaptive streets, and semi-intelligent plant life.
These don't directly turn into gameplay, but I find that strong imagery really helps me get a feel for the game. Unfortunately, the final rule set ended up being a combination of a strategy game and a detective game, so blah.
Still, the point is that I can't really think of a "killer app" for a 3D printer. The only things I can think of all revolve around evading the law or living in places where there are no stores. But I can think of a million killer apps for "living" 3D printers.
Now if only I could figure out how to make it into a game worth playing.
The game was written by me when I was trying to figure out what the "killer app" for 3D printers would be. The final result had very little do with the question, but it might still be interesting.
Unlike the last game I talked about, this game (named 'Seedlings') was not about information for information's sake. Instead, it was about information that can be turned into something real. For example, the file embodying a chair: feed it into a 3D printer, and you get a chair. The file embodying a flower: print the DNA into a seeder, and you end up with that flower.
The difficulty was in the game mechanics. Most RPGs are about killing and looting. The inherently constructive nature of the game made that impossible. Killing someone and stealing their computer is weak compared to getting the file they used to print their computer, at which point you can print an unlimited number yourself.
The core idea is turning information into physical objects, but there's no recurring play in that. Once you've printed something out, you have it. Even if you posit that it breaks, you're still able to print up an identical one. Without some kind of ridiculous conceit, once you've printed something, you have it, done.
The same problem exists with real 3D printers. You just don't need to print that much stuff. The stuff you use new every day is largely food and packaging. The first can't be printed, the second makes no sense to print. If you do need to print something (such as a book shelf or a new iPhone case), you print it and you're done. There's no "rolling ball" to chase, like there is with our never-ending stream of lattes.
Every way I pushed the rule set I ran into trouble. I couldn't find any core mechanic that would sustain an entire RPG. I thought about making it a game about investigation, but those never fly. I thought about making it some kind of strategy/people-management game, but those are poorly suited for paper.
The only thing I could think of in the end was DNA. If instead of using fabricators, I used DNA, I could put in time delays.
Sure, you can print out anything you want, but it will take days or weeks to grow to full size.
This started getting really weird as I pushed it further and further. I drew sketches of the sorts of places you would encounter.
For example, you're walking through suburbia, and everyone's back yard is full of multicolored plants. One mom says to another, "oh, yeah, Jimmie tore up his pants, so I put them in the compost. The denim plants are in bloom, anyway, so I just had him pull new pants off the vine..."
The villainous Doctor Imevil is hidden away on a mountainside. He's growing a new base, and you can see the photovoltaic ferns blooming on his roof. To keep it from giving him away, he's carefully seeded the whole mountainside with them, pretending it's an uncontrolled propagation of a known product, blaming the original researchers who designed the plant.
The 'last mile' is covered by silk-thin tendrils of roots growing from house to house... to tap a phone, you would plant a "tap-plant" and wait for its roots to find the transmission roots.
Although classic pollution is not as much a problem as it was, the sky at night glitters with microscopic organisms battling it out as the city releases swarms of hunter-killer germs to counter today's diseases, brought in on the winds or the planes. These diseases don't affect the populace - the hunter-killers are extremely effective - but you will sometimes find the sidewalk covered in a glittering puddle. You don't want to know what caused the puddle, but you can be sure it's not contagious. Sure, there's no reason for it to glitter, but I take some license.
And, of course, living clothes, adaptive streets, and semi-intelligent plant life.
These don't directly turn into gameplay, but I find that strong imagery really helps me get a feel for the game. Unfortunately, the final rule set ended up being a combination of a strategy game and a detective game, so blah.
Still, the point is that I can't really think of a "killer app" for a 3D printer. The only things I can think of all revolve around evading the law or living in places where there are no stores. But I can think of a million killer apps for "living" 3D printers.
Now if only I could figure out how to make it into a game worth playing.
Friday, March 12, 2010
Funny Laws of the New Century
Every few months I try to write a scifi RPG (tabletop) using fairly realistic reactions to theoretical advancements. Basically, I try to write some speculative fiction in game form. I never publish or anything, but the one I created last month has some interesting characteristics, so I thought I'd share a few of the details.
The tabletop game is codenamed "anonymesh", and revolves around the idea of a massive, dense network of interconnected wireless nodes. Extremely low-energy computers combined with cheap solar cells make running a wireless node quite literally free, and so most people use "meshnet" instead of the centralized backbone internet. This leads to a lot of really interesting characteristics, and as you might expect, the players all play hackers.
The interesting bits are endless, but one of the most interesting things that popped out of this universe was the idea of "deanning". Basically, I tried to think of the weirdest, cleverest laws I could, and some of the privacy laws that emerged were very strange.
For example, you can take a picture of main street and post it on line without getting anyone's permission, without blurring faces, without any of that, because the people in the picture are anonymous.
What isn't legal is running face-scanning technology across that image to identify who these people are. This is de-anonymizing the data, or "deanning" it. Technically, while the deanning is illegal, it can't be enforced. Instead, only the propagation of deanned data is illegal. (More specifically, the propagation of any non-anonymous data without permission, regardless of whether it's been deanned or was never anonymized in the first place.) Data is considered non-anonymous if it reveals more of the person's personal information than the person expected to people they didn't intend. This is an objective statement, but a huge and growing number of guidelines exist in the courts to support it.
This has a huge number of implications, especially since propagation includes "feeding into data mining programs for purposes unrelated to the initial data".
So if you buy a bagel, the bagel shop can remember you bought a bagel. But they can't use the fact that you bought a bagel for non-you-buying-bagel purposes. They can't email you ads, they can't use your preferences in analysis of what bagels are best, they certainly can't sell your debit card info to another company. Not unless the data is properly anonymized. So they can say that their Washington Ave store sold a poppy seed bagel at 10:45 AM, but not who bought it.
It's pretty easy for anyone to save up a lot of vaguely related data and then dean it using basic pattern recognition tools. For example, if you record main street 24/7, you can easily start matching up individuals and determining their habits. Combined with a simple web trawl, you may be able to identify a significant number of people and their exact schedules.
This is illegal, but how would you enforce it? Especially since it's so easy to do with the mesh network: ten thousand man-in-the-middle attacks per message. Just save every bit of recognizable traffic. Analyze encryptions: you'll have gigabytes of data from the same source spooling by day after day, cracking it is just a matter of time and effort.
Well, the truth is that things get deanned all the time. You don't even have to run a thieving wifi router to get enough data to dean. You can dean from an internet search.
But using this information generally leaves a pretty clear trail. The same algorithms that can dean anonymous data can detect when a project or statement contains references to less-than-anonymous data. Individuals rarely have to worry about this in the same way pirates rarely worry about it. But companies have to worry, and have to be scrupulous.
This is especially dangerous to them because many of the wifi routers they depend on are run by untrusted sources who would love nothing better than to forward their illegal data to the police for a reward. It's not illegal to copy the information transferred through their router, not illegal to decrypt it, either, due to some anti-terrorism laws passed by the panicky government.
It's also not illegal to hack into devices, although it is illegal to use those hacked devices in an illegal manner (including data theft). This means that if you do dean data, you want to make sure you do it on an offline-only machine that can't be hacked remotely. Otherwise a hacker might forward that data to the police for that reward, get you thrown in jail.
Those are some of the basic rules, which actually make for a surprisingly interesting hacker game dynamic. There are a few things that may not occur to you at first read, though. Here are a few of those things:
Your friends can talk about you. This is called "implicit permission to dean". Where this permission ends is a rough concept and depends on what the individual has released publicly in the past.
Things you publish "publicly" that aren't intended for public use - for example, your mood on LiveJournal - are considered non-public data. The end user is not expected to always know exactly how every piece of software works, and therefore it is not the user that is held accountable, but the software and those that propagate the information for their own purposes.
So-called "shadow puppets" can be made. These are VR/AR avatars built out of real data fed to them. For example, feed your shadow puppet all the president's videos and speeches, and you have a shadow puppet that looks, talks, and acts like the president. This is almost always a dean even if you do it on public and non-anonymous data, because the shadow puppet can be made to act in a manner normally considered to be private and personal. For example, you can make your president puppet strip naked and dance the watusi. You can also release simulations of the president saying things he normally wouldn't say.
The law hasn't caught up to that extent, yet. Sometimes the infringements are allowed as parody, and sometimes the shadow puppet is waved off as not breaching privacy, but people are starting to crack down on the matter ever since a parody site began releasing pixel-perfect variants of Fox News shows.
"Virtual characters" have some very complex rights ever since the supreme court came down on the side of Disney to find that a shadow puppet of Mickey was not only a violation of trademark, but also a violation of "expected privacy on behalf of Mickey Mouse".
Anyway, the actual game is significantly more detailed (it's actually a bit too detailed for a tabletop game), but the laws about anonymizing and deanning were interesting enough I thought I'd talk about them on their own.
The tabletop game is codenamed "anonymesh", and revolves around the idea of a massive, dense network of interconnected wireless nodes. Extremely low-energy computers combined with cheap solar cells make running a wireless node quite literally free, and so most people use "meshnet" instead of the centralized backbone internet. This leads to a lot of really interesting characteristics, and as you might expect, the players all play hackers.
The interesting bits are endless, but one of the most interesting things that popped out of this universe was the idea of "deanning". Basically, I tried to think of the weirdest, cleverest laws I could, and some of the privacy laws that emerged were very strange.
For example, you can take a picture of main street and post it on line without getting anyone's permission, without blurring faces, without any of that, because the people in the picture are anonymous.
What isn't legal is running face-scanning technology across that image to identify who these people are. This is de-anonymizing the data, or "deanning" it. Technically, while the deanning is illegal, it can't be enforced. Instead, only the propagation of deanned data is illegal. (More specifically, the propagation of any non-anonymous data without permission, regardless of whether it's been deanned or was never anonymized in the first place.) Data is considered non-anonymous if it reveals more of the person's personal information than the person expected to people they didn't intend. This is an objective statement, but a huge and growing number of guidelines exist in the courts to support it.
This has a huge number of implications, especially since propagation includes "feeding into data mining programs for purposes unrelated to the initial data".
So if you buy a bagel, the bagel shop can remember you bought a bagel. But they can't use the fact that you bought a bagel for non-you-buying-bagel purposes. They can't email you ads, they can't use your preferences in analysis of what bagels are best, they certainly can't sell your debit card info to another company. Not unless the data is properly anonymized. So they can say that their Washington Ave store sold a poppy seed bagel at 10:45 AM, but not who bought it.
It's pretty easy for anyone to save up a lot of vaguely related data and then dean it using basic pattern recognition tools. For example, if you record main street 24/7, you can easily start matching up individuals and determining their habits. Combined with a simple web trawl, you may be able to identify a significant number of people and their exact schedules.
This is illegal, but how would you enforce it? Especially since it's so easy to do with the mesh network: ten thousand man-in-the-middle attacks per message. Just save every bit of recognizable traffic. Analyze encryptions: you'll have gigabytes of data from the same source spooling by day after day, cracking it is just a matter of time and effort.
Well, the truth is that things get deanned all the time. You don't even have to run a thieving wifi router to get enough data to dean. You can dean from an internet search.
But using this information generally leaves a pretty clear trail. The same algorithms that can dean anonymous data can detect when a project or statement contains references to less-than-anonymous data. Individuals rarely have to worry about this in the same way pirates rarely worry about it. But companies have to worry, and have to be scrupulous.
This is especially dangerous to them because many of the wifi routers they depend on are run by untrusted sources who would love nothing better than to forward their illegal data to the police for a reward. It's not illegal to copy the information transferred through their router, not illegal to decrypt it, either, due to some anti-terrorism laws passed by the panicky government.
It's also not illegal to hack into devices, although it is illegal to use those hacked devices in an illegal manner (including data theft). This means that if you do dean data, you want to make sure you do it on an offline-only machine that can't be hacked remotely. Otherwise a hacker might forward that data to the police for that reward, get you thrown in jail.
Those are some of the basic rules, which actually make for a surprisingly interesting hacker game dynamic. There are a few things that may not occur to you at first read, though. Here are a few of those things:
Your friends can talk about you. This is called "implicit permission to dean". Where this permission ends is a rough concept and depends on what the individual has released publicly in the past.
Things you publish "publicly" that aren't intended for public use - for example, your mood on LiveJournal - are considered non-public data. The end user is not expected to always know exactly how every piece of software works, and therefore it is not the user that is held accountable, but the software and those that propagate the information for their own purposes.
So-called "shadow puppets" can be made. These are VR/AR avatars built out of real data fed to them. For example, feed your shadow puppet all the president's videos and speeches, and you have a shadow puppet that looks, talks, and acts like the president. This is almost always a dean even if you do it on public and non-anonymous data, because the shadow puppet can be made to act in a manner normally considered to be private and personal. For example, you can make your president puppet strip naked and dance the watusi. You can also release simulations of the president saying things he normally wouldn't say.
The law hasn't caught up to that extent, yet. Sometimes the infringements are allowed as parody, and sometimes the shadow puppet is waved off as not breaching privacy, but people are starting to crack down on the matter ever since a parody site began releasing pixel-perfect variants of Fox News shows.
"Virtual characters" have some very complex rights ever since the supreme court came down on the side of Disney to find that a shadow puppet of Mickey was not only a violation of trademark, but also a violation of "expected privacy on behalf of Mickey Mouse".
Anyway, the actual game is significantly more detailed (it's actually a bit too detailed for a tabletop game), but the laws about anonymizing and deanning were interesting enough I thought I'd talk about them on their own.
Subscribe to:
Posts (Atom)