Telling a Tale, One Sequence at a Time

It’s been a busy few weeks of work on TMF, with a rethink on how unit growth works (fun!), the fleshing out of the leader perk system (exciting!), and a complete overhaul of the save/load system (painful!). While all of those things are worth talking about on their own, the thing I want to focus on today is story.

As exciting as moving pieces around a map and having them battle each other is, it’s not particularly compelling unless there’s a reason for it. Maybe it’s as simple as “they don’t like each other”, but for most of us we want something a little juicier than that.

I’ve been calling this project TMF, because it’s short for Tyrants Must Fall, which is the working title I came up with when I first sketched out the narrative. As you might guess from the name - and from the inspiration the game takes from Fire Emblem and Ogre Battle, among others - it’s a sweeping tale of rebellion, war, and the forces that shape history.

That being said, I don’t really want to talk about that today, either.

How a Story is Told

What I do want to talk about is the rather more practical bit of “how do I get all that narrative in there?” As tempting as it would be to hearken back to the days of paragraph books, players tend to want their narrative a bit better integrated these days.

Unity, being an incredibly generic game engine for building whatever, has no concept of narrative. Sure, it can provide some structures to allow you manage the narrative within your game, but it’s certainly going to require some heavy lifting on your part.

One tool I’ve come to rely on over the past few years is the Dialogue System for Unity by Pixel Crushers. It’s an incredibly robust asset for Unity that handles not just the presentation of dialogue, but all of the behind the scenes management that goes along with it. You can write branching dialogue directly in its database, or use an external tool like Twine. It comes with a bunch of designed dialogue templates, but is also flexible enough that it’s easy to develop your own that fits the needs of your particular game. I cannot begin to guess the number of hours the Dialogue System has saved me, but I’ll just ballpark it as “extremely substantial”.

The thing is, the Dialogue System is still just a part of the equation. Managing the text and getting it up on screen is one thing, but in my vision of the game I want the narrative elements to match the experience the player is having from a gameplay point of view. When running around the map, I want the player to see their units moving about, performing the actions the story is telling them about. In battles, I want the opposing commander squawking at each other from across the battlefield.

That means taking advantage of other systems Unity has to offer - or figuring out how to build my own.

One built-in Unity package is Timeline. As the name implies, it’s a tool for organizing and playing back sequences of events with various triggers and functions. It would take more than the space of this devlog to explain Timeline in full, so just understand that it’s something in which I could say “play the ‘run’ animation on GameObject 1, and when the animation is finished have it start the ‘jump’ animation on GameObject 2 and also play an audio effect at the same time”. It’s much more in-depth than that, but that’s the gist of it.

Unfortunately, Timeline has its limitations as well. A lot of it is built around Animation sequences, whereas in my case I want to take advantage of the pathfinding system I’ve already built. Also, when you start to pull in events like Dialogue System conversations, timing can start to get very messy.

So with two systems that do big parts of what I want (but not all), the clear path forward was that I needed to build something to unify them.

Frankensteining Your Workflow

Now, some people are tools people - people who love building things like map editors or real-time rendering editors. I am not one of those people. I envy those people and their abilities to build exactly the tools they want to do the things they want, but it’s just a road I haven’t wanted to go down. So while I didn’t want to build a fully customized editor within Unity to stitch my pieces together, I did need to cobble together something.

What I ultimately came up with was a Narrative Sequence manager, which allows me to combine my movement pieces via Timeline with my dialogue pieces via the Dialogue Manager, then reorder them or otherwise manipulate them as needed to get the full sequence I desire.

Each narrative sequence is made up of a series of “Playables” (Timeline’s term for, well, timelines). Each individual Playable handles a small chunk of movement, dialogue, or other triggers. This little snippet below, for example, handles the Hero’s avatar appearing and moving, along with a second piece following behind. Rather than using Animations, this system lets me take advantage of my already-built Pathfinding system so I can simply enter in the map coordinates of where I want the involved pieces to go. This also makes it very easy to change sequences on the fly if I end up having to edit the maps for some reason (which is highly likely at this stage in development).

Whenever a sequence ends, the controller looks for the next one, whatever it may be. If there is one, great - do it! If not, cutscene over!

It’s a straightforward system, but it gives me a solid way to unify two disparate systems I know pretty well. It also gives me the flexibility of adding additional features via Timeline’s signal system, and also some extended capabilities thanks to the Dialogue System’s own trigger system.

Are there downsides? Absolutely! The biggest one by far is managing the individual sequences. It’s incumbent on me to give them names that make it easy to understand what they (which I didn’t do in the above image) and make sure I’m putting the right ones in the right spots. Fortunately it’s easy enough to move them around, but it certainly saves time to get it right the first time.

All that said, it still feels like the right solution for me. As a lone dev, it fits my needs and streamlines my workflow. Now I can do my writing, then plot out the visual elements of it right there at the same time I’m building out the actual maps themselves. Keeping it all in one space is a huge boon from a management perspective, but also from a creative one.

As development continues, I have doubt I’ll be refining this even further, but it feels like a solid starting point. And hey, if I happen to bring another team member on at some point, it’s simple enough to understand that I think anybody could drop in and start creating.

Next Time: Rethinking Units and Toying With Player’s Emotions!

P.S. You can always join the conversation at our Porch Weather Games discord!