So, I've been working on a map for quite some time now, and throughout the four years or so of production, I am continually plagued by bugs relating to my story triggers, and at long last I have become tired of it enough to seek out help from the community. Essentially, I want events in my story triggers to run correctly. I'll go through what I've tried and some of the bugs I've encountered:

My story triggers require a number of different functionalities. For an example, I'll use the bar quest in my map. Essentially, you walk up to the bar, the bartender offers you a job, you question him further or accept the job, ect. If you accept the job, you go talk to the fellows at a table, tell them to leave, but they're hardasses so you have to battle them to get them to go. After they battle you, you can go back to the bartender and claim your reward, and for simplicities sake we'll end the example quest there.

From this example, a couple different "story functionalities" as I think of them are required. The most notable one is text. Not much of a story without dialogue. I've been using the transmission action instead of Display Text for its ability to show text for a given amount of time. The second one is what I think of as "one-time-events", for example, walking from the bar to the other table with your hero (which is trigger-controlled). The next thing I would consider is "out of story" events, like the battle which occurs, which teleports you to an arena where all your battles take place in the whole game. These sorts of events can be recurring. If you die and return to the location of the story, you jump right back into the battle, and can replay it as many times as necessary to win it. Another function is the activation of "story mode" triggers. It stops spell casting, item use, prevents you from walking away from the story, ect.

One problem I've run into is with the story battles. Say you're stuck in the dialogue while someone else who got there ahead of you is starting the battle. I decided to have the triggers skip whatever intermittent text there is so that you don't miss the battle and get left behind. Essentially there is an extra trigger that bumps up your DC. Unfortunately, this means there are now 2 triggers which can initiate the battle, so say you're in the middle of this trigger with the text running:

Condition:
DC = ("initiate battle value" - 1)
Actions:
Transmission("blah blah blah blah I'm a dirty whore")
Set DC to ("initiate battle value")

And your buddy starts his battle, which activates your "skip ahead to battle" trigger. Now, your "initiate battle" triggers will run, changing the DC value to "battle value", then the trigger with the transmission will finish, resetting the DC to "initiate battle value" accidentally.

Essentially I'm asking for help designing a control system for all these different events. They need to function sequentially but independant somehow.. I'm not exactly sure how to explain it. Any help is appreciated, and I'll answer any questions to the best of my ability. I'm starting to get crunched on free DC values, so I'm trying to make this work using 1 DC per story/cutscene.

What you need is a finite state machine, which in crude terms is like a flow chart. I drew several of these up to consolidate and rationalise a lot of the trigger systems in my map which had evolved over time, and usually I could cut out 20-40% of the existing triggers and make the system less bug prone and easier to understand.

FSM are part of computer science and I got taught them in university. Funnily enough I thought I'd never actually need them. Turns out that in network programming (my job) almost all protocols will have some sort of state machine to drive the various behaviours.

Basically you need to design a separate FSM for each quest or related block of triggers. If you have complex interactions between quests or whatever, you can design self-contained FSMs for each quest and then link them together later. Going through this formal process you may find bugs or action sequences you hadn't considered that haven't been handled properly.

Some quick google results:
http://en.wikipedia.org/wiki/Finite-state_machine
http://www.generation5.org/content/2003/FSM_Tutorial.asp

Just to add some more information to the topic, there are 4 human players P1-4 in force 1, and 4 computer players, 56 = force 2, 78 = force 3. At one point I had set up something like P8 controlled all the story triggers using DC timers and stuff, and when those timers elapsed it set the DC for P1-4 to display text or whatever, but the problem with that was when a person entered a cutscene later than the others, he would miss stuff, or P1-4 would send the same "input" to P8 up to four times in a row which could accidentally reset DC's and stuff like that.

I need help determining how to build control structures within the triggers, I suppose is my main problem. I think your suggestion might be helpful, Lanth, but I also think a lot of the problem is just the way SC's triggers work, like the fact you can't "turn off" a trigger while its halfway through a transmission.

I'm still a bit sketchy on exactly what your problem is. It sounds like you're most of the way there, already.

Anyway, basically you should be using DCs to control the state. Say you have 4 different dialogue triggers, and after the last one you go to the battle arena where some different things happen. To start the conversation, the player brings their Zealot to a location (where the NPC marine is):
Player bring 1 zealot to location x -> Add 1 to story DC
Player has exactly 1 death of story DC -> display dialogue 1, add 1 to story DC
Player has exactly 2 death of story DC -> display dialogue 2, add 1 to story DC
Player has exactly 3 death of story DC -> display dialogue 3, add 1 to story DC
Player has exactly 4 death of story DC -> display dialogue 4, set story DC to 10
Player has exactly 10 deaths of story DC -> set story DC to 100
Player has exactly 100 deaths of Story DC -> [arena has start, do whatever is required. Set story DC to 101]
Player has exactly 101 deaths of Story DC & has at least 1 kills of [arena boss 1] -> Set story DC to 102
Player has exactly 102 deaths of Story DC & has at least 1 kills of [arena boss 2] -> Set story DC to 103
Player has at least 100 deaths of Story DC & commands at most 0 zealots -> Set story DC to 0
Player has at least 1 deaths of Story DC & at most 10 deaths of Story DC & Allies has at least 100 deaths of Story DC -> set story DC to 10

Hopefully you can see a FSM arises out of above states and their transitions. Whenever an ally goes into the arena, the Player's trigger will detect that and set their DC to 10, which then transitions straight through to 100 which brings them to the arena etc. You can have different stages within the arena by having different values of the DC. If the player dies during the arena we clear out the DC and force them to start again.

Another thing to note with this sort of structure is that it's best to leave large gaps of numbers in your trigger functionality blocks. If we want to add another 3 lines of dialog we can easily add it as 5, 6 and 7 and have the last one transition to 10, which transitions to 100. Say we have an alternate way to trigger this particular fight, we can see up a new string of triggers starting at DC 20 and then transition through to 10 or directly to 100.

This all works very good and fine for 1 player, and is essentially what I have already done, but when you add P234 into the mix, things will get more complicated. Take the "skipping ahead" problem, for example. That doesn't exist in a 1-player map, or if I had the requirement that all players had to be present for a cutscene to start, but I'm really trying to restrict the players as little as possible. Another type of problem is "single occurance" type events. Say between DC2 and DC3 in your example is when an enemy zealot should run over and say something to you. Only the first player to arrive should activate his triggers for that event, and everyone else's should remain dormant since it already happened. It's not hard to do, I could just designate a switch for that event, but I'd rather not, and just use the DC for everything, even if I had to store the trigger under P8 for example, instead of Current Player. Essentially I need to create a system that allows not for just a single linear sequence of events, but one that can control Player entries and exits to and from the sequence, at times where entries and exits aren't necessarily at the beginning or end or where you'd logically expect them.


Any ideas are welcome, even if I reject most of them, essentially bouncing ideas off other people is what I'm looking for here. It just seems to me that every solution I try brings up a new host of problems, requiring either additional game resources (death counts, locations, switches ect) to solve or gets so complex and out of hand to fast for me to handle.

I learned this one the hard way

Yes, using a switch is the obvious way to do that. But if you don't want to, then you just need another block of DCs:

[P1-4] starts with DC 0 and enters the location to start the sequence
DC 0 -> 1, 1 -> 2, DC = 2 & P8 DC = 0 send zealot running past & set P8 to have DC of 10, 2 -> 3, 3 -> 4...

The trigger for sending the zealot running past is current player DC = 2 & P8 DC = 0. Since P8 DC is now 10, the zealot won't run past for the second activation.

Really you will be able to do everything you want to do using a single DC, but some things will be easier with multiple DCs or switches. Being able to dedicate the same DC but stored on P8 (and potentially 5-7 as well) will give you a lot more freedom for controlling things.

I think you already have the skills and knowledge to do everything you want to do, you just need a way to formally organise it and record what you're doing. FSM is exactly what you want for it. You can draw it all down on paper and visually inspect it to make sure it's correct. Once you're happy with it, you can file it away somewhere for later. Then in several months time if you want to change the quest again, you can pull out the FSM and re-acquaint yourself with it, rather than trying to work out what's going on just based on the triggers.

Yeah this is stuff I've tried before, but from unfortunately extensive experience, it doesn't always work. Unfortunately, using Transmissions means that if the conditions of that trigger are invalidated halfway through the trigger running, the now "invalid" actions after the transmission will still run, messing up the DC's again. I don't mean to be a party pooper on what seems like an easy method Lanth, but what I'm looking for is something else.

I think you might be right about the FSM thing though, I've been hesitant to do diagrams because they get so complex and cluttered so fast that I'd rather just be working on the triggers. Uhg, I'm not trying to throw your advice away, just I want a magic easy solution to my problems. Thanks for discussing with me, I really do need another human head or two to bounce this stuff off of.

Sounds like your problems mainly stem from using transmissions, then. I've never really used them as anything other than a wait of 0, so don't have much experience with them.

So I guess your problem is that if you have triggers like this:
If DC is 2, start transmission, set DC to 3
If DC is 3, start transmission, set DC to 4

When DC is 2 you get the transmission, but if DC suddenly changes to 100 from another player's action, the transmission completes and it's set to 3. You can't put the "set DC to 3" before the transmission because then the 2nd trigger will fire as well.

Does that sum up your problem?

Obvious solution: don't use transmissions.

I'm probably oversimplifying, but it sounds like a simple solution would be to split your trigs. Currently, I think you're doing this:

TRIG 1: Do transmission and then cause stuff.
TRIG 2: Stuff being caused.

Do this instead:

TRIG 1: Do transmission.
TRIG 2: After transmission -- was stuff invalidated? If not, cause stuff.
TRIG 3: Stuff maybe being caused by Trig 2.

If the problem is that stuff invalidates the trigs during the transmission, then split your trigs at the transmission. When you have any synchronous function that needs to potentially be interrupted by an asynchronous function (i.e. one trigger by another), the easiest way (if not the most elegant) is to just add a shit-ton of "if" statements to the synchronous function, which all check for, and conditionally terminate execution based on, some flag set by the async.

The "problem" is a whole host of things, all having to do with the fact that multiple players can interact with the cutscene. I'm reading and considering every suggestion though, so any advice is appreciated. I've been trying to "brute force" these cutscenes for so long, by which I mean deal with each bug as they come along, instead of designing a system to be bug-free (or at least less bug prone than before) from the beginning, I've finally gotten tired of it and I'm trying to redo the whole thing from scratch.

Perhaps my question would be better phrased another way: If any of you were going to design an rpg with story scenes, in which four players can enter at any (theoretically) time, and exit due to death in battle, or based on in-story choices (i.e. 2 beacons + civ, you pick a choice, goes down a given story path), or successful completion of the story, how would you go about designing them?

Off the top of my head?

State-storing death counts per player. One to store the type of activity being engaged in (cutscene, speech, player-controlled movement, etc. -- maybe treat it as binary if multiple of these are possible at a time), and a switch storing whether the player's current activity has been invalidated. If P1 enters a cutscene, their invalidated switch is cleared and their activity-type DC is set appropriately. If P2-4 do something that would invalidate that cutscene (we check P1's activity-type DC), then P1's invalidation switch is set. P1's triggers would simply be broken into tiny fragments to check the invalidation switch at every opportunity.

This assumes that different types of events and scripts function similarly enough to be generalized and split into types in this fashion -- types that are invalidated by the same kinds of actions, i.e. all cutscenes being invalidated by a player doing a certain thing. (More detailed checking could be done to handle edge cases.) It makes the process of invalidating an event generally independent of the event itself, without outright precluding the use of special checks when specific events need unique invalidation conditions.

One answer is to create a different environment for each player. Runescape style. But considering how the story could potentially diverge, it seems that this would only turn what started as a multiplayer game into a single player game with limited multiplayer interaction, or none at all.

The other solution I can think of is a shared environment. Players actively affect what the other players can do (if a player goes on a quest to kill an evil warlord and succeeds, the quest very well can't be done again). This of course means that some players will be stronger than others. It would be unfair to grant the other players XP for one player's exploits, and rob them from the game experience. But it also creates a disparity. It means that one player who is the strongest will be the one pushing the game's main story in the direction he chooses.

It's no wonder MMOs adopt separate environments: it's the simpler solution. In other Starcraft RPGs I've seen gameplay elements that require a party to stick together (not starting a particular main plot event until all members arrive at the destination).

One could simply make the bosses too strong to fight alone, but I fear all this will do is turn the game into a giant grind fest for the lead player; he'll either slowly get strong enough to take on the boss, or waste enough time until another player is ready. In either case, it's unfair to the lead player that he's punished for doing well.

Or there's simply the, "things happen when things happen" approach. It keys off the story in a preset time-frame, and players that are in the right places at the right times can make decisions that change the story. If you're not there, sucks to be you. If you're not ready for the engagement, too bad. If you're too strong, good for you, go sit in a corner or do some crafting while you wait for stuff to develop.

Then there is a way to challenge the lead player without rewarding him as much. The stronger you are, the more powerful of opponents you'll attract. Reward experience on a logarithmic scale. This does seem a tad unfair, but it would slow down better players.

I suppose the best idea may be to simply develop in complexity. You're a warrior who can one-hit any enemy? Watch them hex you because you don't have any magical defense. Are you a wizard? Watch them send enemies that are immune to most magic. This sort of tactical approach to players forces diversity and slows down any players that get ahead dramatically. The lead player will be ludicrously challenged against an opponent that would be simple to beat with a few low level abilities that he doesn't have access to.

This is essentially true. Cutscenes are essentially as I described them before, single-occurance actions like walking between 2 places, an explosion going off, giving a quest reward to a player, repeat-occurance actions like re-entering a battle you've lost before, trying a puzzle again that you failed, fighting a boss again, and text, three major categories that I can think of anyway.
Can you expand on this maybe? In a more SC-not-C++-oriented fashion perhaps? While triggers and programming languages share many similarities, SC triggers have many peculiarities specific to them that normal languages don't.



Well, I don't really need help with the gameplay mechanics, Sax, but with an actual system to control/handle/operate story cutscenes that won't bug when another player joins the story.
My map essentially follows this:
I'm not sure what you mean by a different environment for each player, but currently my map is designed such that each player has a "dedicated" battle arena in which to fight his battles, and other players can enter his arena and he can enter theirs, depending on which player has "trigger-active" control of the fight.


Another example of a bug to add on to the ones I've mentioned involving this sort of multi-player problem, is say P1 gets to the story, starts it, and while he's fighting the battle P2 arrives and starts his text/story stuff, but P1 finishes the battle before P2 even gets to it, so when P2 gets to the battle, it doesn't happen and P2 gets stuck because his triggers never make the jump to the post-battle triggers. If it wouldnt be too much trouble, lanth, could you make me a short FSM for a quest (you can make it up or use the bar example or w/e)? I don't know if there will be a true "system" answer for these things or not.

Death counter | 1 means cutscene. So 1, 3, 5, 7, etc., would all mean cutscene.
Death counter | 2 means battle. So 2 means a battle, 3 means a cutscene and a battle at the same time.
Death counter | 4 means... I dunno, maybe a selection menu. So 4 is just a menu, 5 is a menu in a cutscene, and 7 is a menu in a battle in a cutscene.
So on for other binary.

So let's go back to your transmission trigger. We keep the state DC, an invalidation switch, and maybe another DC to track progress through the event.

P1 TRIG 1:
Clear switch 'P1 Invalid'
Set 1 to death counter 'P1 event progress'
Set 1 to death counter 'P1 event type'
Transmission

P2 TRIG TO INTERRUPT:
If P1 death counter 'P1 event type' is 1
THEN:
Set switch 'P1 Invalid'
// do P2 stuff

P1 NEXT TRIG:
If switch 'P1 Invalid' is cleared
And death counter 'P1 event progress' is 1
THEN:
// part 2 of the event

P1 INVALID TRIG:
If switch 'P1 Invalid' is set
THEN:
// skip whatever needs to be skipped now

Reliable yet agile and modular trigger design is the hardest thing in SC. Write your control structure hierarchically, so that the level you're at isn't left to its own means.
If you want realistic interruption/change of what's going on, it only follows that you have to split each activity into as many homogeneous pieces as possible. Ideally, you have control of each piece individually (like every response given by a computer in a dialogue) so that you can skip to the most important lines, go back, ect. If that's too complicated, at least have the sequence as a self-sustained progression with a kill-switch at each "block" so that you don't have to worry about it once you've started it but can kill it at any time.

One other general principle I found useful is to always go back to the "default". I'm not sure how to explain this any better... your hero just walking around the map is the "default" state from which the processes of starting/ending dialogue and entering/leaving battle are well-defined. Instead of tiggering another process of gong directly from dialogue to battle and vice-versa, use the default state as the mediator. So if you need to kill a dialogue and go straight into battle, trigger wise, don't be "jumpy" and use the processes you've already defined in a combination to get what you want - put your hero into the default state and go to battle from there. It can be something as simple as just having one trigger loop worth of "break" between the dialogue and the battle where you re-set all your parameters, make sure everything is in order, etc. so that you can put your hero into battle using standardized triggers.

Not sure how useful this may be, but there you go. Good luck with the map!

Conditions:
"Cutscene deaths is 2"
"Check deaths is 0"
-------------------------
actions:
"Transmission blahblahblah"
"Set cutsecene deaths from 2 to 3"
"Set check deaths to 1"

Conditions:
"check deaths is 1"
"cutscene deaths is 2"
--------------------------------
Actions:
"set cutscene deaths to 3"
"set check deaths to 0"

If you want to set someone to any point in the cutscene without interupting the transmission, just set their cutscene deaths to the number previous tot he one you want played.
When the current transmission ends it will set the check to 1 and the trigger before the one you wanted will activate, causing you to jump right into the number you selected.

If you want to skip the transmission (which will stay on the screen until the timer ends) Set the the check to 0 and the cutscene to the one you want to play right now.
It will immediately play the next cutscene even if the one before it isn't finished.

I've just run into essentially this problem with my Blood Pressure Marathon map. Turns out that a Transmission of 0 millseconds counts as a Wait (0). Somewhat obvious in retrospect.

Anyway, it gave me a strategy that you can use if you insist on using transmissions for your text. Instead of having "Actions - Transmission - Set DC to x", use "Add x to DC".

For example, if you have 4 talking triggers, give them DC values 1-4, and have each one add 1 to the DC. When your ally starts the battle, that can have DC +100. That way if your ally starts the battle when you are on DC 2, you will go up to 102 and after the transmissions has ended it will be incremented by 1 to 103, so you won't incorrectly go back to the talking DC.

You'll need to arrange the various transitions such that there's a range of values of each particular state that you want: eg battle stage 1 can be DCs 100 to 109, and battle stage 2 can be DCs 110 to 119, so that way you can have up to 9 talking actions without screwing up the battle DCs. Hopefully your quests will generally be fairly straightforward so you shouldn't need to have many different execution paths to keep track of.