Dramatic Role Proxies

Dynamic narrative is not something that the mass market for games has any real interest in at this time, but it is something that many game-literate players see as something of a grail. There are many possible approaches, and it can be difficult to know which are worth exploring and which might be dead ends without committing time and resources to prototyping. One such approach is the substitution of proxy characters for specified dramatic roles. 

Although I greatly value the high degree of autonomy I enjoy with International Hobo, it is offset by our lack of resources. Nowhere is this more apparent than the sheer volume of work we have carried out investigating and blueprinting dynamic narrative systems that we generally do not have the resources to implement. Many of these systems have been proposed for certain game projects, but none of those projects have proceeded to funding, and that leaves a lot of the ideas and concepts largely untested.

Reluctant Hero is intended to include a dynamic narrative system, but the question that hangs over the design of this system is the extent to which we will be able to implement new concepts. Game design is almost always a balancing act – new ideas may have great merit, but they take time (and hence money) to prototype, implement and tweak. Usually, I would advocate building a game out of the fewest number of game systems necessary – and since this game already has an inventive combat system, negotiation system and structure, I have to seriously consider to what extent we can risk exploring dynamic narrative techniques as well. 

A fallback position is essential in such situations, and in this case we can always resort to a regular cRPG scripting solution but divided into an episodic structure, much like a TV show (a topic I have discussed before). The game story can then be pieced together from atomic components. This will provide a basic dynamic narrative, but it delivers rather less than I would hope for.

What I would like to explore in this instance is abstracting out the dramatic roles of the narrative, and then instantiating these roles in each episodic instance, which for now I shall term dramatic role proxies. This is an idea we developed before for a rather interesting game project which, sadly, did not proceed to funding. However, the basic idea has always seemed sound and worthy of further investigation. 

Before discussing the problems relating to this, it is necessary to relate something of the data structure of the world of Reluctant Hero. Essentially, the world of the game consists of a database (as can be claimed for any cRPG or MMORPG) the principle elements of which are the Personas (people, monsters) and the Sites (locations, establishments, lairs). Every Persona exists at a Site in the game world – so the world of the game consists of a number of Sites, at which lives a certain collection of Personas (some of which are NPCs and some are monsters).

The idea behind role proxies is that the Personas that the player meets will be collected in lists – Friends lists for those the player has related positively with, and Enemies lists for those the player has related negatively with. (An Allies and Nemesis list may also be used for the player character’s closest friends and worst enemies). These lists are then used to substitute for the general case roles in the narrative engine. 

So, consider for instance an episode that is scripted around a hostage situation plot. In informal terms, this episode script might read something like this:

An ENEMY occupies one of the Hero’s ESTABLISHMENTS, disabling the EMPLOYEES and demanding 50% of the Hero’s new worth. The Hero has 7 days to pay up. 

When these story events come into play, the game would look at the player’s Enemy list and select a Persona from this list to instantiate the dramatic role of ‘Enemy’. Similarly, an Establishment (e.g. a Smithy, a Trading House, a Guild house) owned by the player is selected from the appropriate list, and everyone who has that Site as their home is disabled. A clock is then set for 7 days for the player to either pay up the ransom or overcome the Enemy by other means. (A pre-requisite for this episode being triggered would be the player owning an Establishment, of course).

This episode can then be scripted according to this general pattern. When the player encounters it, the Enemy chosen will be someone that the player has already encountered and who has a reason to hate the player character, and will therefore make sense in narrative terms. 

Where are the difficulties with such a system? It transpires that the actual substitution of dramatic role proxies is the easy part – the difficult parts are identifying circumstances within the game state which generate the role classes (Enemy, Friend), and determining how to store dialogue so that it can be meaningfully recovered when necessary.

The first of these problems is most certainly soluble – Enemies and Friends can be generated both by the action of episode scripts, and also by the outcome of combat situations and negotiations (both of which have their own engine, and hence such assignments can be made as part of the exit conditions of these systems). The problem in this case is that there will probably be a large number of ad hoc situations which must be detected – and detecting specific cases in game state is a recurrent game design problem. It is not that there is a problem to be solved, per se, so much as concern must be given to the amount of time and resources required to implement, and subsequently to debug such a system. 

The second of these problems is somewhat trickier. It requires thought as to where in the game data structures the dialogue is held, and to which dialogue is specified in the episode scripts, and which is owned by the Persona in question. For instance, we can store a value with each Enemy that reflects why that Persona became an Enemy. This value can have associated with it dialogue that comments on why this Persona hates the player.

For instance:

Player kills Enemy’s Husband:
“I can never forgive you for killing my husband.”

Player kills Enemy’s Wife:
“You killed my wife, and I can never forgive you.”

Player foiled coup to control $Region (episode outcome):
“$Region should have been mine, but you had to get in my way”

These motive lines can then be given a reference ($Enemy:motive) and triggered inside episode scripts where appropriate.

For instance, in a prior example of a hostage situation, an event may occur when the player character and Enemy meet for the first time in the episode: 

Player: “Why are you doing this, $Enemy?”
Enemy: $Enemy:motive
Enemy: “Consider this my revenge.”

This scratches the surface of the technique, but I hope it’s clear that there potential here for constructing stories on the fly in which the player’s actions have consequences which are reflected in the story, and hence in dialogue. 

As well as Friend and Enemy proxies, Lover, Monster and perhaps even Mentor and Mercenary proxies may also be possible. For instance, if the player exterminates all but one of the monsters from a lair when they are young, the surviving creature can be added to the Monster list along with a narrator-delivered introduction line to be played when it is chosen (decades later) as a Monster for a particular episode, e.g.:

Narrator: “The $Monster seems to recognise you – there is hatred in its eyes.”

All of this makes this particular dynamic narrative form sound easier than in practical terms it is likely to reflect, and neither I nor 3D People have committed to following this approach yet. I need to specify the formal elements of this system completely so that we can fully assess the scope and risks before we can proceed. 

A related issue worth considering is whether or not to write dialogue in a direct form, whereby the characters in questions will ‘speak’ the lines, or whether to script the entire game from a narrator perspective.

So for instance (and assuming a female enemy – both male and female case lines must be written in most cases to simplify localisation): 

Enemy: “I can never forgive you for killing my husband.”

Becomes: 

Narrator: She says she can never forgive you for killing her husband.

The advantage of the narrator approach is that we could then use a narrator voice actor to record all the dialogue of the game (at least in principle – some stitching might be required). If we don’t use this approach, it will be hard, if not impossible, to record any dialogue for the game. 

Frankly, I’m uncertain of the best way to jump on this issue, but I’m swaying away from a purely narrator based approach. It might be superior to use the narrator to introduce, link and close individual episodes, and leave in (unspoken) dialogue for the rest of the story elements.

This doesn’t cover all of the issues (I have skipped over the dialogue matters relating to funnelling and breadcrumbing, for instance, as this is the easy part in this case) but it gives a snapshot of the problems and potential currently being explored for the dynamic narrative of Reluctant Hero. I don’t know if we will end up using dramatic role proxies or not, but at the moment it seems tenable – a more complete specification of the system will be required to convince me that there no ‘unexploded bombs’ in the design before we can proceed. 

Naturally, I welcome opinions from other people on this subject. Are the goals of this approach worth pursuing? How much of the dialogue workload should be given to the narrator? Let me know what you think.

Comments

[Patrick]

You could call the game Troubadour (three syllables) and have the narration be part of the overall character of the game, in marketing terms it'll have just as much pull for the RPG audience if not more than the longer title currently being used. I do think the hybrid solution of narrating at key junctures is the better one.

I find it interesting that you're using a generative system, but I suppose you have to since pre-written dialogue content is a major part of the game. The architechture you're describing is hauntingly similar to Storytron's, in Crawford's patent there is an algorithm described that is almost identical to yours. You could fly under the legal radar there since this isn't a middleware engine you're talking about, but my Spider Sense tells me to learn from Crawford's design and move on.

In case you're unfamiliar, here's how it works roughly: a script calls for a role to be filled, the engine goes through a list of actors and tests them for eligability, then matches one.

A qualitative issue here is that the characters seem very one-dimensional, based on your axis of assignment. That might work better for a casually targeted game with a symbolic interface than a hardcore targeted game with prescribed dialogue atoms. If you're going to go generative, you might as well go with heterogeneous characters, but on a level radically scaled down (in terms of the scripting language) than Facade, which is also a generative model featuring heterogeneous characters. If you do that you'll have more procedurally intersting characters and you'll be outside the realm of Crawford's patent.

So think of it inside out, instead of assigning data-structural permutations to boolean niches, you have characters operating along niches which are implied by their process. You'll end up with more interesting, less generic characters that way.

If you want to see a design of how such a scripting language would look, see Craig's work from the summer, which we never got the funding to implement. According to Craig something comprable can be prototyped within a few weeks, depending on the parameters of the engine, so the resources required are well within your development partners' reach.

[Chris]

It's interesting that there's overlap here with Crawford's work. That leaves me slightly nervous of pushing in this direction, to be honest, as we are innovating in all the major game systems which is surely risky.

I have read some Storytron documentation, but I'd be lying if I said I understood any aspect of the underlying implementation. I don't want to undertake anything of this level of complexity.

Do you have a copy of the patent in question? I'd like to check there's no crossover. My instinct is that what I'm proposing is far simpler than Storytron, since all we'll be doing is keeping a list of Friends and Enemies, and drawing from that when necessary. It's not even complex enough to warrant a patent in our case.

I'm not entirely convinced that the characters will seem as one-dimensional as you suggest, since what I'm pushing for here is a high degree of implicit narrative - much of the player's image of the characters will be shaped by their behaviour not their dialogue. This depends in part on whether we get the AI system I'm aiming for, and also on how successful the Negotiation system is - but I'm quite confident of this part of the design.

It's important to remember that this is a cRPG and not a simulation game. The way I see it, fighting enemies with whom you have a prior relationship will be more engaging than fighting random enemies, and this is the primary role of the dramatic role proxies.

An alternative option altogether is to keep the dynamic sequencing of episode content but to use a set cast of characters, with no procedural elements at all. This strengthens the importance of the script, and reduces the innovation risk.

I'm going to Slovakia next week to talk to 3D People, so this might firm up some of the ambiguities in the project.

[Patrick]

"An alternative option altogether is to keep the dynamic sequencing of episode content but to use a set cast of characters, with no procedural elements at all. This strengthens the importance of the script, and reduces the innovation risk."

This seems like an alternative worth exploring, but theres a paradox here you might not be consciously aware of. I strongly encourage you to read the Rocket Heart documents to get a sense of how, in a hypothetical engine, you would script specific characts, but these scripts also define the processes of said characters in the engine. Its still procedural, it just defines characters by heterogeneous sets of scripts instead of permuations on a homogenous data structure. There is of course more fictional design spent on each one, and you have to balance their actions and amount in the greater system.

Think of it this way, you'll have to spend a lot of time and creative energy designing these creatures, in terms of script content, but you'll get much better results in terms of dramatically compelling characters. Plus, once you have the character engine prototyped it becomes incredibly rapid to concieve and implement a character, so you can go crazy with it.

I make this argument for two reasons, 1) my experience studying four different drama engine designs tells me that heterogeneous characters are more conducive to the production process, if not the end-experience and 2) I've been craving, in the pits of my soul, a good content editor to work with since I finished building PwF levels, and this is precisely the sort of content creation I've been hoping to do for a while. I'll have a decent income otherwise, so I'm willing to script characters and/or arrange spatial level designs for royalty points. I'm sure you've got Neil and Richard set for the latter, but I've been exposed to different paradigmns of the prior longer than most other qualified people on the planet.

Back in September I worked through Crawford's patent, and I posted my work to his message boards. He has since deleted it, which isn't entirely unexpected since I totally nailed him; the link provided to the full text of the patent is gone with it.

Anyway, you can definetly implement a system similar to what you've described here, and you'll unlikely be sued by a man with little financial resources and no direct competetition with you. I'm proposing an alternative on the grounds that I think it would be qualitatively more interesting for the player, and it would also provide a nice precedent for such a technique in future games.

[Peter Crowther]

"It's not even complex enough to warrant a patent in our case."

Never stopped Bezos. The issue is not complexity, the issue is FUD over possible infringement, as the comments on Crawford's patent demonstrate. It's there, it's potentially troublesome... let's engineer round it rather than risk the court case.

[Chris]

Peter: you're right, of course. How I detest patent law... :(

I still have been unable to contact you over email, by the way, and I've received nothing from you - we're never going to be able to get together for a drink if we can't manage to communicate! It's quite exasperating.

Patrick: Rocket Hearts is just way too complicated for the needs of this game. This isn't a simulation. The NPCs will not be taking actions independently of the player. Most importantly, I don't think 3D People has any interest in developing this kind of system, and so this game will necessarily not include this kind of system. It's just not my call.

I *am* interested in this sort of procedural approach, as not that long ago I was extremely optimistic about dynamic narrative couched in these terms - but if we take the burden of this work on board along with all the other innovation risks, we will be biting off more than we can chew.

I now believe in advancing commercial dynamic narrative in small, conservative steps, not trying to leap ahead - at least in commercial projects. Non-commercial projects like Facade can and should do what they can!

If Reluctant Hero can manage dynamically sequenced episodes with dramatic role proxies that in itself will be a big step forward from fully enumerated linear narrative, but it comes with limited risk, and that has to be considered a priority issue under the circumstances.

I appreciate your input on this issue, but the new RPG system at the heart of Reluctant Hero is the "star of the show" - everything else must serve this purpose. There is no room for innovations that do not expressly support this central point - we do not have the resources for risky experiments at this time (and probably never will). :(

I don't know whether royalty points will be available for external distribution on RH yet - I'm meeting with 3D People next week, and this will surely be discussed. I'll let you know if its an option, and I would be interested in bringing you into this project - but this will never be a project about dynamic narrative, I'm afraid, it just may have some simple dynamic elements within it.

Best wishes!

[Patrick]

Cool. :)

I wasn't suggesting you implement RH for RH, I was pointing to an example. I think one element of the scripting langauge suggested that you could definetly use is the scheduling parameters, which seem to synch with the needs of the episodic system. That and relationship adjustments are core. But even with those two features as integrated to your main system, you'd get a lot of interesting variation in how characters could be scripted. And thats better, IMNSHO, than characters generated by data permuations, and it happens to completly sideswipe key claims in every section of Crawford's patent, which I already dug through but can't reproduce, as I've been censored. :P

[Chris]

I'm afraid I don't see the need for the scheduling parameters. The design as I have on paper positions all the game entities (people, monsters) according to their base of operations. I don't see any tangible value in scheduling this behaviour - it creates more work for the development team, but gives very little extra to the player. This is one of (many) situations where I believe a little carefully shaped chance goes a long way. (I also don't see how this would affect how characters are scripted).

The relationship mechanics in Rocket Hearts strike me as far to simulation-based for the needs of Reluctant Hero. The negotiation system (which I appreciate I haven't properly discussed yet) should generate sufficient basis for changing of relationships without too much else needing to be added.

Perhaps this is a case of incomplete information, in that I'm still working on the design of Reluctant Hero, and you aren't party to the details of that design (yet).

I suspect your feedback would be more useful after the mechanics are written, as then you'd be able to see what was being used and how. Since you're covered by NDA, I'm sure I can send you a copy of the core design when its completed.

Thanks for the input!

[Corvus]

Chris, these goals are absolutely worth pursuing. I've got something very similar in the works for the Honeycomb Engine (as you might remember from the radial plot posts in May).

You clearly have a solid grasp on the possibilities of such a system, of both the benefits and the hindrances. The Honeycomb Engine is further complicated by ascribing levels of potential villainy and heroism to characters, which informs how far they're willing to go to seek revenge, or how quickly they forgive. At least RH won't have to deal with those extra headaches!

Good luck in your meetings. Hopefully there will be room in the budget. Keep us informed!

Oh, and from a player perspective, I'd be all in favor of you handing dialog to the narrator. It's a pretty traditional narrative conceit for this sort of story and if the narrator turned out to be the central character, reflecting on his life from a vantage point created by the player's actions... so much the better. You know the sort of thing:

"As I write these final words, I look out the room of my squalid shack and wonder how I could have wrested my life out of the hands of fate..."

"As I write these final words, I hear the guards approaching my cell. These fools may kill me for what I have done, but they can never unmake my deeds or obliterate my greatness from the annals of their history."

"I fear I haven't long left. As I write these final words, I feel the welcome touch of death lightly caressing my heart. I have lived full life, I only hope that they say of me, He left the world a better place than he entered."

[Chris]

Corvus: I really appreciate you finding the time to get around to commenting. I really enjoy bouncing ideas between Patrick, but he and I often end up in highly technical spaces which can miss the point I was seeking in the first place. ;)

The advantage you have with the Honeycomb engine is that you're not really implementing yet, so you still have plenty of time to iron out stuff on paper. I'm feeling my back against the wall already, and we've only done the tech demo! :o

I'm also fascinated to hear you endorse the narrator idea, because I have to say I am really drawn towards this approach. It allows me to get a voice actor in to do all the game voice (which we couldn't afford to do otherwise), and it also changes the focus of the narrative in a way that I find quite appealing.

I really need to know how people feel about this issue in the wider audience before commiting to it, though.

Thanks again!

PS: I can't have the narrator be the player character because the player has a choice of male or female character, and that would require two narrators (which we can't afford). But I know what you're driving at here and certainly plan to take advantage of it in some manner. ;)

[Corvus]

Gender choice completely trumps future-self 1st person narrative!

[Mike]

Find the right androgynous voice actor and you can have it all :)