Good workflow for handling cutscenes?

I'm making a small, narrative based adventure game, so I've got a lot of cutscenes planned.

The first few were simple: a character talking to themselves, then in the next scene a character waking another character up.

For both of these scenes I just used an event with no graphic assigned to it and put it aside on the map. It worked well enough and it was easy to keep track of.

After that second scene though, the player is told to go shower. Here they first get control. So after they shower I turn on a switch called 'player has showered'. Then they talk to the NPC again and he tells them to get into uniform. Again, another switch, 'player has dressed' is turned on once they're dressed. When they go back to the NPC, he eventually tells them to meet them in the kitchen.

Now, it was nice at the start when I had everything all in just the one event. It had a lot of commands in it, but it worked and wasn't too hard to keep track of. But, after each of those switches, when the player talked to the character, I didn't do all the dialogue within the main cutscene event, I did it across several event pages of the NPC that activated with the switches I mentioned.

Would a better workflow be to handle everything in the one event? Or across the NPCs event pages? Or a mixture of both like I've got it now? Longer, cutscenes would be separate events and dialogue and everything that is mixed with gameplay across NPC event pages?

My approach for anything meant to be sequential like that is to just use one variable and increment it. I'll refer to it as Time Period (or TP) for the sake of this example:

TP 0: Character talks to self and characters wake each other up. Someone tells the main character to shower. Increment to TP 100
TP 100: Player interacts with the shower. Increment to TP 200.
TP 200: Player talks to NPC and is told to put on uniform. Increment to TP 300.
TP 300: Player does whatever is needed to put on uniform. Increment to TP 400.
TP 400: Player returns to NPC and is told to get in the kitchen. Increment to TP 500.

And so on. A few notes:

1. Note that this approach, while it works really well for me so far, it requires you to keep a set of personal notes detailing which time period means what.
2. It's only appropriate for purely-sequential events. Anything requiring branching options (such as if the player could shower, put on their uniform, etc in any order) would still require switches of some kind.
3. Another huge advantage of keeping as much as possible centered on one variable like this is debugging. When I debug, I can increment or decrement this variable at will to test one specific sequence, or to bypass as much as I want when testing from a new game.
4. I choose to increment by larger numbers (such as 100) just in case I decide to go back and add something else later. Like if I want the character to poop before he showers, I can sneak that in anywhere between TP 1 and TP 99.

Thanks for the tips. I hadn't thought of using variables, as I thought Switches were probably the way to go. I'll have to try your way out.

One other thing I was wondering: after my player is told to go to the kitchen, the NPC who told him that walks out. If I then walk out of the room and then back in, that NPC is back in his initial position. Also, if I have a cutscene that is set to autorun, it starts up again.

Is the way to handle this to just make duplicates of maps? It seems like a bit of a pain if I want to change art around because I'd have to do it across all instances of that map. I also have a lot of interactables in each room so they'd need to be updated, but I can't think of a better way.

That's why the variable approach I mentioned is so nice. In my example, once the player is told to go to the kitchen, the variable increments to 500. You can use this to make a new event page on that npc which causes it to disappear (if he walked out of the map). You can also use it to tell that autorun event to not run once the variable is past a certain point, or to run a quick thingy to move the previously-mentioned npc to his intended location.

So, I'm understanding you right, you'll have a variable called TP, and when a cutscene plays or the player does something that should progress the story, you'd have in that event a Control Variable that adds 100 to that variable. Then you use that variable as a condition for triggering future cutscenes, event states, etc? Like you would say that the next event doesn't trigger unless TP = 200,300, etc?

If that's how it works, then that's pretty nice. It is basically the same thing as switches, right? Except you have the great option of going back and adding more in, which I really like. I just know I'm going to get lost if I make a bunch of switches in order and then go and have to add ones later that are meant for earlier segments.

I do however, have points where the player can do what they want. For example, there's a part where the player has to go and deliver coffee to 4 different characters, but the player can visit any of those characters in order. I should be able to use your workflow up until this point and then use switches as well, right?

I tend to use a different variable for each series of quests. Var 1 would be the main series, but then each side quest will have another variable to keep track of it.

Oh, cool. So do you do the same thing as Aesica? Like, you'd have Variable 1 as your main quest and keep adding to it to control the main quest?

Yup, that's exactly it. :) Although I name the variable something like "TP - Main Quest" so that it's easily recognizable from any additional variables I add for side quests.

I have something similar, where the player is supposed to talk to each of the party members plus a few NPCs in the room. For the time being, I used self switches to mark each person as interacted with, but also, each initial interaction incremented the time period variable by 20. Upon reaching the desired total, the main questline is able to continue to the next phase.

While I suppose you could replace self switches using bitwise operators (each person increments by 1, 2, 4, 8, or 16) that requires you be more comfortable with coding. That's probably how I'm going to end up doing it, though.