Scripted Scenes in Dead End

Since I recently finished updating this system, I thought I’d give an explanation of it for you 🙂

Dead End uses a system I made years ago (and first used in Planet of the Poison Past), which allows me to quickly write dialogue, scene direction, and a few other neat little game related things like inventory addition/removal and setting story flags.

It is based off my (very limited) experience with Ren’Py (which was wonderful) to make Important Game You Should Play. I loved how you could quickly create character settings, and then use a shortcut to refer to characters by a single letter. So that’s what I used as the foundation for my system.

OK, so lets go through the script for the above scene! It is just a text file, which the parser will read from top to bottom, processing one line at a time:

First we use the ‘char’ command to create our ‘Enid’ character, and pass along all the information we need;

• shortcut (from here on, ‘e’ will refer to our Enid character)
• display name (for dialogue bubbles with a name display, I’ve recently disabled them tho – just trying it out!)
• animation object name (name of the gameObject which has Enid’s animations on it)
• tail point object (which object a speech bubble’s tail should point at when Enid talks)

Here we specify where and how Enid’s speech bubble will appear on the screen. Position, scale, colour. Not much to it but just these go a long way to distinguishing between different characters’ speech.

We also set up Enid’s motion, this includes:

• How fast a character walks
• The name of the walking animation
• How fast a character runs
• The name of the running animation
• The idle animation
• How fast a character turns

Although not used in this scene, I can give direction in these scripts to direct characters to move about, and this stuff determines how they do that.

We do all this for each character in a scene, so here’s that for the other character, the Aristocrat:

Once our characters are set up, I specify which animations they should be playing at the start of the scene:

(These animations will stay the same throughout this particular scene, mostly because I haven’t animated much else yet, but once I have I’ll be able to say things like “e anim shocked” or “a anim rudelaugh” to have much more expression. But I’m waiting till my writing is more certain first, so I don’t make animations that I later decide not to use).

The next thing I usually do is check for item use. If the player tried to use an item and triggered this scene, we can check what item it was and go to a specific marker in our script. Here, if the player tries to use the crest then the parser will look for the “usecrest” marker, if the player tries to use any other item it will go to the “usemiscitem” marker.

And here is the scene’s dialogue for the gif above. I use the character shortcuts (e for Enid, a for Aristocrat) and quickly write out dialogue and scene direction.

This saves a HUGE amount of time compared to any other way of writing scenes I know of, and I can make little changes without any worry because it is just a text file (no compile time!)

Finally, the ‘end’ command tells the parser to complete the scene and not to keep advancing to any more lines beyond.

But there are lines beyond! This is an adventure game after all and we did write some conditions for item use, so next we have the markers that those conditions point to:

We have markers “usemiscitem” and “usecrest” marked with #, the dialogue for each kind of item use, and an ‘end’ to finish the scene.

The ‘usecrest’ section doesn’t need an ‘end’ however, because that really is the end of the script and the parser will know to end there 🙂

~

The scene parser also understands commands for dialogue choices, showing/hiding props, music cues, transitions to other levels, camera direction, character motion like “walkto” and “runto”, setting story flags (Boolean, float, int, string, vector), going to a specified line marker, going to a random marker from a list, and a command to trigger C# scripted actions for anything that the parser can’t do.

This is one of those kinds of things that takes a LONG time to program, but once it’s done you can work A LOT faster.

Like, A LOOOOOOOOT.

~

I hope this was interesting, and in case it’s useful for you I’m attaching my current parser script. It won’t do much without all of my other adventure game systems to work alongside it, but it should at least provide some insight into how I write a parser that can do all of this 🙂

As always, thanks for your support! It means bunches to me, bunches and bunches. SO MANY BUNCHES ok I gotta stop typing now BYEEEEEEEE <3