I've been thinking about plot generation. There's a lot of difficulties with plot generation, and a lot of the solutions seem to involve hundreds or thousands of hours of work.
But what if instead of plot generation, we do emergent plot?
This is hardly new, but I think my idea is relatively fresh.
Most people, when they think of this kind of thing, they think of plots which adapt to the player's choices. For example, if the game lets you shoot someone important and can still ad-lib the plot convincingly, it's cool.
Sure, but that's not really emergent - it's just self-repairing and/or variable. Emergent implies that a complex situation comes together from a set of simple rules.
To some extent, self-story games feature emergent stories by using the player's drives and preferences as a catalyst. For example, in many tabletops or LARPs, players often decide that they want to experience a particular kind of story. They want to be the redeemed bad guy. They want to be the faithless clergyman. They want to experience a particular plot arc or just experience the world from a particular angle.
In a tabletop or a LARP, this works great because the game world adapts nimbly to these people. If one player is working through a redemption story and another is working through a challenge of faith story, they will tend to naturally harmonize with each other and prod the story along. The game world itself will change to facilitate this, if the GM is any good.
Basically, when you're building a story in a live game, you see kernels of opportunity in the game world and other players. Overtures to work these things into your personal story are usually successful, as the other players bend a little to work you into their story. When it works, it works wonderfully. It's an emergent narrative, and it's usually the most interesting part of any given game.
There's two problems with it.
First is the obvious problem: it relies on the adaptability of human beings. Computers have a much harder time adapting.
The second problem is much more insidious: these plots are fueled by in-game opportunities. It's become clearer and clearer that players think in terms of using what they are shown, not engineering new content. Even the players which are exceptions to this rule and think in terms of engineering new content and long-term plots are insufficient to do the task: they simply don't have the means to provide other players with opportunities that those players can latch on to.
Now, the first problem is a problem which faces computer games. The second problem is a problem which faces live games, but can be solved by computer games.
So, I'm going to concentrate on the first point: adaptability.
Usually, when I talk about a generative plot system, I talk about an incremental system. That means that a player is given a little bit of data, then makes a choice and is rewarded with another event and more data. These are not pre-planned chains of events. The path the player will follow is forged as the player walks it, but in such a way as to convince the player that they are in the midst of a complex and interesting plot.
The idea is that there is a kind of rules system for determining what kind of progressions there are. There may also be a kind of "guide" system which keeps the plot on track rather than letting it wander around at random - there are lots of ways to do it. It is, either way, a highly complex system.
So, I saw Raph's NPC post, right on the tail of his ecology posts. I didn't get any further than the first sentence: "In thinking about the UO resource system in recent posts (1, 2, 3), I also got to thinking about other things that we either wanted to or tried to get the NPCs to do."
(Yeah, I read it later, but the rest has only a little do to with this concept.)
I thought to myself, "hey, ecologies of NPCs have been tried before. In fact, I've tried them before. But there's a nugget of newness here, descended from Chu Chu Rocket and Carnage Heart."
So this is the "chu chu carnage" theory of emergent plot creation.
Imagine your NPCs are components on a 2D field. The Incredible Machine style - lots of weird kinds of components.
The basic idea is that the player can run around and tweak these components. The player can point them in a new direction, or change the color of their laser, or even move them if they are moveable components. This is pretty similar to the Incredible Machine in most ways, but it runs continuously instead of play-stop-rearrange.
It would be fun: the player would get to experiment with making components do fun combinations of things. Instead of a simple reward system, you make a really complex reward system. If you fire a green laser here, you get a bonus, sure. But you also get a bonus if you create a blue laser feedback loop or if you can pop fifteen balloons in three seconds. Instead of having all your goals as specific to a level, you have goals which are universal to all levels. Such as blue laser feedback loops: any level you get a blue feedback loop in, you get a bonus.
Of course, this is just an example. The real goals would be far simpler with far more complex results. For example, any laser feedback loop, but the color determines what kind of bonus you get.
Now, here's the other half of the equation: that TIM-like image is just what you see when you design the game. The player simply sees the city he is wandering around in, and talks to people. To him, our "blue laser" is "love" or something. If the game world is complex enough, we might allow the player to see the real logic map as well, as that way he could plot out his course. But I imagine that level of complexity is not needed.
The idea is that the player will be running around hooking people up or making people angry or whatever. Instead of having generic NPC AI systems which adapt to this, each NPC is a kind of "component" that deals with the various social stuff in relatively simple ways. Simple but malleable and adaptive - changing even without the player there to tweak it. For example, a common component might fire a blue laser at anyone who fires a blue laser at her. Or another person who fires a blue laser at everyone of the other gender within reach.
The rules governing the objects would be relatively simple and not something that can always be ruled by the player. For example, maybe that waffling component will only settle down when focused on by a single blue laser for some time, so the way the player gets the waffler to settle is by interfering with anyone else who wants to fire a blue laser at her.
Anyhow, the point is that you don't have a bunch of largely interchangeable NPCs. You have NPCs which are carefully placed and designed so that they have the potential to create a fun plot. I've used primarily romantic examples, but the same basic idea could apply to getting people to go hunt a dragon with you, or convincing thieves to rob a bank, or anything else. The idea is that the components are carefully placed so that there is a system-wide reaction when the player changes something significant, and that system-wide reaction is a plot.
What makes this different from a normal plot, aside from the difficulty of designing a level? Well, first, it gives the NPCs a feeling of being alive (if handled correctly). Second, when the situation gets complex, it allows the player to be innovative. For example, if the player knows the situation well, he can plan ahead and tweak a critical piece, causing a very different cascade than the one you originally planned for.
Also, you could allow players to have a lot of control over creating their own plots by "pushing pieces into place". Imagine a tactical game where the members of your team are these kinds of components, and the team itself has fun social dynamics. I think it would be a whole lot of fun to try to get the team socially working together.
I'll try to work out a more specific implementation soon, but I think this "chu chu carnage" social system could work really well. :)
Friday, June 09, 2006
Thursday, June 08, 2006
Fun with Perlin
It's been rainy for a week. Pardon the lack of energy.
I'm behind: I only heard about Perlin today.
What do I think? It's an idea. It's flawed as stated, but most ideas start flawed, and Perlin didn't state it - Ernest Adams did. So perhaps this should really be called "Adams' Corollary of Perlin's Law".
Perlin's law is good. Adams' corollary is a bit screwed up. My experiences in Nobilis tell me that there is no quicker way to break immersion than to attach numbers or costs to events. What he is essentially proposing is a "mana" to let you cast "spells" which break the game's reality in various fun ways. That's good for a game, but I don't think it's any kind of fundamental breakthrough.
The other problem, besides numbers, is the fact that you're breaking the foundation of a game's immersion with highly unlikely events. I don't think Perlin was talking about summoning chickens. I think he was talking about stumbling across clues to a kidnapping case. At most, he's talking about turning the corner and finding a chicken market.
There are a couple of other ideas which use the same principle without breaking immersion. For example, "for every action there is an equal and opposite reaction" would be fun. The more the player "spends" on unlikely actions, the more the computer can "spend" on unlikely actions. The player doesn't have to know how much he's spending. Of course, in this system, you still have to have a remarkable world engine to allow for such variability without forcing the player to carefully build whatever he's using.
Another idea is the "reality degredation" system, which is really a foundation to the rule itself. "The cost of an event in an interactive story should be directly proportional to its improbability." Well, obviously, once something happens, it's no longer nearly as improbable. Each time it happens, it gets more probable.
So, if a player does an unlikely action, it becomes cheaper for other players/AI to do equally unlikely actions. If the player wants to keep the game a serious real-world cop drama, he can. Or he can turn it into a melodramatic anime.
Also, world control could be given to a player, rather than an author, and the player could determine what is unlikely and what isn't, allowing for different "genres" of story fueled by one game engine...
But all of this is just silly chatter. These are not fundamental laws. They're just corollaries and fun gameplay dynamics.
The fundamental idea that Perlin is suggesting is that "the cost of an event in an interactive story should be directly proportional to its improbability."
I'm going to kick the tires.
I've written dozens of essays about player control, ranging from automatic adaptation to world set-up to game rules and on and on. To me, "cost of an event" isn't some kind of point value, it's the amount of attention a player needs to spend in order to even recognize that event as possible.
For example, a player is walking through a town. There is buried treasure in the town. The player finding that treasure is very unlikely. The longer the player spends in the town, the more people he talks to, and the more places he searches, the higher that probability becomes until, at some point, he finds the treasure.
Now, "that's a linear narrative! It's not generative!"
It could just as easily be applied to generative systems. For example, the player is passing through a city. The probability is very high that the city holds nothing of importance to him.
But every moment he dallies - every moment he talks to civilians ("Pro tip: talk to all townsfolk!") or breaks into someone's house - increases the chance that there's something important here. A "plot" event rather than simply idle conversation and breaking and entering.
Of course, to the player, this unfolds as: "You overhear the two men - they're talking about a pirate ship in the bay!" (Substitute cliche as you feel appropriate.)
To the engine, this is a progression: there's a lowish probability of providing a plot hook. Once you've provided a hook, there's a lowish probability of providing another plot hook based on the first. The longer that the player hangs out in "hooked" regions, the more times we "roll for hook deployment".
To the high-falutin' theory, this is simply "the cost of an event in an interactive story should be directly proportional to its improbability," where "cost" is defined as "player time/attention".
This has a downside of requiring you to write plots, or write something that can write plots. Of course, the downside to Adams' way is that you have to write something which allows the player to try to do anything with enough ease that players won't feel bogged down. Honestly, I don't know which is harder, but I've tried both and neither is easy.
I have some fun new ideas about those requirements, too, but not for this essay.
This essay is just a fun alternative to "cost" meaning "points".
I'm behind: I only heard about Perlin today.
What do I think? It's an idea. It's flawed as stated, but most ideas start flawed, and Perlin didn't state it - Ernest Adams did. So perhaps this should really be called "Adams' Corollary of Perlin's Law".
Perlin's law is good. Adams' corollary is a bit screwed up. My experiences in Nobilis tell me that there is no quicker way to break immersion than to attach numbers or costs to events. What he is essentially proposing is a "mana" to let you cast "spells" which break the game's reality in various fun ways. That's good for a game, but I don't think it's any kind of fundamental breakthrough.
The other problem, besides numbers, is the fact that you're breaking the foundation of a game's immersion with highly unlikely events. I don't think Perlin was talking about summoning chickens. I think he was talking about stumbling across clues to a kidnapping case. At most, he's talking about turning the corner and finding a chicken market.
There are a couple of other ideas which use the same principle without breaking immersion. For example, "for every action there is an equal and opposite reaction" would be fun. The more the player "spends" on unlikely actions, the more the computer can "spend" on unlikely actions. The player doesn't have to know how much he's spending. Of course, in this system, you still have to have a remarkable world engine to allow for such variability without forcing the player to carefully build whatever he's using.
Another idea is the "reality degredation" system, which is really a foundation to the rule itself. "The cost of an event in an interactive story should be directly proportional to its improbability." Well, obviously, once something happens, it's no longer nearly as improbable. Each time it happens, it gets more probable.
So, if a player does an unlikely action, it becomes cheaper for other players/AI to do equally unlikely actions. If the player wants to keep the game a serious real-world cop drama, he can. Or he can turn it into a melodramatic anime.
Also, world control could be given to a player, rather than an author, and the player could determine what is unlikely and what isn't, allowing for different "genres" of story fueled by one game engine...
But all of this is just silly chatter. These are not fundamental laws. They're just corollaries and fun gameplay dynamics.
The fundamental idea that Perlin is suggesting is that "the cost of an event in an interactive story should be directly proportional to its improbability."
I'm going to kick the tires.
I've written dozens of essays about player control, ranging from automatic adaptation to world set-up to game rules and on and on. To me, "cost of an event" isn't some kind of point value, it's the amount of attention a player needs to spend in order to even recognize that event as possible.
For example, a player is walking through a town. There is buried treasure in the town. The player finding that treasure is very unlikely. The longer the player spends in the town, the more people he talks to, and the more places he searches, the higher that probability becomes until, at some point, he finds the treasure.
Now, "that's a linear narrative! It's not generative!"
It could just as easily be applied to generative systems. For example, the player is passing through a city. The probability is very high that the city holds nothing of importance to him.
But every moment he dallies - every moment he talks to civilians ("Pro tip: talk to all townsfolk!") or breaks into someone's house - increases the chance that there's something important here. A "plot" event rather than simply idle conversation and breaking and entering.
Of course, to the player, this unfolds as: "You overhear the two men - they're talking about a pirate ship in the bay!" (Substitute cliche as you feel appropriate.)
To the engine, this is a progression: there's a lowish probability of providing a plot hook. Once you've provided a hook, there's a lowish probability of providing another plot hook based on the first. The longer that the player hangs out in "hooked" regions, the more times we "roll for hook deployment".
To the high-falutin' theory, this is simply "the cost of an event in an interactive story should be directly proportional to its improbability," where "cost" is defined as "player time/attention".
This has a downside of requiring you to write plots, or write something that can write plots. Of course, the downside to Adams' way is that you have to write something which allows the player to try to do anything with enough ease that players won't feel bogged down. Honestly, I don't know which is harder, but I've tried both and neither is easy.
I have some fun new ideas about those requirements, too, but not for this essay.
This essay is just a fun alternative to "cost" meaning "points".
Tuesday, June 06, 2006
Waitaminute...
It just hit me. This whole "6/6/6" thing, right? Well, the real number is theoretically 616, right?
That was my birthday!
My time is come! Muahaha!
Meh. Send your new overlord links to beautiful and interesting things.
That was my birthday!
My time is come! Muahaha!
Meh. Send your new overlord links to beautiful and interesting things.
China's so lovable...
This morning, an interesting piece of news popped up on my feeds. I can't remember what blog fed it to me, but here's an article that covers the same topic: China controls the rain!
Literally three hours later, I get fed another piece of news: southern China flooded, displacing a hundred thousand!
The fact that they claim to control the rain simultaneously with massive floods displacing so many leaves only two possible responses:
1) China's government is being stupid again, but at least this time it's at a hilariously ironic moment.
2) China's government should be held directly responsible for 29 deaths, tens of thousands of displacements, and tens of millions of dollars in damages and shortages.
As someone who loathes pseudoscience, I think we should hold China's government responsible! I think we should force them to take responsibility and apologize for their costly mistake! After all, they can control the weather, they should be held directly responsible for the things they let the weather do.
Sure, like any skeptic and most of the sentient humans, I know China can't actually control the weather on any useful level. But they claim they can, and people like this have been claiming such idiocies for thousands of years. It's about time their claims were held against them instead of only being brought into play when things happen to go right.
Literally three hours later, I get fed another piece of news: southern China flooded, displacing a hundred thousand!
The fact that they claim to control the rain simultaneously with massive floods displacing so many leaves only two possible responses:
1) China's government is being stupid again, but at least this time it's at a hilariously ironic moment.
2) China's government should be held directly responsible for 29 deaths, tens of thousands of displacements, and tens of millions of dollars in damages and shortages.
As someone who loathes pseudoscience, I think we should hold China's government responsible! I think we should force them to take responsibility and apologize for their costly mistake! After all, they can control the weather, they should be held directly responsible for the things they let the weather do.
Sure, like any skeptic and most of the sentient humans, I know China can't actually control the weather on any useful level. But they claim they can, and people like this have been claiming such idiocies for thousands of years. It's about time their claims were held against them instead of only being brought into play when things happen to go right.
Sunday, June 04, 2006
Metaprogramming and Slogging
For a few years now, I've wondered why I can program complex engines and full-sized business apps in the same amount of time it takes me to complete a relatively small game. It seems absurd. But I recently stopped and looked back over my code base. And now I know why.
I'm a "metaprogramming" specialist. This functionally means I try to turn anything I program into LISP.
This works really well for regular programs. By "regular" I mean "repeating" rather than "normal". Most business apps are just slight variations on a theme. So I build code which analyzes the situation and builds the necessary code, instead of manually programming it.
To be honest, I haven't worked on many tight programming teams: the teams I worked on tended to be of the "you do this part, he'll do this part" variety rather than the "let me see your code" variety. So, I was surprised to learn that many (most?) programmers manually write all these variations (often using cut and paste). This is perhaps the worst possible method to write the code. It's extremely difficult to make changes and prone to breaking in a heartbeat, in addition to simply taking longer.
Engines - simulations or game systems - are similar. They use a set of rules to determine the world state. Writing an interpreter which incorporates those rules is the same as writing a bunch of code which analyzes a database and produces a web page.
But programming a game is very different.
When I'm programming a game, I feel like I'm wading through mud. This is because I can't use many macros - there's very little outright repetition outside the engine itself. The art, the plot, the levels - they all need to be created manually. Programmed explicitly.
The end result is that I have the same amount of code, but I actually have to write all of it for a game. For a business app or engine, it literally writes itself.
Now that I'm into the level generation part of Kampaku, this is striking me more and more. Each level is something which has to be manually drawn and programmed in.
But that isn't the worst part. The worst part is that manual code and self-writing code have a ragged edge between them. Neither works as "smoothly" as it should, because when one side changes, the other side doesn't update properly. You end up with a lot of legacy code and wondering whether you should make the next mod as a macro or a manual bit.
(I've heard that programmers who stick entirely to manual code suffer from the same problem, so perhaps it's simply that manual code has ragged edges. Someone will have to tell me.)
Well, Kampaku is functional, but it's pulling up short. The manual code is simply too complex to allow me to add the social engine I want to include. In fact, the game probably isn't worth playing without the social engine.
I'm going to have to think for a day or two. I think I'm going to have to radically rethink my game programming methods, now that I know the trouble. I had good success with Machine City until I lost it, and it was almost entirely macros. Can I make every game almost entirely macros and custom domain languages?
Including content?
Heh. I can try.
I think I had better investigate Flash tomorrow. I wonder if it supports multiplayer games...
I'm a "metaprogramming" specialist. This functionally means I try to turn anything I program into LISP.
This works really well for regular programs. By "regular" I mean "repeating" rather than "normal". Most business apps are just slight variations on a theme. So I build code which analyzes the situation and builds the necessary code, instead of manually programming it.
To be honest, I haven't worked on many tight programming teams: the teams I worked on tended to be of the "you do this part, he'll do this part" variety rather than the "let me see your code" variety. So, I was surprised to learn that many (most?) programmers manually write all these variations (often using cut and paste). This is perhaps the worst possible method to write the code. It's extremely difficult to make changes and prone to breaking in a heartbeat, in addition to simply taking longer.
Engines - simulations or game systems - are similar. They use a set of rules to determine the world state. Writing an interpreter which incorporates those rules is the same as writing a bunch of code which analyzes a database and produces a web page.
But programming a game is very different.
When I'm programming a game, I feel like I'm wading through mud. This is because I can't use many macros - there's very little outright repetition outside the engine itself. The art, the plot, the levels - they all need to be created manually. Programmed explicitly.
The end result is that I have the same amount of code, but I actually have to write all of it for a game. For a business app or engine, it literally writes itself.
Now that I'm into the level generation part of Kampaku, this is striking me more and more. Each level is something which has to be manually drawn and programmed in.
But that isn't the worst part. The worst part is that manual code and self-writing code have a ragged edge between them. Neither works as "smoothly" as it should, because when one side changes, the other side doesn't update properly. You end up with a lot of legacy code and wondering whether you should make the next mod as a macro or a manual bit.
(I've heard that programmers who stick entirely to manual code suffer from the same problem, so perhaps it's simply that manual code has ragged edges. Someone will have to tell me.)
Well, Kampaku is functional, but it's pulling up short. The manual code is simply too complex to allow me to add the social engine I want to include. In fact, the game probably isn't worth playing without the social engine.
I'm going to have to think for a day or two. I think I'm going to have to radically rethink my game programming methods, now that I know the trouble. I had good success with Machine City until I lost it, and it was almost entirely macros. Can I make every game almost entirely macros and custom domain languages?
Including content?
Heh. I can try.
I think I had better investigate Flash tomorrow. I wonder if it supports multiplayer games...
Saturday, June 03, 2006
Yeaaaaaarrgggggh! Story time!
I just wrote a ten page essay. I won't torture you, but I think I can see now why people write books.
Instead of giving you a nice nap, I decided to cut out all of it except a challenge.
Of course, to get to the challenge, you have to sit through a page of detail...
My long-time readers might remember Livewire and Kung-Fu the Card Game the Role Playing Game (KFtCGtRPG). The challenge is to design a core mechanic which does what these games didn't quite manage. This is not an easy challenge. Here's more information.
KFtCGtRPG was a game based on kung-fu movies. You played with cards, a bit like Magic: the Gathering but more like Lunch Money. A fast-paced, light-hearted combat game where you gained experience to buy more stuff. It had a faulty negative feedback loop and no organization behind the plot/NPCs, but it was still a literal runaway success - the players started plotting against me to keep the game going.
The driving force in KFtCGtRPG was plot cards. I created a totally stereotypical kung-fu plot line, and made some 30 cards with snippets on them. Snippets like "The Iron Master uses only his legs" and "The Temple of the Unforgiven was raided four months ago".
The way I set it up, once you got a number of cards it started to all make sense. The plot was big enough that you had to have several of these "oh, I get it!" moments in order to really see what was going on.
I'm not just babbling, but now I'm going to go on another seeming tangent before bringing this whole thing together.
The other game, Livewire, was a vaguely similar game designed to run without a GM. It went exactly as I thought it would (meaning it died), but I gathered data from its death: it did not die in vain.
In this game, instead of having a master list of cards and a GM-built plot, the players got to make their own cards and plots.
The mechanic was fairly simple: every time you wanted to make a card, you had to have help from other players. The idea was to force players to get together and twist them into plots of their own devising.
I learned three very important things, which I'll just list quickly so that you can lust after an imaginary book. Or, I guess, I can lust after the book, and you can think I'm a shmuck.
1) Players need to be pulled into gamespace, and if it is multiplayer, they all need to be pulled into the gamespace.
2) Normally, history is lost as players leave the game, because most game histories are vocal. In a high-churn situation, this is unacceptable.
3) Very few players (<5%) have the capability to actively sustain a fantasy world. Most players will participate in a fantasy world, but not actively seek to produce or sustain a world. Most players who can sustain a fantasy world are control freaks and not suitable for sustaining a fantasy world heavily influenced by other players.
The last is what I'm going to limit myself to, even though the first two are equally interesting.
Almost all players are happy to participate in a fantasy universe, but there is a natural tendency for player-created universes to become either PvP or tightly controlled, depending on how much power the creator is given. Either way is unsuitable for most players, who want to be involved with other players but not in a way which risks anything.
Livewire actually did pretty well on that front, using a system of voluntary inclusions and requiring the use of other players in cooperative ventures.
However, Livewire's universe was... fragmented. There was no driving force, no overarching plot. This was mostly because plot couldn't be distributed: the networking was enough to make you touch a dozen other characters to get what you wanted done, but each of those other characters was only exposed to the tiny fragment of plot that you are working on them with (which was usually something on a lark, anyway).
On the other hand, KFtCGtRPG was exceedingly cohesive. This let the players (forced the players) to work together to conquer the universe or be defeated. It also allowed players to do whatever they wanted with their own characters - some had very nice plot arcs, and most had interesting moments, at least.
But, like Livewire, these were nearly impossible to share on a useful scale, and couldn't be interacted with by other players in any useful manner. They contributed to one player's enjoyment - and any nearby players who happened to be involved - but they didn't echo throughout the universe.
They should have.
How would you solve this problem?
Don't simply answer off the top of your head, please. This is an exceptionally complex issue. You have to make sure that a player's story can't be hijacked and, similarly, another player can't be forced into an irritating situation by that plot. But, the plot does need to be distributed. Not all players will actually see it, but they should all have the potential to see it, especially in parts of the game where they are not being exposed to much plot.
In addition, the plot has to allow for a high level of complexity. "Steve killed Bob" is not a plot. It's a blurb. The plot needs to be something that can be explored. "You discover a shattered sword. It has a red dragon on the hilt." Later, "Oh, Bob's symbol is a red dragon..." A slow unfolding of the plot is necessary to keep players emotionally interested.
Ha! And it has to be easy enough to do that more than 5% of the players will participate. Whether this is by automating it or simply making it extremely beneficial...
I have some ideas, but I'd like to hear yours.
Instead of giving you a nice nap, I decided to cut out all of it except a challenge.
Of course, to get to the challenge, you have to sit through a page of detail...
My long-time readers might remember Livewire and Kung-Fu the Card Game the Role Playing Game (KFtCGtRPG). The challenge is to design a core mechanic which does what these games didn't quite manage. This is not an easy challenge. Here's more information.
KFtCGtRPG was a game based on kung-fu movies. You played with cards, a bit like Magic: the Gathering but more like Lunch Money. A fast-paced, light-hearted combat game where you gained experience to buy more stuff. It had a faulty negative feedback loop and no organization behind the plot/NPCs, but it was still a literal runaway success - the players started plotting against me to keep the game going.
The driving force in KFtCGtRPG was plot cards. I created a totally stereotypical kung-fu plot line, and made some 30 cards with snippets on them. Snippets like "The Iron Master uses only his legs" and "The Temple of the Unforgiven was raided four months ago".
The way I set it up, once you got a number of cards it started to all make sense. The plot was big enough that you had to have several of these "oh, I get it!" moments in order to really see what was going on.
I'm not just babbling, but now I'm going to go on another seeming tangent before bringing this whole thing together.
The other game, Livewire, was a vaguely similar game designed to run without a GM. It went exactly as I thought it would (meaning it died), but I gathered data from its death: it did not die in vain.
In this game, instead of having a master list of cards and a GM-built plot, the players got to make their own cards and plots.
The mechanic was fairly simple: every time you wanted to make a card, you had to have help from other players. The idea was to force players to get together and twist them into plots of their own devising.
I learned three very important things, which I'll just list quickly so that you can lust after an imaginary book. Or, I guess, I can lust after the book, and you can think I'm a shmuck.
1) Players need to be pulled into gamespace, and if it is multiplayer, they all need to be pulled into the gamespace.
2) Normally, history is lost as players leave the game, because most game histories are vocal. In a high-churn situation, this is unacceptable.
3) Very few players (<5%) have the capability to actively sustain a fantasy world. Most players will participate in a fantasy world, but not actively seek to produce or sustain a world. Most players who can sustain a fantasy world are control freaks and not suitable for sustaining a fantasy world heavily influenced by other players.
The last is what I'm going to limit myself to, even though the first two are equally interesting.
Almost all players are happy to participate in a fantasy universe, but there is a natural tendency for player-created universes to become either PvP or tightly controlled, depending on how much power the creator is given. Either way is unsuitable for most players, who want to be involved with other players but not in a way which risks anything.
Livewire actually did pretty well on that front, using a system of voluntary inclusions and requiring the use of other players in cooperative ventures.
However, Livewire's universe was... fragmented. There was no driving force, no overarching plot. This was mostly because plot couldn't be distributed: the networking was enough to make you touch a dozen other characters to get what you wanted done, but each of those other characters was only exposed to the tiny fragment of plot that you are working on them with (which was usually something on a lark, anyway).
On the other hand, KFtCGtRPG was exceedingly cohesive. This let the players (forced the players) to work together to conquer the universe or be defeated. It also allowed players to do whatever they wanted with their own characters - some had very nice plot arcs, and most had interesting moments, at least.
But, like Livewire, these were nearly impossible to share on a useful scale, and couldn't be interacted with by other players in any useful manner. They contributed to one player's enjoyment - and any nearby players who happened to be involved - but they didn't echo throughout the universe.
They should have.
How would you solve this problem?
Don't simply answer off the top of your head, please. This is an exceptionally complex issue. You have to make sure that a player's story can't be hijacked and, similarly, another player can't be forced into an irritating situation by that plot. But, the plot does need to be distributed. Not all players will actually see it, but they should all have the potential to see it, especially in parts of the game where they are not being exposed to much plot.
In addition, the plot has to allow for a high level of complexity. "Steve killed Bob" is not a plot. It's a blurb. The plot needs to be something that can be explored. "You discover a shattered sword. It has a red dragon on the hilt." Later, "Oh, Bob's symbol is a red dragon..." A slow unfolding of the plot is necessary to keep players emotionally interested.
Ha! And it has to be easy enough to do that more than 5% of the players will participate. Whether this is by automating it or simply making it extremely beneficial...
I have some ideas, but I'd like to hear yours.
Friday, June 02, 2006
Journey into the Amazon
(This is a repost, if you see it twice, sorry. This one has comments enabled. The other one, for reasons beyond me, did not.)
I made a post about Pandora's song selection methods, and it was pointed out that Amazon does something similar to what I suggested.
Let me explain what Amazon does, first, then explain the differences.
Imagine that for each book it offers, Amazon puts a circle on a page. Whenever anyone buys a book, Amazon draws a line from all the books they bought before to that book.
So, if five people buy "Zozo's Tea Adventures" and "Pandas on Iceskates Photo Album", then there are five lines between the two.
Now, if someone buys (or adds to their wishlist) one of these books, Amazon sees what other books it is connected to by the most lines and recommends them.
In fact, you can see this in action: if you go to your Amazon recommendations page, each recommendation has a definite source. So, when you buy "Zozo's Tea Adventures", Amazon would recommend "Pandas on Iceskates" and specifically tell you it was because you bought "Zozo's Tea Adventures".
Of course, if "Pandas on Iceskates" had five lines and "Teabags from Hell" was connected by fifty, Amazon would recommend "Teabags from Hell" rather than "Pandas on Iceskates".
This works okay, but its primary strong point is simplicity.
It has a few major flaws.
One of the flaws I continually run into is that I buy books to research a specific topic, and then Amazon insists that I'm interested in that topic forever. For example, I did some research into the Steampunk genre. Now half my recommendations are for Steampunk books, even though I haven't bought any (or shown any interest in them) for more than six months.
This is relatively easy to fix: every time you visit your recommendations page and don't buy anything, it counts as a strike against that particular network. Since I've visited my recommendations page half a dozen times and never even clicked on a link to Steampunk books, it should realize that those carrots aren't catching me, and move on to offering different carrots.
A dramatically worse flaw is the "mob rule" mentality that these links provide.
For example, there are evidently ten million people who simply buy everything on the New York Times' best seller list. So, when I buy a book which happens to be on it, I get suggestions that I should buy other NYT BS. After all, everyone else buys them.
Of course, my only interest in these other books is to mock them. "YOU: The Owner's Manual" is just about the polar opposite of something I would buy.
Sure, when I look at the recommendations, I see, "yeah, those are popular because they are connected to these." That's fine, but it's not: "Oh, that book looks interesting." It doesn't sell me any books. No money goes to Amazon for these recommendations.
Okay, sure, it pleases the majority to some extent. But to what extent? How often does someone buy something Amazon recommended? I doubt more than 1% of their sales come from recommendations.
Because even the ultimate generic customers have niche interests and different purchase patterns.
So, what I recommended for a Pandora-like system, I'll now recommend for an Amazon-like system.
In Amazon's case, it's really simple.
Make recommendations additive.
I bought Freakonomics and Blink. Amazon passes recommendations on that are echoed from the two of those. However, the connections from Freakonomics run off into bestseller land, and the connections from Blink seem to run off into crazed lunatic land.
Presumably, the two networks touch. It would be hard to believe that I'm the only person who's bought both of these books. In fact, chances are very high that the networks are intermingled in several locations.
Books which are connected to more than one of my purchases should be suggested more often - depending on the strengths and disparities of the connections.
For example, if Blink and Freakonomics are very tightly connected, then it's not very useful to try and triangulate what books I'm likely to like from those two. But if I buy, say, Freakonomics and "Cloud Captains of Mars", those are disparate enough that triangulated books are probably quite interesting to me. (Well, no, actually, because "Cloud Captains" was for research purposes, but add in what I talked about earlier...)
This might be kind of hard to see, so let me explain:
I might be the only person who bought "Cloud Captains of Mars" and Freakonomics. However, someone else bought books close to those books. Say, someone bought "The Undercover Economist" and "GURPS Steam-Tech". Those books are tightly connected to Freakonomics and "Cloud Captains" by other purchasers who have a general interest in those areas.
Therefore, there is a networked superstructure; a chain running from "Cloud Captains" to Freakonomics via user preference.
Now, you could even go better than this by "color coding" your links based on their sprawl areas. For example, if a huge number of people buy five particular books, those five books are linked very strongly. But chances are that many other people won't want to by the other four when they buy one. So you "color code" the most common links and then do a few suggestions to see whether the buyer in question is part of that "color".
For example, the NYT BS list. Chances are, they are all heavily linked. But those links should all be considered "one subnet". I have no interest in that subnet, so this super-Amazon should ignore those links when it comes to determining what books I'll like.
Clear?
Edit: Amusingly, Amazon sent me a new recommendation as I was typing this. It's for "Artificial Intelligence for Games" - a topic in which I'm very much interested. I don't much care for what I see of the book, but at least the topic was right.
The reason for this success is that this is such a niche audience that there is only one "color" of line connecting these books. So, functionally, it's as if, for this tiny little section of the network, they were running with the method I explained above.
I made a post about Pandora's song selection methods, and it was pointed out that Amazon does something similar to what I suggested.
Let me explain what Amazon does, first, then explain the differences.
Imagine that for each book it offers, Amazon puts a circle on a page. Whenever anyone buys a book, Amazon draws a line from all the books they bought before to that book.
So, if five people buy "Zozo's Tea Adventures" and "Pandas on Iceskates Photo Album", then there are five lines between the two.
Now, if someone buys (or adds to their wishlist) one of these books, Amazon sees what other books it is connected to by the most lines and recommends them.
In fact, you can see this in action: if you go to your Amazon recommendations page, each recommendation has a definite source. So, when you buy "Zozo's Tea Adventures", Amazon would recommend "Pandas on Iceskates" and specifically tell you it was because you bought "Zozo's Tea Adventures".
Of course, if "Pandas on Iceskates" had five lines and "Teabags from Hell" was connected by fifty, Amazon would recommend "Teabags from Hell" rather than "Pandas on Iceskates".
This works okay, but its primary strong point is simplicity.
It has a few major flaws.
One of the flaws I continually run into is that I buy books to research a specific topic, and then Amazon insists that I'm interested in that topic forever. For example, I did some research into the Steampunk genre. Now half my recommendations are for Steampunk books, even though I haven't bought any (or shown any interest in them) for more than six months.
This is relatively easy to fix: every time you visit your recommendations page and don't buy anything, it counts as a strike against that particular network. Since I've visited my recommendations page half a dozen times and never even clicked on a link to Steampunk books, it should realize that those carrots aren't catching me, and move on to offering different carrots.
A dramatically worse flaw is the "mob rule" mentality that these links provide.
For example, there are evidently ten million people who simply buy everything on the New York Times' best seller list. So, when I buy a book which happens to be on it, I get suggestions that I should buy other NYT BS. After all, everyone else buys them.
Of course, my only interest in these other books is to mock them. "YOU: The Owner's Manual" is just about the polar opposite of something I would buy.
Sure, when I look at the recommendations, I see, "yeah, those are popular because they are connected to these." That's fine, but it's not: "Oh, that book looks interesting." It doesn't sell me any books. No money goes to Amazon for these recommendations.
Okay, sure, it pleases the majority to some extent. But to what extent? How often does someone buy something Amazon recommended? I doubt more than 1% of their sales come from recommendations.
Because even the ultimate generic customers have niche interests and different purchase patterns.
So, what I recommended for a Pandora-like system, I'll now recommend for an Amazon-like system.
In Amazon's case, it's really simple.
Make recommendations additive.
I bought Freakonomics and Blink. Amazon passes recommendations on that are echoed from the two of those. However, the connections from Freakonomics run off into bestseller land, and the connections from Blink seem to run off into crazed lunatic land.
Presumably, the two networks touch. It would be hard to believe that I'm the only person who's bought both of these books. In fact, chances are very high that the networks are intermingled in several locations.
Books which are connected to more than one of my purchases should be suggested more often - depending on the strengths and disparities of the connections.
For example, if Blink and Freakonomics are very tightly connected, then it's not very useful to try and triangulate what books I'm likely to like from those two. But if I buy, say, Freakonomics and "Cloud Captains of Mars", those are disparate enough that triangulated books are probably quite interesting to me. (Well, no, actually, because "Cloud Captains" was for research purposes, but add in what I talked about earlier...)
This might be kind of hard to see, so let me explain:
I might be the only person who bought "Cloud Captains of Mars" and Freakonomics. However, someone else bought books close to those books. Say, someone bought "The Undercover Economist" and "GURPS Steam-Tech". Those books are tightly connected to Freakonomics and "Cloud Captains" by other purchasers who have a general interest in those areas.
Therefore, there is a networked superstructure; a chain running from "Cloud Captains" to Freakonomics via user preference.
Now, you could even go better than this by "color coding" your links based on their sprawl areas. For example, if a huge number of people buy five particular books, those five books are linked very strongly. But chances are that many other people won't want to by the other four when they buy one. So you "color code" the most common links and then do a few suggestions to see whether the buyer in question is part of that "color".
For example, the NYT BS list. Chances are, they are all heavily linked. But those links should all be considered "one subnet". I have no interest in that subnet, so this super-Amazon should ignore those links when it comes to determining what books I'll like.
Clear?
Edit: Amusingly, Amazon sent me a new recommendation as I was typing this. It's for "Artificial Intelligence for Games" - a topic in which I'm very much interested. I don't much care for what I see of the book, but at least the topic was right.
The reason for this success is that this is such a niche audience that there is only one "color" of line connecting these books. So, functionally, it's as if, for this tiny little section of the network, they were running with the method I explained above.
Subscribe to:
Posts (Atom)