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.