Kalia and the Cutscenes (and some more stuff)

Hello all! Today I bring a new devlog about a new development in the Kalia project: in-game cutscene scripting! And while that is meant to be the main topic of this post, I've decided to also hijack it to talk briefly about the immediate future of the project and some ideas I've been floating around to keep interest in the project up, both for the audience and myself. Anyway, onto the topic of cutscenes!

SCRIPTING IN-GAME CUTSCENES

Before getting into this topic, a clarification must be made: Kalia and the Fire Staff is planned to have two styles of cutscenes, fully animated and in-game. Fully animated cutscenes would be either comic panel style slideshows or straight up animations if the game's talent (and budget) can afford it, that showcase major points in the game's narrative that couldn't be properly represented using the in-game graphics. In-game cutscenes on the other hand would happen completely within the game itself, possibly affecting the status of the level directly (such as a level object getting destroyed during one). *While the artist task for an animated cutscene would be significant,* as a game system it's as simple as playing a video or animation sequence over a suspended game, so no sweat in the coding department there. In-game cutscenes are another story. As they use and interact with level elements, they need to be scripted, not animated, requiring a different sort of setup.

If you played the latest version of the demo, you might remember a few cutscenes: whenever a boss is defeated, when the landship is introduced, and right after the street market ambush where two gates are opened. These were developed using a "placeholder" method so that the demo could be finished faster, and that placeholder method was... This:

One big bespoke Unity Coroutine where all the cutscene beats are scripted directly in C#. While it gets the job done for this specific cutscene, its usefulness ends there. Need a slightly different cutscene? Time to make a whole new Coroutine! And considering that the full game will likely have dozens if not a hundred cutscenes like it, do we really want to have so many single-use Coroutines in our code that do mostly the same things but in slightly different ways? No, this won't do, we needed something that would work across multiple use-cases. Maybe like a modular way to script cutscenes...

Introducing: CutsceneController and CutsceneAction!

So what was the idea? Well, in-game cutscenes could be described as a series of common "actions" such as panning the camera around, activating a device or following a moving object. What changes are the parameters and the order of these actions. So what if we could set up these actions like they're building blocks for a cutscene, and have them played as a sequence? We were onto something, so it was time to get to work. Two new components were created, CutsceneController and CutsceneAction. The latter is an abstract class representing a generic action as described earlier, while the former contains a list of actions and is responsible for executing them. Afterward, a few simple actions were implemented, such as CameraAction which handles panning and zooming.

Set up a couple of actions together, and we have an example:

Okay, that's neat and all, but how does it actually work? Let's get into the code then. Remember the bespoke cutscene Coroutine? Having it as a Coroutine was very important as they allow for actions to run across multiple frames. If you tried panning the camera in a single frame, you'd just end up with a jump cut. So I already knew that I'd need to run actions as Coroutines. So we have a series of actions, we have a main controller Coroutine, how do we do this correctly? A revision of how nested Coroutines might be helpful (courtesy of Alan Zucconi).

Ooooh, so that's how you do it.

Yeah it's that simple. Iterate over a sequence of actions and run their individual Coroutines one after another. Actions can also have wait times at their start or end, allowing for pauses in between them (included in action.PlayAction()). This already gives us plenty to work with, but what if we need two actions to happen at the same time?

Huh. Let's try that.

That wasn't complicated at all! Add a check box to the action, and you can have it run in parallel to the main cutscene "thread"! Well okay, it does get a bit more complicated here - first, we can't have two conflicting actions running at the same time (such as two actions that pan the camera); and second, we need to be more mindful of the timing when opening up these parallel sequences. But it does work as intended. But there's one more toy in our box:

Coroutines not only allow you to wait for a set amount of time, they also allow you to wait on a conditional, which enables for "await actions" that do nothing but observe other cutscene elements and "gate" the cutscene. If you watch the example GIF again, you'll notice that the camera only pans to the gate after the heat crystal has been triggered - that's thanks to a logical observer waiting for that sensor to turn on. The code above is a bit more meta, observing previous actions and waiting for their completion, which can be useful to wait on actions running in parallel.

Finally, you may have noticed that one of the actions in the inspector screenshot is labelled ActorController - what's that about? Well, I figured, since this system worked so well for cutscenes, why not reuse it to script acting sequences for NPCs? Maybe that's best reserved for another devlog, but I'll say this much - it's the same method of sequencing action Coroutines, but operating on an NPC. I'll leave an example with this prototype for the zombie introduction right at the start of the game:

AND SOMETHING ABOUT THE FUTURE OF THE PROJECT?

So, at the start of this devlog I said that I also wanted to talk briefly about some ideas to keep me motivated and you interested in the project going forward. The truth is that ever since the third and final demo chapter launched, I found myself staring at this abyss between where I was at and the full game as I currently envision it. While I have taken measures to keep the scope of the project reasonable and still believe it is attainable, this valley is still unavoidable as the project greatly opens up and it can get overwhelming to know what to do next. I have done plenty of writing for it (see the last devlog), but writing is just a part of the whole.

Thankfully, I had the opportunity to attend Gamescom LATAM recently and hang out with many fellow devs, an event which invigorated my motivation and gave me a goal for the near future - to have a proper build for the full game that could be showcased next year (even if an incomplete one). Think of it as another demo, but this time one that is supposed to be a proper vertical slice for KatFS. Having a short term goal is good, but now we need a process. Back when I was developing for the prototype and then demo, there was always something new to talk about, and as the project consolidated, it felt like these devlogs became rarer and rarer. That's not good, devlogs are a great way to not only keep people posted on the project, but also a way to reorganize your own thoughts and feelings. Like a checkpoint.

So what's the conclusion then? I want to establish a more frequent schedule for these devlogs. I'm thinking either monthly or (more likely) bi-weekly. Maybe even weekly if I'm feeling ballsy. The idea is to use these as a quick update on the status of the project, on what was worked on since the last. I might even assign specific days of the month to work on the devlog. I hope to start this right away on a yet to be established schedule, so keep posted on the Kalia Twitter for any news on that front!

That's not all however! I want to have more scheduled "social media" events around the project. What these would actually be is yet to be decided, but as an example, the (sorta) weekly "Friday Fanart" social media posts are something I want to canonize into the Kalia campaign. Speaking of, have you seen this week's art featuring Ana Lúcia from the game Asleep?

Finally, I've been wanting to expand Kalia to other social media platforms. She's already on Bluesky and Tumblr (even if those accounts have been gathering dust for a while), but I've been looking to different sorts of platforms such as Instagram or the new Cara for archiving all the neat arts that have been made around the project. Again, stay posted for future updates!

That's all for now! If you've read this far, I really appreciate it, and I'm eager to showcase more of the project in the near future!