BeanPole Campaign, Episode One
The BeanPole Campaign is a thirteen episode content set for GearHead2 which should provide a complete and uninterrupable core story. The campaign is designed so that it should be compatible with any character type, and does not depend upon any specific factions or locations. It tells the story of the PC’s rivalry with an enemy pilot; in the first episode, the PC learns of this enemy but does not actually meet them.
This is how the first episode is structured:
Give Mission: Find and Defeat Raiders
*Combat Encounter: learn of enemy leader
*Gain Advantage: Possibly gain reinforcements for above combat
*Reveal Encounter: Meet rowdy raider in town
Track Raider: Defeat henchmen, follow above raider to base
Win Mission
Lose Mission
Each line represents a separate subplot. Before going on, let me explain how plots and subplots work in GH2: plots are constructed from multiple subplots. Originally, only one subplot could be active at any given time. As of v0.504, it’s possible for a plot to have multiple narrative threads, each with their own active subplot. This means that it’s possible to have several different things happening at the same time. In the above chart, subplots which begin their own narrative threads are marked with an asterisk (*).
I’ll walk you through the events. The player is given a mission to locate and destroy some raiders. When the player accepts the mission, two threads are activated- the Combat Encounter and also Reveal Encounter. Upon being activated the Combat Encounter activates Gain Advantage. The player will first need to locate the raiders- the rumor from the Reveal Encounter thread will lead him to a public building in town. He may also hear the rumor that someone else is looking for the raiders, and may be able to gain some backup for the Combat Encounter. These two tasks may be done in either order.
In the Reveal Encounter thread, there are multiple ways for the PC to learn the location of the Combat Encounter from the rowdy raider. If the PC doesn’t manage to do this before the raider moves on, the Track Raider subplot is activated. Now the PC will have to find the raider’s lance and defeat his henchmen quickly in order to follow the raider back to the Combat Encounter.
Once the Combat Encounter has been revealed, the PC will be able to go there and face the entire crew of raiders. If he obtained backup from the Gain Advantage thread those mecha will be here to meet him. The Combat Encounter is a fairly tough fight- 150% more mecha then a regular encounter. Upon either winning or losing the encounter, the Give Mission thread will activate either Win Mission or Lose Mission.
Note that although in this example the Combat Encounter is generated by a Give Mission subplot, this need not be the case. Any other series of events which would lead to the PC seeking out the raiders would have worked just as well. Combat Encounters such as this one are to be the basic building block of the core story. All Combat Encounters should alter the core story context. In this case, the encounter adds the enemy NPC and records a hanging thread that the PC defeated the NPC’s henchmen.
In previous versions, a core story combat mission would typically work like a regular combat mission- once the PC had been told what to do, the encounter would appear on the map and the PC could go straight to it. I think it works better if the PC has to work a little bit before the fight begins. It builds anticipation, and makes it seem less like the PC is simply playing connect the dots. I also like the fact that the two combats in this plot are very different- in one the PC must defeat a small number of mecha very quickly, while in the other the PC must defeat a large number of mecha.
One thing I need now is a method to make sure that certain subplots will only appear once over the course of a campaign. Some subplots can appear multiple times with no problems- in the above example, the Win Mission and Lose Mission subplots could be the same in nearly all cases. Others- such as Gain Advantage and Locate Encounter- shouldn’t be repeated, but since these subplots won’t likely affect the story context there’s currently no way to guarantee that. If anyone has a good suggestion for how to do this I’d love to hear it.
August 25th, 2008 at 7:00 am
Sounds good!
If you want to prevent a certain subplot from being reused, couldn’t you add a line to the character’s context after the mission is completed and check for it before issuing the subplot?
August 25th, 2008 at 7:42 am
Sorry, I should have explained the problem better. The issue isn’t removing the used components from future use; the real issue is identifying those used components in the first place.
One option would be to give each component a unique identifier, and then keep a list of the identifiers which have been used. I don’t want to assign identifiers by hand since doing that always leads to trouble. It would also make it difficult for people other than me to release content, since there’s always a danger that your chosen identifiers will be used by someone else.
Another option would be to create a list of components at the start of a campaign and delete them as they’re used. This is what’s currently done with artifacts and quests. This isn’t a good solution for plot components, though, since it should be possible to install new components in the middle of a campaign.
I could create a mechanism whereby components are automatically assigned ID numbers by the game when it’s run. These IDs would be contained in a separate file from the components themselves. At startup the game would search through the Series/ directory checking each component against its existing list. If a new component is found, it will be assigned a new unique ID number. How to tell if a component is new? That’s a good question. Maybe each component could be identified by its filename plus its individual name. Problems- scanning the series directory at startup would take time. I’d need someplace in the campaign to store the used ID numbers. Because everyone’s component ID files would potentially be different, sharing RPG save files between machines might not work reliably.
I think that last method might be my best bet, though I’m certain it can be refined somewhat.
August 25th, 2008 at 4:33 pm
I don’t see why you couldn’t add a line like “D:DAU” to a character’s context string to when he has completed a “Rescue the X’s daughter” component. That way when the program is choosing a new component to add to a subsequent plot, all “Rescue the X’s daughter” plots require “!D:DAU”.
Of course this doesn’t prevent the program from choosing the same component more than once in single subplot (from what I understand).
August 26th, 2008 at 12:51 am
It’s true that that could be done right now without writing a single line of code, but the problem is that each component would need to be hand-assigned a unique identifier. Also, after a few dozen unique components the context string would start getting pretty long. Admittedly this system would have certain benefits- the fact that you did a “rescue the daughter” plot could potentially affect future story development.
August 26th, 2008 at 10:14 am
Do you really plan to have dozens of one-shot components? That seems like a lot of work for an event that may occur in a story. A better idea might be to reuse the components but change them subtly either at random or according to the character’s context.
For example, in the kidnapping case, 25% of the time the victim could be dead before the mission even beings, another 25% of the time the kidnapping could be something other than it seems (i.e. she left willingly and her father wants her back, she faked the kidnapping to escape her father, or she faked the kidnapping to lay a trap for the character). In addition, if the character has an enemy, they might be the kidnapper, or the victim could be a friend of the character. If an artifact has been found, the kidnapper might demand that the artifact be handed over for the victim.
The main reason I suggest adding a line to the context is that it can be used to force the program to only use one of a set of components as well.
For instance, say you want to introduce a new biomonster to the story, but the character could stumble over it one of a number of ways (i.e. combat mission against “unidentified mecha”, inadvertently activate it during an archaeological dig, or lose control of it while claiming it for your faction). If each component had added the tag “D:BIOM” or such to the character’s context on generation, you would never have an introduction twice.