Concurrent behaviours within non-linear dialogue

Concurrency is an area of programming that few people enjoy wrestling with. I have tried my hand at it a couple of times, both in practice and theoretically as a part of my university studies.

Obviously concurrency is everywhere, but typically it only sees large use when very specific task parameters are in place. The internet and cell phones are great examples of humongous concurrent systems where concurrency is inherent in their structure; it is a prerequisite, so to speak, but also an obvious pattern. Each cell phone, each computer, often live in their own little isolated worlds, untill they decide to make a transfer to another, single computer.

Since each transfer between two computers is unrelated to whatever else is going on, many such transfers can take place concurrently without any interference.

But while most concurrent computer systems are "pretty" like this, the only really interesting concurrent structures are the ones where the various transfers are not unrelated; where everything isn't locked down nicely into little isolated systems that can be run concurrently without a moments pause.

The way in which concurrency is used within non linear dialogue is absolutely crucial, then, because we would prefer that if we do need to use it, we want the full benefits. Oblivion and morrowind are exceptional examples of non linear games. The second I write games, I feel the need to legitimize that I, a grown man, am fooling around with such nonsense, but exactly for that reason, I think I wont.
But let me continue: They're exceptional examples because they utilize a hugely concurrent system. You can easily be working on 10s, if not 100s, of quests at the same time. The players journal, if thought of as a language with many composite pieces, is huge and expressive - what direction the player takes within each individual quest, and which quests he does first and last, is entirely up to him. It even goes that the players customization at the start of the game is reflected in a myrriad of the quests, further adding to the unique experience of the individual player.
How all this works out, though, is managed mainly as a dull concurrent system - every quest is like a transfer on the internet, but no two transfers have effect on eachother. Even if you're doing 2 quests for the same guy at the same time, you're going to recieve the two seperate thankyous that each quest yeilds upon your return.

It's not that the connection is mangled - it's that it isn't there. Of course, if it were there, it could well be mangled - there's a reason why the various quests are not intertwined in their narrative. It would be too difficult to maintain any sort of overview. Mistakes would be introduced. The game could well be broken in many ways. And it would take much more work to intertwine various quests.

But all the same, reality is intertwined, because when concurrent behaviour is exhibited across communications, they _do_ affect eachother fairly often, even if the communications are unrelated at the outset. And for that reason, developing concurrent narratives within non linear dialogue requirres that the full suite of concurrency-architecture tools be utilized to engineer natural sounding narratives.

Context management within complex adaptive structures

I'm very fond of programming patterns. The concept is easy to describe, but hard to fully grasp.
The idea is that if you program things in a certain way, where things relate to eachother in a particular fashion at an abstract level, then your life will be a lot easier.

Utilizing an advanced programming pattern to solve a tricky problem is a bit like how I imagine bungie jumping must feel. You fasten the pattern securely around your waist, take aim at the ground below, and then you jump. And for a while there, you're in free fall, just as if there is nothing there to support you, nothing to catch you. You just have to have faith that you're using the pattern right, because you won't know if it'll work untill the point where it's workings snap into place, and saves you from crashing and losing all your hard work.

Now that might sound somehow risky, and the first time you use it, it sure feels that way. Because sure, your teacher may have told you that it'll work, or you may have read it in the book. Or you may have seen it presented in one of googles lovely programming podcasts.

But you have to actually use programming patterns in contexts where you dig them forward, and you follow them like a recipe, without knowing for sure how to solve the problem. Because then you understand the hidden value: When you're using a programming pattern, you can program an incredibly smart solution without being incredibly smart. That is also why using programming patterns when you fully grasp the benefits is not as rewarding at all. If you fully grasp them, then you're not making a solution that would otherwise be beyond you. While it'll almost certainly keep things tidy and smooth, there is no leap of faith, and no reward which you couldn't have claimed without knowing that your solution was indeed a pattern in the first place.

It's not entirely unlike a habitual clubber discovering the safety and luxury of cabrides for getting home. A task which can otherwise be difficult, and requirre much resourcefulness and brainpower (in the situation, at least) like sticking to the sidewalks while walking in the right direction, is suddenly made easy because of the reliance on something otherwise seemingly unreliable - that a nice fellow in a big leatherseated yellow car will just happen to come by and pick you up when you're drunk and need to go home.

There's a price to be paid for using patterns, as well as taxi cabs, though - you must either know of them ahead of time, or be able to discover ones that'll solve your problem in your time of need. And if you go looking for one that doesn't exist, it'll waste your time when you likely need it.

Since programming is a highly logical discipline, and since it is extraordinarily simple (humans just naturally happen to suck at it really badly), it is a great place for patterns to live, but there is nothing that prevents pattern based utility in other contexts. In fact, the reason it's called patterns in the first place is because some dude a long time ago coined the pattern term in relation to real physical architecture, buildings and such. There, they were akin to a methodology very similar to programming patterns, where relying upon the methodology would provide certain predictable (nice) results.

Yeah....I'm not great with giving credit to my references. Google it if you care so much. I'll put them in when I have them handy.

And now we're getting to the reason I'm making this blog post. Programming patterns absolve humans of logical responsibilities and relations, but allow them to simply rely on proven-to-work methods of working. A programming pattern, in this regard, is almost similar to an algorithm which is human-executable - in fact the algorithm analogy holds up exceptionally well, since many good programming patterns are inherently integrated into programming languages as these languages are developed.

Programming patterns are, in a word, context free - and that means they are equally applicable for managing non linear dialogue. Since I have yet to encounter a programming language developed specifically for writing non linear dialogue, I highly doubt there is one which implements a great many patterns. Rather, I would not be suprised if developers had instead taking to develop toolsets for managing solutions to common problems in writing non linear dialogue. That would probably be a much better place to look for such patterns.

In fact, I know of a few game developers who have taken to developing their own makeshift methods for developing non-linear dialogue. I have heard of people utilizing microsoft excel, of all things, for keeping an overview.

That is not a satisfactory situation. Something must be done. Something that abstracts away the logically simple and mundane, but to humans feverishly complicated, management of variable context structures within writing. Without it, I fear we will be stuck with relying on exceptional people for designing around this obstacle to non linear stories, rather than facing it head-on with a multitude of ordinary writers that have dedicated themselves to crafting beautiful natural language constructs, rather than boring boolean logic. That last part would be my job.

Logical theory and how it relates to writing non-linear stories

A subject of great interest to me when I was younger was non linear stories. There was something magical about the unassuming interactivety that preprogrammed addaptive dialogue conveyed to me. Perhaps it's that I was listened to and had a say; perhaps it's that I was responded to regardless of being a kid spending the afternoon at home with only TV, homework and the computer for entertainment. It doesn't really matter why, but I was definately starved, and games with nonlinear dialogue in particular fed me quite well as I sunk my teeth into them.

Now, having come to understand at least part of the structural intricacies of languages, and more specifically how to translate between languages, it seems like a good idea to re-examine non-linear dialogue. It'll allow me to put my old hobby into the context of what I've learned since then; and hopefully I can boil down that which I used to like into rules which are more generally applicable than "oh yeah, they did this cool thing in this game I played ten years ago, and it was soooo awesome but I'm not quite sure why!". If I succeed, which probably won't happen in this entry, that should improve the way I think about narratives in general, and nonlinear ones specifically.

I'll try to come back to applicability for games later.

Essential to non-linear structures is a grasp of logical languages. I call them logical languages only to differentiate them from natural languages such as Englsih - which sounds moronic as English _is_ a logical language. The point would be the link of association - languages are associated with communication between people, or in the case of programming languages, the decleration of data manipulation mechanisms.

But technically speaking, anything that defines a set of legal operations and results (or meanings) of those operations can be thought of as a logical language. This is because it allows the user to express meaning through the use of the operations. In the case of natural languages, it should be obvious that there often is no set definition, and that the meanings conveyed may in fact be unlimited.

I bring up logical languages, because in order to make interesting non-linear dialogue, we need to utilize a context free language to organize the natural language expressions in a non-linear fashion. This limitation is two-fold: we cannot program a computer, which is requirred to "run" the non-linear dialogue, without utilizing context free languages (yet, at least, because computers have no grasp of language-contexts at this stage of technology), and we can't impress humans without using natural languages; and argument for the latter follows:

In simple terms, the most important aspect of any language remotely interesting for humans is context. This is in part because all natural languages are defined by their context (even their grammar, alphabet, spelling and semantics are, in the grander scheme!), and in part because the context can never be fully known, remembered, or even understood, making the reading of almost any context-based text a highly individual experience.
Even normal conversation has this element of uncertainty, which then means that every expression we make carries with it a choice in how we word the expression, and a result, how it is understood. Making things all the more intriguing is the fact that we don't know the result, the impression, our expressions have on our listeners before we have a chance to listen to some of their following expressions.
To hammer in my point agai : Our only basis for understanding those who speak to us, and coinstructing expressions for those who listen, is context. All of our decisions with regard to how we communicate comes from how well we understand the context, and how quickly we understand it.

This fairly complex work is handled by us at automatically, without conscious analysis. That isn't to say that we aren't fallible in this endeavor - we're very fallible, particularly concerning areas where no reliable and common context exists as the basis of communication - but we're very good at it, and the enjoyment that comes from conversation probably is in no small part due to how it flexes and excercises this part of us.

The idea I proposed above - arranging natural language expressions in a non-linear fashion - is not the only solution. It is also possible to generate natural language expressions utilizing context free languages, but these, while usually gramatically correct, reek of simplicity and are exceptionally mundane by natural language standards.

So, we're currently left with the organization of chunks of natural language by utility of context-free mechanisms language mechanism. Essentially, this means that the only people really qualified to design non-linear dialogue are people who understand how context free languages work, and are able to use them. This is a discipline which is not derivative of being a writer, but rather of being a programmer, which is a large problem.

Having a firm grasp of clear-cut expressions in context free languages, the programmers forte, often means having a sub par or completely ruined grasp of natural language constructs. Either direction is not exclusive, to be sure, but compared to the precision of context free languages, many programmers are likely to find natural languages imprecise and unfullfilling to deal with.

So where am I going with this?

Well, my idea is, more or less, that because you can introduce context-based values to a context free language, you can write touring-compatible languages within the confines of context free grammars and languages. This is what allows for the various branches to exist.

But because this is all touring compatible and originates in a context free language, it means it's possible to translate, or compile, the dialogue into wholly natural language based strands and examine them without the branching context.
Sortof like unfolding a tree into a number of linear paths. So, it may take a programmer to construct the strands, but a writer can edit and sharpen the strands.

While it may well be technically tricky, it is therefore perfectly possible to develop a branch revision structure that allows a multitude of writers to pour over forks in the dialogue while keeping the dialogue inherently compatible. Of course, this is what you need to develop tools for if you want to construct non-linear dialogue.

I'll get into, another entry, why exactly the tools are necessary - but this blog post should explain why the tools are possible. Also, I want to adress the problem of having several writers on a project; since the writers have different personal natural-language contexts, a certain degree of meta-management is necessary every time you add another writer. Since the number of writers means a decrease in the common denominater, so to speak, managing a common context will necessarily become paramount in such an endeavor as the team size grows.

But more on that later.