News:

Forum changes: Editing of posts has been turned off until further notice.

Main Menu

Event Driven Adventure Design

Started by Kedamono, January 25, 2005, 03:14:39 AM

Previous topic - Next topic

NN

Clerich, was the problem that the campaign was set up to be

"Stop the Villain taking over the Universe"

when it would have been better if it had been

"The Villain is expanding his Evil Empire: you guys can make a difference as to where the frontline is"

clehrich

Quote from: NNClerich, was the problem that the campaign was set up to be

"Stop the Villain taking over the Universe"

when it would have been better if it had been

"The Villain is expanding his Evil Empire: you guys can make a difference as to where the frontline is"
Well, bit of both, really.  But we're getting afield, I think.  Unless Kedamono wants me to go on with the example....
Chris Lehrich

Kedamono

Quote from: clehrich
Quote from: NNClerich, was the problem that the campaign was set up to be

"Stop the Villain taking over the Universe"

when it would have been better if it had been

"The Villain is expanding his Evil Empire: you guys can make a difference as to where the frontline is"
Well, bit of both, really.  But we're getting afield, I think.  Unless Kedamono wants me to go on with the example....

You don't have to if you don't want to Chris. You have a valid point in that without a "good hook" the PCs will tend to wander off the trail you're trying to lead them along.

I need a chance to sit down and think through all the information everyone has provided in this thread and refine if not redefine what an Event-Driven Adventure is.

Oh, and Chris, you were being railroaded by that GM of yours, only, his train made frequent stops and allowed you to wander far from the train, only to have the Conductor show up and shoo you back on board the train...

Whenever there is a "Correct" way to play a scenario and end up at the predefined endpoint, it's a railroad.
The Kedamono Dragon
AKA John Reiher

shlo

@Kedamono:
Two last things before you sit down  =)

EDA definition
When I design a scenario -- with event design as use it, scene to scene -- I first define a condition for the event to happen, then I write the description of the event as it could be. If the condition is "D+2, 8h20pm" it's exactly like the timing in your EDA, but I could use "When the PC enter the warehouse" too, or "When the PC are resting, between D+1 and D+3", or "When the pace drops down because the PC have no clue", or whatever. Branches are just a new batch of events, so if ever I want some, I write some.

Without your two restrictions that "condition" is a date and time and that there are multiple branches, the definition of EDA could be larger, and then have some specializations like time driven, NPC driven, PC driven, with or without branches... with reflections on the flaws and advantages of each method. IMO you're focusing on a specialization of the larger Event Design method, that's why I suggested sooner a more accurate term.

Branching
About the example with the bad guys trying to grab some explosives: you design two events, 2a and 2b. Can the PC stop them from taking explosives or not? If they cannot, I don't think having two or more events will extend their "free will" sensation in any way, in comparison with single branch event design. If they can, the scenario is over after 30 min, and the players I know would be frustrated. Do the NPC need mutiple ways to do things? I don't think so. IMO the use of multiple branches should be used to define multiple PC's ways, like in Clue Trees, not to let the story happen whatever the PC do.

But I'm still not a branches fan since I think it leads the PC to confusion. Give them three clues and they want to use all of them, wasting time exploring each branch, separating in multiple groups, and possibly get lost since the profusion of clues may tell a different story.

Kedamono

Quote from: shlo on January 31, 2005, 10:09:29 AM
@Kedamono:
Two last things before you sit down  =)

EDA definition
When I design a scenario -- with event design as use it, scene to scene -- I first define a condition for the event to happen, then I write the description of the event as it could be. If the condition is "D+2, 8h20pm" it's exactly like the timing in your EDA, but I could use "When the PC enter the warehouse" too, or "When the PC are resting, between D+1 and D+3", or "When the pace drops down because the PC have no clue", or whatever. Branches are just a new batch of events, so if ever I want some, I write some.

Without your two restrictions that "condition" is a date and time and that there are multiple branches, the definition of EDA could be larger, and then have some specializations like time driven, NPC driven, PC driven, with or without branches... with reflections on the flaws and advantages of each method. IMO you're focusing on a specialization of the larger Event Design method, that's why I suggested sooner a more accurate term.

I've been letting this concept ferment for a while and you're quite right, limiting EDA to just the Timeline Driven model is me carefully building a fence about myself. EDA has many modes and covers a large number of event driven designs. The most basic is the Linear Adventure were there is no branching whatsoever. The most complex is a conditional branching design you see in some CRPGs and is typically used naturally by many GMs running a game. Your definition and examples is this style of EDA.

And example of the basic event branching design is the Choose-Your-Own-Path books, were there is a good path and many, many bad paths. I dislike them, since you can play them randomly and do a drunkards walk through the game.

I prefer the "no bad paths" branching design, where the choices lead the PCs down different paths with different endings. And the endings are what they make of them. There is the tendency for the last event to be the Big Boss Battle, which is OK for hack and slash games or Tournament games at cons, but for campaign play, the boss battle is often unsatisfying, especially when the GM or designer woefully underestimated the abilities of the PCs and the ingenuity of the players.

QuoteBranching
About the example with the bad guys trying to grab some explosives: you design two events, 2a and 2b. Can the PC stop them from taking explosives or not? If they cannot, I don't think having two or more events will extend their "free will" sensation in any way, in comparison with single branch event design. If they can, the scenario is over after 30 min, and the players I know would be frustrated. Do the NPC need mutiple ways to do things? I don't think so. IMO the use of multiple branches should be used to define multiple PC's ways, like in Clue Trees, not to let the story happen whatever the PC do.

The example I gave was a bit off the top of my head, but if I had time to properly work it out, I would allow the PCs to stop the bad guys from getting the explosives. However that would not stymie the bad guys, who would have a plan B or even C in reserve. The other way is to have two events happening almost at the same time and the players have to decide to divide their forces or do one of the events and let the other happen.

QuoteBut I'm still not a branches fan since I think it leads the PC to confusion. Give them three clues and they want to use all of them, wasting time exploring each branch, separating in multiple groups, and possibly get lost since the profusion of clues may tell a different story.

That is a problem, that really depends on group dynamics. I've been in games where splitting up was frowned upon the team leaders, and other games where the GM had a headache trying to deal with four groups going off in different directions.
The Kedamono Dragon
AKA John Reiher