Making a Scene

Whoa, it’s March already. March 2013, even! I keep getting an embarrassing reminder of time every time I open Tweetdeck and see declarations that I was going to smash out The Day After in 2012.

Don’t fear, I am working on it. It’s just slow progress that usually doesn’t lend itself well to blog posts. I have some new (AWESOME) artwork to show off, but I need to do a bunch of boring things like tweak the website and fix this blog theme – I’ve lost my love for this WordPress theme and am convinced it mangles posts with pictures. *sigh*

So what have I been working on? I’ve done a bunch of engine work (getting graphics, input and text managers working) but I’ve pushed my focus over to the game engine. Core to The Day After is the concept of scenes. As best I can describe it, the core gameplay in TDA is interactive scenes, like the dialogue of Bioware games or scenes in visual novels, but souped-up a little.

As a reminder, in TDA you’re a Survivor of a great calamity. You need to get rescued and achieve objectives whilst working as a team and overcoming all the crazy stuff thrown at you.

Each slice of story and action happens in a Scene. The Drama Manager (aka Drama Queen) selects appropriate scenes to either push storylines forward or create a bit of chaos for the Survivors. Scenes may run in parallel (so characters may break off into their own conversations temporarily, or one person may be bolstering a door while another tries to find a weapon) but they are granular. There’s a scene, people do things and the curtain comes down. Next scene.

Once we’ve broken the game down into scenes, we can begin to think about how we connect scenes. The way I’m setting things up, there are three main types of games I can easily emulate with my system.

The first is a linear or branching narrative. This abstractly looks like this kind of picture:

Linear or branching narrative.
Linear or branching narrative.

The order of scenes are fixed and if there is a choice in subsequent scenes, you can never go back. Games like Half-Life 2 encompass this style of story on a high-level view. They have a fairly set story they want to tell and you might get a choice in how you end the game (like the famous G-man choice at the end of Half-Life 1). I think this sort of game setup could be good for a tutorial for TDA or to showcase new features. The only randomness in the linear narrative is within a scene, so you can use it for competitive play.

The second style of game is the choose-your-own-adventure narrative. This looks like:

Choose-Your-Own-Adventure-style narrative.
Choose-Your-Own-Adventure-style narrative.

Notice that you can loop back around in this model, branch and combine branches. The Mass Effect series and Telltale’s Walking Dead series work like this on a narrative level. Some choices branch out initially in terms of new scenes, but in later scenes we combine those threads to compress the amount of content we need to make, and to push the story through fixed narrative gates. This kind of story could be good for set piece stories – I fix the general narrative milestones but allow the story to wander a little bit in between.

The last style of game is free-flow sandbox, like roguelikes. This looks like:

Clusterfrak narrative
Clusterfrak narrative

Of course this is a silly representation. In this situation I give the reins to the DramaManager and let it choose the next scene based on a number of factors in the game. It might want to up the tension, give two characters an opportunity to chat, remind the players about their impending rescue or doom, present new characters… basically any dramatic effect I’d like to happen. It’d all be random and heuristically chosen, on a scene-by-scene basis. This is where I see the real game of TDA occurring. It’s no good for competitive play or tutorials, but great for normal games or endless play.

Under the hood, the first two styles are actually just restrictions on the last one, but it’s nice that you can put the restrictions in there and get a slightly different flavour of play. Specifically in the first style, the Drama Manager only has the strict options you allow it to use. In the second, the Drama Manager still has strict instructions, but scenes interact with those instructions in more interesting ways.

This system is at the very core of the game and touches on everything: the engine loop (updating graphics, sounds etc), the world model, and how I put data and story into the game. I’m pretty sure I’ve got a good framework for all this. I’m currently dismantling some of the old code, inserting the new framework and testing. My goal this year is to create some prototypes, probably a linear test game, then one with branching, and when I’m confident of all that, I’ll give the Drama Manager room to cause havoc. Although I’m trying to avoid it, this part of the engine needs to be implemented with a bit of coupling between components, so it feels like creating from whole cloth rather than the much easier patchwork.

So that’s what I’m up to and why I’ve been quiet of late.