Creating an Interactive Story
by Kevin McLaughlin · 10/31/2007 (4:42 pm) · 1 comments
I don't usually just repost these blogs from my weekly blog. But - I had an especially pertinent post on Saturday, and I thought there might actually be interest in reading it! If you want more background on this post, go read the full blog at http://roleplayersworld.wordpress.com
Thanks for reading, comments welcome, and enjoy!
********
There's a lot of garbage that has been written about the theory of interactive story in an online game. Garbage, because most of it is useless theoretical crap. Theoretical, because no one has done it yet. Not in a graphical game, anyway. That's a serious problem, because it means that interactive online storytelling is essentially an unfounded medium of communication, something that has no easy templates or examples to draw from.
There have been some failed stabs at it in the past, of course. Asheron Call 1 had an ongoing monthly "story" that in theory players could affect but in practice was simply patched in the same on every server regardless of whether players had done anything to progress the story or not. The story there was backdrop, not core. It was not interactive, because it progressed in the same way regardless of player action. Shadowbane briefly tried some GM-driven storyline events, but these again tended to be brief and without lasting impact. Players who happened to be online got to go see the event, kill some mobs (or players!) maybe get a cool item, and that was it. The results of the event really never changed anything in the world. Eve Online and other games have introduced what I would call "ongoing backstory". As the months go on, new backstory is introduced, talking about the changes in the world around you. Again though, this backstory rarely has any impact on the players. It's flavor, designed to make the patches more interesting and explain away any oddities added in a patch.
Wish was probably the closest thing to my goal ever to be attempted. Wish intended to have no senselessly repeating quests, for instance; all quests would either be one shot deals, or would repeat because it was logical they do so. Dungeons would not automatically respawn; a GM would have to reinitialize a dungeon with new critters based around some new story sequence - "reinhabit" it, so to speak. Story would be driven by a collaboration between players and GMs, with GMs presenting challenges and players responding to those challenges with their actions, which in turn let the GMs develop the future chapters of the story. Wish sounded like a truly wonderful idea.
Wish was cancelled in beta due to unforseen difficulties with production. Go figure, eh? ;)
There are other examples of failed or halfhearted attempts, but essentially any sort of real interactive storytelling in an MMORPG is breaking new ground. So, with no strong examples to build on, the best bet seems to be to work from the failed attempts of others, and try to see where they went wrong.
The system I am roughing out is a mesh of some of the concepts of Asheron's Call, melded with some of the flexibility planned for Wish. AC ran updates with fixed, preplanned content. This was necessary because the game used a multiple-shard setup. The same content needed to be patched to every server every time. As a result, player action could never determine the content being patched, because divergence between server storylines was not allowed to happen. A single-shard approach is not vital to a story based game, but it helps. Multiple servers would mean generating, tracking, and doing all the work to create content for multiple storylines, since divergence is almost certain. My intent was always to run a single shard, at least at the outset, so this part is easy.
AC1's patches were not frequent enough to be reactive, however. Monthly patches don't occur often enough to be seen as responding to player actions. It's too easy to disassociate the patched changes from the actions the players did that caused them when there is a 2-4 week lag between the two. A faster update pace is required. Wish was the flip side of this coin, with GMs constantly spinning out new content in the form of quests, spawns, and such on an hourly basis around the clock. This undoubtably proved very time intensive, and it seems likely that the projected man-hours required contributed heavily to the cancellation of the game. So we need fast updates, but not as fast as Wish had in mind. We need content that responds to players, but not in a pre-scripted manner, since that would seem artificial.
The best answer I have come up with so far seems to be a threshold system. Storylines will be scattered through the game world, with various thresholds tracked by the server. For instance, if a certain critter infests an old mine, and players can recover the mine, then after a certain threshold of clearing activity, a flag will go up, and the GMs will patch the next segment in that story. That area might have a deeper dungeon at the bottom of it which now needs exploring. The critters might have moved, but where did they go and what trouble will they cause now? These sorts of continuations of the story can be patched as soon as the players have hit the critical trigger level. You can think of these threshold points as "turn the page" events which act as flags to tell the GMs to move the story along.
Comlpexity can be added as well. If there is a threshold for heavy player victory against the critters, what happens if the players ignore them completely? Do they just stay there, or would a threshold event be added for a certain level of non-interference? This can easily be a graduated scale; a point value which slowly moves up if they are not interfered with, and moves down whenever their lair is invaded. If the point scale goes high enough, they might grow bold, raiding farms nearby, attracting stronger allies, or otherwise becoming a bigger menace.
Further complexity can be added by mixing the thresholds. Undead infest the ruins of a nearby keep. The little goblinlike critters have always coveted those ruins, but are afraid of the undead. If players clear the ruins, the critters might move in to replace the undead - if the critter point scale is high enough. If they've been raided a bit, they might be more inclined to dig in. If they've been raided a lot, and want a new home though, they might head for the ruins anyway. And who knows what sorts of trouble small burrowing critters can turn up at an ancient ruin?
I'm sure you get the idea now. By introducing myriad small "turn the page" events, the GMs can be flagged when a particular storyline has been affected by the players enough to move it to the next chapter. By knowing in advance the possible outcomes, GMs can prep the content needed to quickly apply the patches required for any new story segment. The overall system is still rough, and I'd welcome other thoughts on the subject. But it looks to me like it is a system which should work - providing ongoing interactive stories in a manageable manner.
Thanks for reading, comments welcome, and enjoy!
********
There's a lot of garbage that has been written about the theory of interactive story in an online game. Garbage, because most of it is useless theoretical crap. Theoretical, because no one has done it yet. Not in a graphical game, anyway. That's a serious problem, because it means that interactive online storytelling is essentially an unfounded medium of communication, something that has no easy templates or examples to draw from.
There have been some failed stabs at it in the past, of course. Asheron Call 1 had an ongoing monthly "story" that in theory players could affect but in practice was simply patched in the same on every server regardless of whether players had done anything to progress the story or not. The story there was backdrop, not core. It was not interactive, because it progressed in the same way regardless of player action. Shadowbane briefly tried some GM-driven storyline events, but these again tended to be brief and without lasting impact. Players who happened to be online got to go see the event, kill some mobs (or players!) maybe get a cool item, and that was it. The results of the event really never changed anything in the world. Eve Online and other games have introduced what I would call "ongoing backstory". As the months go on, new backstory is introduced, talking about the changes in the world around you. Again though, this backstory rarely has any impact on the players. It's flavor, designed to make the patches more interesting and explain away any oddities added in a patch.
Wish was probably the closest thing to my goal ever to be attempted. Wish intended to have no senselessly repeating quests, for instance; all quests would either be one shot deals, or would repeat because it was logical they do so. Dungeons would not automatically respawn; a GM would have to reinitialize a dungeon with new critters based around some new story sequence - "reinhabit" it, so to speak. Story would be driven by a collaboration between players and GMs, with GMs presenting challenges and players responding to those challenges with their actions, which in turn let the GMs develop the future chapters of the story. Wish sounded like a truly wonderful idea.
Wish was cancelled in beta due to unforseen difficulties with production. Go figure, eh? ;)
There are other examples of failed or halfhearted attempts, but essentially any sort of real interactive storytelling in an MMORPG is breaking new ground. So, with no strong examples to build on, the best bet seems to be to work from the failed attempts of others, and try to see where they went wrong.
The system I am roughing out is a mesh of some of the concepts of Asheron's Call, melded with some of the flexibility planned for Wish. AC ran updates with fixed, preplanned content. This was necessary because the game used a multiple-shard setup. The same content needed to be patched to every server every time. As a result, player action could never determine the content being patched, because divergence between server storylines was not allowed to happen. A single-shard approach is not vital to a story based game, but it helps. Multiple servers would mean generating, tracking, and doing all the work to create content for multiple storylines, since divergence is almost certain. My intent was always to run a single shard, at least at the outset, so this part is easy.
AC1's patches were not frequent enough to be reactive, however. Monthly patches don't occur often enough to be seen as responding to player actions. It's too easy to disassociate the patched changes from the actions the players did that caused them when there is a 2-4 week lag between the two. A faster update pace is required. Wish was the flip side of this coin, with GMs constantly spinning out new content in the form of quests, spawns, and such on an hourly basis around the clock. This undoubtably proved very time intensive, and it seems likely that the projected man-hours required contributed heavily to the cancellation of the game. So we need fast updates, but not as fast as Wish had in mind. We need content that responds to players, but not in a pre-scripted manner, since that would seem artificial.
The best answer I have come up with so far seems to be a threshold system. Storylines will be scattered through the game world, with various thresholds tracked by the server. For instance, if a certain critter infests an old mine, and players can recover the mine, then after a certain threshold of clearing activity, a flag will go up, and the GMs will patch the next segment in that story. That area might have a deeper dungeon at the bottom of it which now needs exploring. The critters might have moved, but where did they go and what trouble will they cause now? These sorts of continuations of the story can be patched as soon as the players have hit the critical trigger level. You can think of these threshold points as "turn the page" events which act as flags to tell the GMs to move the story along.
Comlpexity can be added as well. If there is a threshold for heavy player victory against the critters, what happens if the players ignore them completely? Do they just stay there, or would a threshold event be added for a certain level of non-interference? This can easily be a graduated scale; a point value which slowly moves up if they are not interfered with, and moves down whenever their lair is invaded. If the point scale goes high enough, they might grow bold, raiding farms nearby, attracting stronger allies, or otherwise becoming a bigger menace.
Further complexity can be added by mixing the thresholds. Undead infest the ruins of a nearby keep. The little goblinlike critters have always coveted those ruins, but are afraid of the undead. If players clear the ruins, the critters might move in to replace the undead - if the critter point scale is high enough. If they've been raided a bit, they might be more inclined to dig in. If they've been raided a lot, and want a new home though, they might head for the ruins anyway. And who knows what sorts of trouble small burrowing critters can turn up at an ancient ruin?
I'm sure you get the idea now. By introducing myriad small "turn the page" events, the GMs can be flagged when a particular storyline has been affected by the players enough to move it to the next chapter. By knowing in advance the possible outcomes, GMs can prep the content needed to quickly apply the patches required for any new story segment. The overall system is still rough, and I'd welcome other thoughts on the subject. But it looks to me like it is a system which should work - providing ongoing interactive stories in a manageable manner.
Associate Ross Pawley
If the players ignore the growing population of goblins, soon there will be goblins all over the place, and not much can be done. On the flip side, if the players kill all the goblins, something else must happen or those areas might be totally empty. Such things might be mitigated to some extent by having GMs manually provide the reactions to such stimuli, but that brings up the issue of large amount of man-hours to get anything done (i.e., same problem as Wish). For a large world, you'd either need a large staff (possibly 2-3 people dedicated per area) or very limited updates (which brings up the problem of players feeling like they don't affect the world). Not to mention that such a system would be complex and hugely interconnected, which brings up engineering difficulties in general.
It's an interesting problem and one I've thought about for some time, but honestly I think it *could* be done. One thing I think would/could help to preserve a base line of playability is to dynamically assign players quests based on the needs of the simulated ecosystem by giving them competing goals.
To expand on the running examples, let's say the goblin population bloomed due to people ignoring them. Well, you might give player A some sort of mission to eradicate parts of their food supply, while player B could be given a competing goal of helping the goblins take over new resources. In this way, the effects of players ignoring issues could be mitigated to some degree while preserving playability. Said quests might have a better payout than your typical "Run here and get X, and return it to me." quests. Or even just the simple task of "exterminate the goblins". That brings up the problem of how to define when such missions should be dispatched, and who to dispatch to.