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.
mandag den 10. november 2008
Concurrent behaviours within non-linear dialogue
Etiketter:
concurrency,
games,
language,
Logic,
non linear dialogue,
stories,
writing
Abonner på:
Kommentarer til indlægget (Atom)
Ingen kommentarer:
Send en kommentar