Tejlgaard

burgerman

2010-10-09T09:53:00.000-07:00

here he is!

Are both of these women the same?

2010-08-28T07:06:00.001-07:00

This is slightly ridiculous to put on this blog, just as my character design was, but since I'm currently just using it as a place to dump images that have some type of meaning to me

Left picture is Morrigan for biowares upcomming dlc for dragon age. Right picture is some woman from the trailer for dragon age 2. Now, initially, I was convinced the woman on the right wasn't morrigan, untill I saw the piece of pre-rendered art on the left. Now I'm no longer sure - add 15 years to the woman on the right, and I could see her turning into the one on the left.

Why does this matter? It doesn't, really....it's just a part of me speculating what the latest dlc, and what dragon age 2, will have as their focal point....I can't shake the feeling that dragon age: origins is really the origin story of the so-called "god-baby" that this morrigan person and the protagonist can have together.

Continuing to develop the character concept in photoshop

2010-08-20T12:48:00.000-07:00

a small character concept I been working on

2010-07-24T04:49:00.000-07:00

I blatantly stole someone elses picture of stilgar from dune, and I'm currently modifying it with photoshop to get him to look like a D&D character I'm building...

Handling player state

2009-12-28T16:17:00.000-08:00

A players state is the data describing the value of all the variables pertaining to things which might happen in the game.

If that sounds like "blabla", it's because I was extra careful to word it unambiguosly, but it's probably failing utterly to communicate the basics of what I mean to describe.

So, let me give you an example: the players charactersheet in dungeons and dragons is part of the players state. Abstractly speaking, values which the player has not had a chance of influencing yet are also part of the player state; the lack of a level 20 ability on a level 10 character sheet can technically be thought of as part of the player state, because it is implied by the player state.

Now, as you can imagine, there's one heck of a lot of variables in the player state in a computer game: the player characters XYZ coordinates in the 3d space he inhabits, for example, are part of it.

All of these variables, together, form a cartesian product. A cartesian product is something usually used in math, but the short story is, it's a function, it's sometimes useful, and while it's definite, it's usually not finite, and it's not usually something you can picture in your head unless you're rather brilliant.

I bring it up, because understanding how to handle player state, as a game designer, inevitably ties in to handling the cartesian product: the cartesian product of the player state variables is the collection of all the possible permutations of all the variables.

If the variables were strength and agility, and those variables went from 1 to 3 each, the collection of permutations would be:
(str=1 agi=1,str=1 agi=2,str=1 agi=3,
str=2 agi=1,str=2 agi=2,str=2 agi=3,
str=3 agi=1,str=3 agi=2,str=3 agi=3)
Here, I've seperated each permutation with a comma.

That is, in other words, the cartesian product, and you can hopefully see what I mean when I say it is this product you need to keep in mind when designing a game...going by the above example, if the player only gets to level his stats twice, with a free choice between agility and strength, if you want to cover all your bases in a quest, you need to deal with both players who are 2str2agi, 3str1agi, and 1str3agi...since that's the possible player states at that time, supposing the player is forced to use level up points.

As you can see, all of these are present in the cartesian product above...the cartesian product, in other words, is the source of possibilities the player can expose the designer to, though it almost always contains permutations that couldn't happen at a specific point in a game.

Games are, by their nature, fun because they make manipulating the player state difficult. Handling player state, then, becomes a question of designing fun difficulties for the player. Thinking of the game designers job in this manner makes it seem ever-so-slightly sadistic, but regardless of what it seems like, it is what it is: You're out to stop the player from getting what he wants, to make him fight for it, and to (hopefully) make him beat you whilst he retains the illusion that you wanted to win too Which you didn't. But shh, lets keep quiet about that.

There's more to it than simply designing fun roadblocks though; you want the player to feel as though you are not limiting him, but rather, that he is limiting himself. For instance! the classic jump puzzle, while not very fun, makes the player limit where he walks because you punish him if he does do something else. Think of a room you as a player must walk across. If the state possible within the room is simply the entirety of the room floor, the room is boring. Clearly, where the player is able to walk has been limited by the designer. Put a chasm in the middle of the room, though, and have the player jump over the chasm or be forced to restart at the start of the room, and suddenly, both the player and you limit the player; see, the player limits himself by wishing to avoid the chasm. It doesn't really matter that you designed both obstacles; it doesn't matter if the chasm is a very small challenge to overcome...because it accomplishes the most important thing: the player is suddenly thinking in terms of what he wants to do, and what he wants to not do; not in terms of what you want him not to do.

Since we, as game designers, are forced to make sure our players don't do certain things (walk through our walls for example...he must stay on the path, as it were), it serves us well to try and design the fashion in which the player can change the player state in such a way that he inhibits himself, and thinks in terms of what he does and does not want to do. This, we do by making sure the player can be punished, if only ever so slightly, by being careless.

And that's really it; we should focus on making the hard edges in the player state soft, whereever possible...so instead of being constrained on a huge balchony, the player is on a huge balchony and part of the railing has come off so the player could possibly fall over, if he was careless.

This probably sounds...like a weird hypothesis, but I believe that this type of design is part of the reason Batman: Archam Asylum feels exceptionally free and open, in spite of being quite linear, and oftentimes quite constrained. The fact that you have choice, even if it's sometimes useless and clearly bad choice, it keeps the player making up his mind out the limits of the world, keeps him thinking...and that's really enough to make the player forget about the game designer and his artificial boundaries...

Ancestry as a game element

2009-12-26T13:36:00.000-08:00

The idea of bloodlines and ancestry - that one person is, merely because they were born from certain parents, important and carries within them a particular destiny is perhaps at the very root of elitism.

For that reason, I'd like to make the case that genetic (inherited) memory and will is an excellent concept for an interactive narrative.

Genetic memory can take many shapes and forms, but it's irremovably tied to ancestry - and your mum & pop. A person with person with a bloodline with genetic memory is, as a result, tied to his mom and dad. It could be further manipulated, such that only certain genders receive the full extent of the gift, as well as the ability to allow their children to inherit memory...these genders would not necessarily be set in stone, they could be alternating, or use some type of pattern, but the long and short of it is, a discussion of entitlement and strength can be brought into the narrative.

Genetic memory - which might be muscle memory, memory of crafts or meditative techniques, as well as memory of what has happened to every person in your bloodline coming before you - could be used as an excuse for attributing the players character with extraordinary abilities, and perhaps even the ability to converse with or be possed by his ancestors at his will or theirs.

It opens up many possibilities, but unlike so many, many stories, this one can be kept groomed - the Dollhouse TV series is doing something similar, but it's had a very difficult time getting going because it attempts high internal consistency, buffy the vampire slayer does it a bit, but only as a minor subplot, assasins creed does it, but doesn't use it for anything other than a starting point - and it's one of those "one magic thing" that people will accept in a narrative, yet it remains very specific.

When I say, one magic thing, it's because most stories only have one thing out of the ordinary - a focal concept. For example, if we were considering a world where everybody posses genetic memory, it wouldn't be "one magic thing" - it would merely be part of the setting. But take bumblebee in the transformers movie - it becomes sams car. We, as receivers, come to understand that we follow sam precisely because he is, through coincidence, fated to receive bumblebee. If it had come to someone else, the story would've been about them instead, not about sam.

Sam, however, cannot win the lottery the same day as he gets bumblebee, which would be another thing so unlikely that it would qualify as "the one magic thing". See, as unlikely as it is that a giant spacerobot becomes your car, it's part of the plot and the setting that it _must_ happen to _someone_ - the movie merely chooses to focus on the person it happens to.

But noone gets to be on the receiving end of two huge coincidences within the context of the same story - it's almost unheard of.

The thing about genetic memory is that it's not general, it's specific - it's not "magic", for example. If it had been magic...sure, our protagonist could have both magic and genetic memory if those things were tied together, being part of the same ability, but then, our protagonist would be much less predictable. Magic can do lots of things that the receivers of the story won't be able to predict; not so with genetic memory. It's nice and tight, but at the same time, presents a large amount of solutions.

So not only can it be used as the basis of a major narrative due to the relationships between characters the ability inherently projects and explains, it can also be used because it makes for interesting adventure and problem solving!

Now, notice that I say interactive narrative - I think this type of thing fits with narrative that allows choice particularly well, because ancestral preconceptions necessarily try to take choice away, and having a player deal with that seems like it could be almost existensial.

Progress on the conversation editor

2009-12-26T13:19:00.000-08:00

Since I started working with off topic productions as the primary use case for the conversation editor project, much has happened with my plans.

As it turns out, the ideal tool has not been to handle persistence from within the context of the program itself, but rather, to merely load and save to file and have another program handle the persistence...it scales back the responsibility of the storyline editor considerably, but it also means that the writers will be stuck with generalized persistence management tools rather than custom tailored ones - at least for now.

We currently rely on an svn server to manage this - and in the future, if I do solve this problem with a custom tool, I will likely rely on the svn protocol. It works excellently with xml serialization, which is what we use now and what we'll be using going forward. There's an odd, but completely bearable, workflow currently tied to working with the program which is, currently, called Fabula.

The current Alpha version is done, but major refactoring has already commenced...the early focus has been on being able to model threaded conversations, which has been a success, but it's a far cry from what I eventually want to do. I'm afraid one of the things we will want is an emulator, which I will have to program after the next batch of minor changes has been implemented and refactoring is done. Fortunately, the theory behind everything is sound, and what I've used to program with is not likely to deprecate anytime soon...the only worry I could possibly have is that microsoft will deprecate WPF entirely, but that doesn't seem like it'll happen within 8-10 years.

Some stuff clutter has been used for so far

2009-04-12T04:45:00.000-07:00

http://www.youtube.com/watch?v=arL_-tQndzI&feature=PlayList&p=9FAEABEC2B33B600&index=0&playnext=1

I slapped together a playlist on youtube of some videos that demonstrate applications slapped together with clutter.

If you're wondering why there aren't any more videoes outthere, the answer is simple:

Clutter is only about 2 years old, and Intel only purchased openedhand in september 08. It hasn't even been released in version 1.0 yet.

Perhaps of some interest is the fact that the iphone is also fully capable of running clutter applications, at least with regards to hardware. The same can be said for all symbian smartphones, and many of HTC's windows mobile smartphones, though again, it might not be easy to rig the software to allow it to happen.

But the important point is, if something is written using the clutter library it's not particularly constrained or encumbered by graphics hardware.

The theoretical case for using the clutter framework in an actual game

2009-04-12T00:55:00.000-07:00

I've been trying to wrap my mind around the clutter framework and the accompanying technologies for a while now, because it seems to be a powerful library that makes a lot of features easily accesible.

What might not be apparent, is that the problem it solves - the rendering of 2d graphics - is a problem in the first place. So let's examine for a moment what it actually is: A library that utilizes opengl as a backend for drawing hardware accelerated graphics.

Why is hardware acceleration necessary for a 2d game in this day and age? I hear you cry.
Well have a look at this:

http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Early_debate

Excerpt from the linked section:

"By 1998, even the much-maligned S3 Virge was substantially faster than the fastest Pentium II running Direct3D’s MMX rasterizer."

The S3 virge, presumably, was an elcrapo graphics card with 4 megabytes of VRAM, that might've cost about 40$ to slap into your run-of-the-mill prefabbed consumer desktop computer at Dell or HP. The fastest Pentium II, by comparison, must've been about 6-700$ or so, not even available in preassembled computers unless specifically requested.

The perspective this is meant to impress upon you is this: Hardware acceleration rocks, software emulation sucks, and this has been the case since 10 years ago, with the gap in performance/price widening every quarter ever since.

Ok, so we need hardware acceleration for the graphics. How do we get that?
We use a library. Libraries are collections of functional code that performs operations detailed in an API. A library is different from a system call in that a system call is implemented in the operating system, whereas the library resides in a little bubble attached to the operating system. Indeed, it "talks" to other libraries and hardware as directed and permitted by the operating system.

Even Direct X, which is microsofts multimedia library, is in a bubble attached to the operating system. While it's true that you cannot run windows without having some form of direct x on your system, direct x is a library because it does not belong within the windows kernel. As such, it's a library in it's own right. Microsoft also includes a version of openGL with Windows.

So why not simply use Direct X or OpenGL? Why use a library build on top of another library?
Because OpenGL, for example, is very simple. It only allows a program you write to communicate with graphical hardware through some very rigid functions.
Textures are a common concept within graphics rendering; it's a bitmap projected onto a geometric shape. But to OpenGL, a texture isn't a file on disk; it's a bitmap in memory. Converting a file on disk into a bitmap in memory is a function which OpenGL does not provide. So you need to either program it yourself, or find another library which can be used to read files into memory in a way that makes the final result compatible with OpenGL.

But Mads, you say, surely there are 2d libraries with hardware acceleration other than OpenGL and Direct3d, which are, after all, predominantly 3d libraries?

No, no there are not. Yes, there are 2d libraries, but no, they do not have hardware acceleration. Look at the firefox browser you're probably using to browse this blog right now. It uses the Cairo library. It's not hardware accelerated, and it shows. That's why web browsing is so processor intensive compared to how piss poor the graphics are. The responsiveness of the firefox webbrowser is _not_ good enough that the same kind of thing would go over well in a game.

So, clutter. It's a library that supports text rendering (which is a motherfucking bitch to implement yourself), textures (as in, you can load them from disc and manipulate them using an established framework), and fluid animations, all in an easy-access framework. It's also brand spanking new. And it's primarily a 2d rendering library, but perfect for working with many layers and grouped things because it has a scenegraph and a z axis thingie.

Sure, it's meant for designing interfaces, but that doesn't matter; if it's hardware accelerated, performance will probably be up to snuff. It even supports rendering of videos onto textures, and yes, this can be hardware accelerated as well.

About system requirements:
On ebay, for less than 200$, an eee pc 4g, the lowest performance eee, can be had. It's intel GMA900 graphics card can hardware accelerate opengl 1.4 - which is what clutter uses. Now seeing as intel owns openedhand, the developer behind the clutter library, this should hardly come as a suprise - the intel GMA 900 and above almost exclusively make up the graphics hardware in netbooks, and intel purchased openedhand with the intent of using clutter for rendering the UI on it's moblix platform....which is the operating system designed to push netbooks and mobile internet devices developed by intel.

Making clutter run well on the GMA900 and above, as a concequence, is likely a high priority at openedhand...

This implies that clutter will be a future-proof rendering option for a 2d game, and it also means that any 2d game written with it will likely perform well even on future mobile internet devices. Oh, and it's a cross platform library, of course, so games written with it run both on windows, linux and mac os x.

But if running on tiny, low performance netbooks isn't good enough, the first geforce graphics card to support opengl 1.4 is geforce 4, ti4600, which was the top of the line model back in febuary 2002. Every geforce model since 5xxx and forward has supported it as well. Same goes for every radeon including and above the 9500, which is also ca. 2002.

It's also likely that most laptops support it, though it's difficult to say because laptop gpu's are considerably worse documented; but anything both nVidea and ATI have been shovelling into laptops since 2004 ought to support clutter, and it's supported on _all_ of intels graphics hardware.

Finally, about licensing: Clutter, and all libraries it uses and works with, is released under LGPL. This means that it's legal to build proprietary software using the library, but that anyone who does so, ideally, allows people to upgrade to new versions of the libraries used if they want. I haven't figured out how difficult this aspect might be, yet, but I don't foresee any problems.

The Spy Blimp

2009-04-06T22:15:00.000-07:00

I might try to draw up some sketches at some point, but for now, I want to document a concept here for posteritys sake.

Spy blimps are a whole world of awesome. I spent an hour or so designing a particularly cool one in my head. Well, to me it's particularly cool.

See, blimps have always been fascinating to me...it's one thing to fly, but it's quite another to remain airborne. A propeller airplane is little more than a bird - it can get about much faster than walking or jumping, but it's still severely constrained. What goes up must come down and all that.

I've never been in one though...closest thing I've been in was an airglider airplane - a plane flying on airstreams, very light, requirering no engine...but, while capable of flying quite far, they must keep in motion, must maneuver with the wind, must...well, you get the picture. They're inhibited.

Air baloons, I suppose, are kindof cool too....in the same way hitchhiking is. You never know quite where you end up, but at least you're getting somewhere. It's, again, ihibited.

Not so with blimps. Blimps can remain airborne for as long as they want, like air baloons, but they can go places, like airplanes....Perfect!

Well, when I say blimp, it's because DARPA has been contracted for something the popular news outlets call a spy blimp...what I really thought up is an awesometastic derrigible. See, a derrigible has an internal construction and an internal structure, and the outer coating is not a balloon itself...rather, it's just there to cover the structure of the craft against the elements. Indeed, large derrigibles can be thought of as assemblies of helium or hydrogen balloons, embued with other properties (and engines!).

Large derrigibles are powerful, and are able to lift quite a lot of weight, but the classic ones are run on hydrogen as carrier element, which is highly volatile. The Hindenburg, greatest airship ever made (...somewhat similar to the titanic, greatest passenger craft ever made....) failed on it's virgin journey.

...and, at this point, I realize the irony of scribbling an idea down and the scribbling taking so long that I'm no longer in the mood for it when I just get to the important bits.

But fuck it:

Use carbon nanotube firbres for the internal balloons, rigid enough to maintain shape even when pumped empty of air
vary balloon displacement by means of nanotube fibre patches that can vary in length when electricity is applied
stick solar panels up top
use two dirrigibles side by side with a bridge inbetween
allow dirrigibles to alter outside shape from fairly air-streamlined to completely boxy in order to be rader invisible, using light tent-like material
coat the entirety of the bottom of the airship in blue-grey-black epaper for live action visual cammouflage
built a greenhouse on the bridge section for food
keep stock of new rapid-delivery lithium-ion batteries as those developed at MIT for rapid electricity availability at all hours (fast enough to power laser cannon batteries or railguns - stuff with infinite ammo...probably run dry in 4-5 shots, but hey, laserguns are LIGHT)
keep weight ratio low to be able to go higher than all jet engine missiles and hopefully out of range of rockets using supperior carbon-nanotube balloon goodness
Keep giant kites in top compartments for blazing speed on the jetstream (and maybe even for powering wind turbines...the sun may be blotted out by dust, but the winds will never cease, and ultra violet rays can grow foods! mm mm good)

Ok I think that's all my crazy ideas, for now...more, better, later.

Virtual Machines, Python, Clutter and Ubuntu

2009-04-03T23:04:00.000-07:00

...I'm slowly making progress while working on my dialogue editor project.

In working with my first open source project, I'm finding that a lot of exceptional effort goes into the system - and that it's really quite elegant.

But it's also a bit of a nuisance...which I can mostly attribute to my own expectations and background. See, I've always considered myself more of a visitor whenever I've used linux, not an actual, permanent user. I've found many neat features in it, many that I'd increasingly like to combine with my windows rig - but it's only on this project that I've come to the conclusion that serious programming will often necessitate that you do it from a 'nix system.

See, I came accross this excellent UI framework called Clutter, being developed by openedhand. It's drawn using OpenGL for some parts, but native operating system rendering for fonts. And it has bindings such that it can be used from python.

Most UI libraries will give you one or two of these - an extensive library of premade functionality, excellent text rendering, hardware accelerated graphics rasterisation, and an elegant application programmer interface.

Clutter gives all 4. It's also a so-called copyleft licence, meaning that code which uses clutter can be proprietary if need be; but any modifications of clutter itself need to be published as either gpl or lgpl.

So it's great and all, but there is a catch. Clutter is a bitch to compile because it requires a lot of other libraries as binaries...and of course, neither clutter itself, nor the other libraries, are available as binaries on windows.

Enter VMware Player by VMware, and a virtual machine, called a virtual appliance, with ubuntu installed.

I managed to get it up and running in the course of about 4 hours....and that's on linux.

Like I said, it's a bitch. But now, it's all up and configured on the virtual machine, so work can soon begin...I do need to build a production pipeline soon, though, such that I can do test-runs on the native host machine, which is the next thing I'll be doing, and from there, well...hopefully, I'll link the virtual machine up with a repository, and have it run a virtual file server of compiled binaries....and _then_ I'll be able to work on the actual application =P

The characteristics of data persistence

2009-04-02T16:51:00.000-07:00

Data is structured information. Persistence is steadyness: A persistent state is a steady state; this is particularly true when the word is used in the context of data. Here, I will be addressing persistence with regard to a particular type of data: Digital Text.

So...Persistent data is data you expect to stay the same.

Well duh, you say. Don't. Let me go over a concrete example of how the implementation of persistence may vary:

Programming languages deal with persistence in different ways; the most elegant way is, without a doubt, the functional programming languages, such as Scheme and F#. Functional languages do not accept mutation of data; that is, once data has been entered, it's there, forever. You may, at some point, lose the ability to address it; but you'll never be able to change the data at the end of an address.

This may seem like a bigger burden at first than it really is: Functional programming languages also allow you to create the (seemingly) same adress multiple times, so rather than changing the data at the address FOO, you can create a new address FOO and put the changed data there instead.

So even if you do not allow data at various addresses to mutate, you do not necessitate creativety in coming up with new meaningful address names; you can just reuse old ones.
This does make it more tricky to get at the old one (you need to get at it by writing something similar to "FOO; THE OLD ONE" in the address field), and it does make for confusing programs when the address FOO does not always refer to the same data (remember, all references to the old FOO within your program still point to the old data, because that's where they pointed before you introduced the new FOO).

The point is, however, that it's perfectly plausible to never erase anything, and to never change anything that anybody else has been working on, in the context of any advanced system. Contrast this to java, a complex programming language for modeling complex systems.

Here objects are passed by reference; that is, if a Salesman object passes a Car object reference to a Customer object, and the Customer object then makes a change (mutation) in the Car objects Wheeltype attribute, that change will also be apparent to the Salesman if he still has a reference to the Car object.

This behaviour can be destructive if the Salesman object was counting on the contents of the Wheeltype attribute to stay the same in the car object: If persistence was somehow important, then in this case, it would have been broken.

Alright, now that I've given some concrete examples of persistence, so you hopefully have a grasp of why it matters (at all), let's look at the how and why of the whole thing:

There are two defining questions to data persistence:

- Why persist?
- How do we persist?

The answer to the first one is: Because you might want to use it later.
The answer to the second one is: By making sure that we are able to address the data at the point where we want to use it.

Understand, then, that the relationship between not persisting and being able to address data is crucial: If you have 100 data articles, and you choose to only persist 50 of them, then you only have to keep track of 50 data addresses. Perhaps this seems like it's not that different from keeping track of 100 data addresses, but try to consider the receipts you get after purchasing groceries in the place of data articles. If you save 100 of those rather than the 50 most important ones, when the time comes to dig out the receipt for your new television set, you'll have to rummage through twice as many articles before coming upon it.

Not persisting the grocery receipts - or the data addresses - makes it quicker and easier to discern the useful ones from the useless ones; it makes it quicker and easier to address that which you are most likely to want to address, and as a concequence, it makes your collection of data more powerful and user friendly.

This is all well and good in a single user environment, but in a multi user environment, things tend to change. Whats important to one person could seem useless to another, and suddenly an important article is missing from the collection.

The answer is, of course, that deletion of any kind is a very primitive type of ordering in a persistent data set. It's actually hiding an article very very well; rarely does i actually phase permanently out of existence, it just becomes so hard to get at that it's no longer worth it to retrieve it. It probably only has such appeal to humans because we can safely forget about things we delete, just like things we throw out.

The same could be accomplished by using a less effective hide operation than deletion - instead of throwing the grocery receipts out, you could toss them all in an old shoebox, so that they're there at least, even if hidden behind a decidedly user-hostile interface. But even the shoebox will repressent a useless article to some, though, so it might get deleted eventually...unless it's impossible to delete, as it would be if it were an object in a functional programming language.

So now that we understand that the goal of persistence is the ability to use later, and that deletion is a type of ordering that simply makes us more _likely_ to use a collection later at all (because it becomes more powerful), we can toss the idea of deletion out the window for good...at least when it comes to small data.

Simply put, there are other types of maintenence that yeilds better results than deletion, often in much less time because there's far less finality to it (ie. it makes the collection more powerful, faster), so as long as size is not a factor, there should be no deletion. Since we're dealing with digital text in this article, it's verifiable that size is, indeed, not a factor.

This makes for a conclusion to this article: Everything should be persisted. Everything that is likely to be useful should be systematically ordered. And finally, efficient algorithms for ordering and retrieval are essentiel to maintain the power of a collection.

Status on generic storyline editor, simplified:

2009-03-29T09:40:00.000-07:00

Persistence:
For version 0.1, will be using user-activated object serialisation.
For version 1.0, will be using atomic timestamped patches that are pervasively stored, backed up, and synchronized when possible.

Platform dependence
All versions will likely be platform independent, both with regards to OS and processor. Python and clutter will be utilized for the bulk of the work.

Programming Language dependence
Python will be utilized for main development, allowing for mid-level portability.
For version 0.1, this is not a concern.
For version 1.0, XML export must be implemented and fully supported.

Network dependence
This will not be necessary for any versions. Version 0.1 will not support it.
For version 1.0, it will be necessary for pervasive synchrony.

Command response delay
No delay is acceptable in any versions.

User Interface
0.1: Basic experience with a basic font. Functional auto-placement and folding algorithm.
1.0: Pixel-precise user-customizable fonts, dynamic and fluid interface experience, with panning, zooming and scaling all incorporated, and dynamic folding and placement of everything. Placement structures and colour schemes incorporated to allow writers to use their visual memory.

Backwards and forwards compatibility
0.1: No focus is given here for this release.
1.0: Fully forwards and backwards compatible, as well as allowing for different branches when necessary. A simple tool for merging, splitting, and maintaining synchrony across versions and branches.

Programming language and graphics API for the generic storyline editor

2009-03-29T08:46:00.001-07:00

I've been examining a couple of different programming languages and API's. The first is java and swing; java is the most widely used programming language, and almost always the most efficient one in terms of the number of necessary CPU cycles while maintaining stability.

It is, however, prone to several problems: Java garbage collection leads to annoying "jitter" because it isn't designed for maintaining a smooth user interface. Secondly, java swing looks weird on both windows and nix systems, being visually different from native window rendering.
Finally, java is...well, annoyingly heavy to write.

C# and windows presentation foundation is option number 2...C# is a smaller and less utilized language than Java, but it's only properly supported on microsoft platforms. Windows presentation foundation, while teoretically just what I'm looking for, is currently under-utilized as well. I don't quite dare jump on C# for these reasons...well that, and I don't like being limited to microsofts platform unless I have to be. C# is also a fairly heavy language to write.

Third option: Python and Clutter or Cairo. Clutter is a visual open source API intel is developing that can do all sorts of neat tricks. Python is google's favoured programming language, and they're currently actively developing solutions to it's biggest drawbacks. Cairo is a visual open source api that isn't being shouldered by any specific company, but it's big enough that the mozilla foundations gecko rendering engine, used in firefox, relies on it.
There are bindings from python to both api's, meaning that they should function with it; python is, itself, a language with a fairly large user base (bigger than C# and small than java), and it's dead simple to write and use. Very fast. And Clutter and Cairo look excellent; not necessarily like something that runs natively on any one system, but then, it's so fancy that it looks more next gen than simply different.

I'm hoping to use python and clutter, and if that doesn't work out, python and cairo.

Status on the generic storyline editor

2009-03-28T16:52:00.000-07:00

My design needs to deal with the following:

Persistence
Syncrhonisation
Platform dependence
Programming Language dependence
Network dependence
Command response delay
User Interface
Backwards and forwards compatibility

Each area poses a unique challenge. Let's go over them one by one:

Persistence is necessary because an editor by definition needs to produce something persistent. But there are several kinds of persistence, and some are more valuable than others. One type is file serailization; this is a snapshot of the current results that is only readable by the current program and perhaps a hex editor. Another is XML-based serialisation; this allows for synchronization, limited interoperability with other programs, and limited readability by humans by means of standard text editors; but it's still limited to snapshots. The third, most advanced, and best option is persisting every change made in the editor along with a vector timestamp, an internet timestamp (if available), a local timestamp, and a user ID, and storing it as an atomic patch.

Synchronisation is necessary if more than one person uses the editor on the same project, or even if that one person works on the project from several locations. Backup is often considered an intrinsic part of syncrhonisation, because if you have access to synchronisation, you have access to backup.
There's a drastic difference between single-user and multi-user synchronisation; it's generally acceptable to use manual synchronisation between workstations, as well as manual backup, when there's only one user; further, it's also generally accepted that if that one user were to make different changes to his project at two different places without synchronising, all the changes made in one of the places would be lost upon synchronization: this limitation is accepted because a single user can generally "work around" this situation such that it never happens.
But for multi user synchronisation, it's generally necessary to allow simultaneous work in several places at once without having them manually reenter all the changes made in all but one place, in order to synchronize them.
Ideally, multiuser synchronization is either synchronous, or asynchronous but automatically run at set intervals and/or on demand, and when it occours, it usually does all, or almost all of the work without user intervention for solving conflicts.
Typically, synchronization also provides sync reports that go into detail on what was changed with each sync, so as to keep all users up to date. Synchronous synchronization is easy to implement, because everything is sync'ed all the time, but usually lags things down because all user clients need to be constantly chattering about whats happening all over the place, and demands solid network stability to the point of being always-on. Asynchronous sync is much harder to implement, but poses no strict network demands; instead, users must provide ID's, abd must help solve conflicts, but in return they're likely to get a snappy and free user experience.

Platform dependence is really OS dependence these days; all work done is done on PC's, so the only question is if the editor is able to run on all platforms natively, or if it has to happen on virtual machines. Platform independence is generally considered the more future-proof alternative, but it can pose some strict interface limitations because platform independent interface libraries generally look odd on most platforms.

Programming language dependence is closely associated to platform dependence; choosing a language will generally lock you in to using just that one language or having you incur rather tremendous costs, but there are different degrees of lockin. Python, for example, is often the second or third language that gets bindings to access libraries of another language, meaning you generally have several languages to fall back on. Some languages are also able to run on several different virtual machines, or interpreters, which can be a boon for future-proofing. Finally, some languages are exceedingly interoperable, allowing you to abandon them when a better one arises by means of automated translation.

Network dependence is just what it says; will the program need net access to function or not?

Command response delay is really a measure of how snappy the program is. If ever a user has to wait for the program, he becomes a _lot_ less productive; a short delay generally translates to a break in workflow, which makes a 10 second pause translate into several minutes of lost work. Some technologies _cost_ on this front; so it's one of those things that isn't an issue when you start out, but if you make the wrong tradeoff somewhere along the road, suddenly you have a useless program, or one with major drawback.

User Interface is just what it says; there are good user interfaces, there are clunky ones, there are bad ones, and there are ones that only a programmer can use, usually by command line. What type of user interface you need depend upon the target usergroup, and your ambitions with your application. The target audience of this program is fairly broad, since it simply means to get at creative individuals with no other qualifications, and they work better if they have a better interface. The ambitions are also high, of course, so that doesn't improve things. This makes the interface bit quite important.

Backwards and forwards compatibility is a matter of allowing the users to get at the program early while not hanging the sword of damocles over their head: If users are scared that future versions of the program won't be backwards compatible, they won't be inclined to use it.

So, now that we have some design parameters up, let me follow through with what I've been thinking, and how I've planned to tackle these issues so far...:

I've allowed the idea for a generic storyline editor to simmer for a while now, since about december 08 when I last did serious work on it, and have now come back to it.

And when I write idea, I mean plan. Traditionally, it's considered counterproductive to plan too far ahead concerning software development; rather, rapid prototyping and modular approaches tend to make for a far smoother creative process with far less grief over wasted effort.

It could be considered a mistake, then, that I've allowed my idea to linger for as long as I have. Thing is, allowing time to pass tends to reveal obvious design errors. One of which I feel I was close to making.

There is a reason, for example, that everybody hates the object-relational mismatch: The best way to store data is in databases, the best way to program is with objects. It's not just that these two methodologies are somewhat incompatible; it's that in spite of this incompatibility, using the two in conjunction is better than the alternatives for a wide range of software products.

Since a generic editor is by definition going to be a program with general utility, and since the projects meant to be edited by it are huge and may live to see several versions of it, such an editor closely mimics the utility pattern of enterprise software, and here's the point: It's precisely this type of software that usually needs both relational data storage and object based algorithms. Not because there aren't alternatives, but rather because the alternatives have been found wanting by the people making the decisions.

Fortunately, since the information needs to be available as objects in the application, I can start there, and simply be mindful that I only use plain serialization to disk if I need to persist anything at first. This means that the persistant data is, initially, bound to the programming language of the editor, but that's a small price to pay for utility before I have figured out how to write a database management module.

So, that means: persistence is going to be simple serialisation of objects for now, database stuff later, hopefully atomic patch-based.

Synchronisation will be solved by means of the database, again, later.

This means that, later, networking will be necessary for sync, but for nothing else.

This also means that there will be low command delay, since all the information will be available in local objects, always.

I've not made any final decisions on most of the other things, so that's the status for now.

Story Ownership continued

2009-02-05T12:30:00.000-08:00

The reason I went into an exploration of this subject is because of a story a friend of mine, Jonas, related to me about how he felt when he explored the multi-layered game Braid.

Built into the game is an explanation of the lowest, most subtle layers - the game, being non linear as games are, allows the player to seek out this explanation or leave it alone at his leasure. But it still serves not just as an external message from the author, but as a part of the game itself, that insists on being the "right" manner of understanding the subtleties.

Any other interpretation has the unfortunate concequence of making the experience a lot worse, so it really gains authority in this fashion.

But what happens when the player disagrees with the "correct" interpretation of the subtleties? What happens if he hates it, as Jonas did?

There's a breach - it's like playing a game of pen and paper dungeons and dragons and the dungeon master suddenly decides to destroy the story for one of the players by denying him the ability to participate. It's an implicit rule that the dungeon master will not do that. It's self governed - so there's noone there to punish the dm if he does it - but it remains a rule.

So how does this rule work with the idea of story ownership? If the author truly owned the story as if it were his property, then how can there be room for rules which inhibit what he can do with it?

The answer must be that - well, at least if my understanding holds up - story ownership is shared between an author and a reciever, and the fact that the reciever traditionally has had few tools for defending his part of the property is unrelated to the sensations and feelings involved.

In other words, the ethics of story ownership take their basis in culture, rather than in law; it is culture that dictates that the DM doesn't destroy a story mid-game, and it is culture that dictates that Jonas felt his anger was righteous, and that something had been stolen from him by the author upon discovering the deepest depths of the game.

Now I'm not suggesting any changes to ownership laws in my writings on this subject - rather, I would just like to explore the ethics of what a author can and cannot reaonsably do without infringing on the story ownership his audience feels, at least in our current cultural climate. I hope to return to this subject at some later date, again.

Story Ownership

2009-02-04T20:42:00.000-08:00

Who owns a story?

It's a simple question with a complex answer; there's certainly one naive answer that immediately comes up - the one who created it.

Which makes a great deal of sense when the author, and the person who performs the story, are one and the same; which is really the way the first stories were related, so in a historical context it'll often be true.

It makes less sense, though, when the performance of the story is seperate from the author of the story - does a dead author still own a story, for example?, Because that butchers the idea of ownership pretty badly; once you're dead, you don't own anything anymore. Certainly the ownership is not generally inherited - the children of JRR Tolkien couldn't simply add an additional book in Lord of the Rings series if they saw fit. Legally they could, but it would not be percieved as if it had been written by JRR - so at the very least, the exact type of ownership JRR possessed is not inherited. Perhaps a different type of ownership is what the children recieve, but that's really besides the point!

What I'm getting at is not that ownership of a story depends on the proximity of the author and the performance; it's rather that the question has an intuitively trivial answer given some very particular, but fairly common, circumstances. That is, it's trivial if a story is performed and made by one and the same person.

But if it is written, such that the story is detached from the author, it almost gains a life of its own; it sometimes lives beyond the mortal life of the author, at which point ownership becomes difficult to define. It becomes apparent that there are several kinds of ownership (of which I have aluded to at least 3 here), and that these depend upon a lot of different circumstances.

I hope to touch on this subject again later, because it's worth exploring in more detail.

Snake Webcams

2009-01-15T01:00:00.001-08:00

Happy newyears! And now, snake cames!

(Being a mobile computing and hardware entusiast in addition to being a computer game theory geek means I will sometimes make blog posts such as these)

:

I've been on the lookout for a good webcam with a bendy mount for recording lectures and perhaps webcasts and notes, in an effort to improve my oral presentation skills. Requirements were integrated microphone, atleast 30fps 640x480 video, and a bendy usb mount.

My research turned up these models:

http://www.huehd.com/index-2.html
http://www0.shopping.com/xPO-Macally-IceCam
http://www0.shopping.com/xPO-Offspring-Technologies-CAM30
http://www0.shopping.com/xPO-MSI-StarCam-Mini
http://www0.shopping.com/xPO-Philips-PHILIPS-SPC610NC-USB-WEBCAM-FOR-PC-AND-LAPTOP
http://www0.shopping.com/xPO-Flex-CP-MPC-01
http://www0.shopping.com/xPO-Notebook-USB-Web-Cam
http://www0.shopping.com/xPO-A4tech-A4Tech-PK-7ma-Flexi-Webcam-Microphone-for-WebCam-Built-in-Microphone
http://www0.shopping.com/xPO-MSI-Starcam-370i
http://www0.shopping.com/xPO-Mustek-Mustek-Web-Cam-M6323
http://www0.shopping.com/xPO-Typhoon-Toto-TEL5GGC-60-EcoPower-Electronic-Faucet-Gooseneck-Thermal-Mixing-Chrome
http://www0.shopping.com/xPO-ClearOne-Communications-FlexCam-iCam-Digital
http://www0.shopping.com/xPO-AOC-PCCDC1120
http://www0.shopping.com/xPO-Solidtek-NoteCam-B100
http://www0.shopping.com/xPO-IC-Gear-Mini
http://www0.shopping.com/xPO-Compucessory-CCS42122
http://www0.shopping.com/xPO-BYTECC-350K
http://www0.shopping.com/xPO-Micro-Innovations-CPQ54CAM
http://www0.shopping.com/xPO-Logitech-430ML
http://www0.shopping.com/xPO-Logitech-Quick-Cam-530-Plus
http://www0.shopping.com/xPO-Micro-Innovations-IC70C
http://www0.shopping.com/xPO-SIIG-CE-UMCP12
http://www0.shopping.com/xPO-Sakar-Mini-WebCam-69352
http://www0.shopping.com/xPO-Iogear-GCA210U
http://www0.shopping.com/xPO-Canon-VIZCAM-1000
http://www0.shopping.com/xPO-Ezonics-CobraCam
http://www0.shopping.com/xPO-Sony-CCD-PC1

Now most of these are probably quite crappy, and don't even meet my demands, so proceed at your own risk, and sorry for not sorting it more thoroughly...but the above list should be current as of january 2009 with regards to everything available on the market, used or new. So it's a place to start looking for a solution that meets your needs.

Your best bet for getting a really good solution may be this though:

http://www.umpcportal.com/2009/01/digitus-flexi-webcam-ordered

It wasn't available and I've already purchased an excellent alternative from the list above, the Clique Hue HD:

http://www.amazon.com/Clique-HD-PC-Mac-Webcam/dp/B000TTIP8Q

But not at that abhorent price tag though, I purchased mine straight from Hong Kong on ebay for 17$ and 10$ shipping, brand new too. Only problem was getting the drivers from a reliable source.

Clique appears to have gone belly up, at least with regards to driver downloads! Which, if you do ebay it, kindof sucks because even if it does come with a driver cd, are you going to trust your computer to a cd that a random stranger sold on ebay?

Best drivers I have found for it are available here:
http://www.kentd.com/index.php?option=com_content&task=view&id=205&Itemid=1

Or they were at the time of writing. If the link is down, email me, and I'll try to upload them!

Exact size for the zip should be:
11.517.399 bytes.
At the time of writing Web Of Trust trusted the KetnD site. Not sure if that's worth much, but hey.

And neither avast nor any of the 4 firewalls I'm behind have complained about trojans or vira, so it appears completely legit. I don't recall if the drivers were digitally signed though, and they do install a server process for configuration, so use at your own risk.

I hope this proves useful to someone at some point =]

Progress

2008-12-26T13:53:00.000-08:00

This is a small status update on the various things I want to write about.

Firstly, there's the concurrent savegame system pattern.

That's currently on hold; it's an interesting subject, and I want to dive into it further, but for the moment I'm not well-versed enough in concurrency that I want to model it. I want to eventually utilize a concurrency modelling language to implement a real world model of it - I want to use either coloured petri nets or spin:

http://en.wikipedia.org/wiki/SPIN_model_checker

I've drawn up a preliminary diagram, but I need to work in the rigerous models in order to fully understand the problem and how to best tackle it.

Secondly, there's the non-linear story development tool. I'm inclined to call it Texton. I've been discussing with my good friend Aksel whether I should implement it in C# - Which I've never used before - or if I should implement it in Java. C# seems far more suited to the kind of enterprise level software it's turning into - and it comes with windows presentation foundation and if I do program it in that, I'll actually have C# experience.

Java, on the other hand, would mean I would have to use java swing for the interface, which is a lot less delicious than windows presentation foundation. It would be multi-platform, but that's not really a concern at this point. The biggest problem with not using java is, probably, that java is home to staggering amounts of open source software and frameworks.

Either way, that is a bit of a concern.

Thirdly, I've yet to device an appropriate storage model scheme for the tool. I'm inclined to use xml-based object serialization through an SQL database for all storage, since it effectively decouples all storage and concurrency concerns, and allows for remote sync of data. The problem is, I have to write an SQL database adapter at some point. On the plus side, I can start out simply relying on local xml object serialization.

On the other hand, I've been very enticed by the prospect of using a remote object-data-base, since it allows for transparent development and very clean code.
Problem is, such a database utilizes a model-view-controller system of it's own, where the view into it is often locked to a specific language very tightly; a java object db communicates through a java interface in the client application, for example, so you'd have to find some sort of interoperable object db in order to not get your data locked into a specific piece of software; but an interoperable DB, unless it's interoperable because there's a host of different client frameworks in different languages, would lose the elegance.

In the end, I think I'll go with a highly modular approach, where data can be saved and stored through the utility of the adapter pattern. That is, I write my own client in either C# or Java that relies on an adapter interface for loading and unloading data. How that adapter handles data persistence will then be variable, but the main application can effectively treat the adapter as the model it's working on.

If necessary, an adapter should be able to easily be fitted to a remote object data base for live sync, and one can be written for both sql databases and xml serialization. Given the modular approach, two adapters can also be chained up and translate between two different formats relatively easily. Finally, adapters can be written that are able to translate serialized or sql'ed objects into new ones with appended fields and properties, allowing for patching the data-structure without corrupting the data. Hopefully.

Fourth project is my computer game theory course exam. I need to work on it relatively vigorously, so I'll have to put the other projects on hold for now. Hopefully, the next time I post on that, it'll be concerned more or less directly with this exam.

Blog consistency

2008-12-12T14:31:00.000-08:00

I sometimes feel the need to argue why I'm doing things a certain way. Honestly, it's not for posterity, or to make anything clear to anybody else; it's mainly for me.

When I write things down, the syntax and semantics of what I write help me express something I feel. On occassion, those feelings are misguided. That's a pretty way of saying that I'm sometimes wrong, in spite of presenting a thorough argument.

I know this, because it's happened in the past, and I'm not going about things terribly different these days, so it'll happen again.

I'm not always going to go back and say what part of an argument was right or wrong; in the end, I write this for myself, and if I feel making a wrong argument ended up making me smarter, and expressing how that happened doesn't appeal to me, chance is I won't do it.

Sometimes, that will mean my blog becomes inconsistent between blog entries, and on occassion, even within individual entries. This is a choice. I'd rather make entries distanced by clean breaks, even if that means the entries don't fit together, if that in turn means the entries themselves grow to be of better consistency internally. And I'd rather spend my time writing about new ideas I think might be right, than old ideas of my own I think might be wrong.

But, _for_ posterity, I will be making sure that the results I derive will be easy to seek out, handle, and utilize. So the good stuff, I will be certain to reexamine later. The blog is a part of the process towards arriving at those things, so those are what matter.

With that in mind, I hope to soon make a blog entry tying together the game concurrency pattern and the save game pattern.

Designing savegame systems

2008-12-02T18:30:00.000-08:00

Since we've previously established that the design of the save game system impacts gameplay, even if it requirres specific behaviours by the player to do so, I think it's in order to discuss different behaviors in relation to different save game systems. Before we get that far though, we need to establish just how difficult the subject is to work with, how it can possibly fit within my pattern model, and generally how we should procede from there.

I hope to narrow the subject towards a somewhat monolithic conclusion, but I fear it will be far more divergent than any of the other patterns I've discussed. I don't think it'll turn into a nice uniform set of rules, but rather several sets of conditional rules, that can be followed depending upon what exactly you're trying to achieve. The key to the difficulty, in my view, is the heterogeniety of the player behaviour. Perhaps I should embark on explaining why exactly save game systems are different from other gameplay mechanics, and perhaps more importantly, on how this difference is reflected in the way players tend to percieve save game systems.

Save game systems are technically different from everything else because they can be invoked at any one time during the game, and because they completely change the state of the game. None of the other metafeatures have this effect. Changing your options and configurations do not, as a general rule, effect the play experience; but there are a few exceptions to this rule, if for example you play a timed game against a chess computer you can underclock the cpu that's driving it to make the experience easier. Or, if you get a faster mouse and monitor for an FPS game, or a game with quick time events, it should improve your reaction time by as much as a 10th of a second. And of course any difficulty settings.
And then, there's the save/load feature, the focus of this blog, which alters the games state completely, at any time. Unless there isn't one, in which it simply impacts the players life, if he needs to leave the game, instead. Either way, once invoked, either by shutting the game down because there isn't one, or by saving it because there is, once the player returns, the game will be altered. Either because it allows the player to start from that point regardless of what happens over and over, or because it forces him to start from the beginning again.

Obiously, it's very difficult to anticipate the invocation of the feature, since it's invocation may not relate directly to anything that is within the game as a product. In fact, it's very normal not to respond to the invocation at all, for that very reason, nomatter where or how it occours.
This relies on a, by now completely ingrained, very specific suspension of disbelief amongst players.
Anecdotally, when disguised as anything but a save-game system, this feature would be looked upon as being completely different; a common system could be percieved as an undo-button which you can press if you anticipated that you might need to press it ahead of time. Omnipressence of this feature, this ever-pressent choice, within the game is at the heart of why it is very difficult to work with. But the bulk of the trouble in dealing with it in any innovative way is the vague notion that the feature is to be treated as special and somehow "outside" the game, which has by now festered and taken root in the public consciousness amongst players, even though it can clearly alter the experience very considerably.

Choosing wether or not to cooperate with the notion is not a difficult choice to make on the surface, as the advantages are many and ample. Many players will appreciate incorporating a traditional save game feature because it makes matching their lives with their gaming. This will largely be casual gamers, and if anybody uses it to improve their abilities within the game, it doesn't really relate to them because those who have the largest benefit from a save-at-any-time system are likely so casual that they wouldn't bother. The most hardcore gamers, of course, will likely choose to limit themselves from abusing the system because they want to play the way it was meant to be played, and somehow they feel that not using the save-game system to their advantage is more "real".

But the downside is that, somewhere in between, there will be a demographic that will likely use it to alter their game state in various ways, and it's incorporation will alter their play experience significantly. For this reason, what to do is not obvious, and because the demographic is difficult to pinpoint with any accuracy, it's difficult to say wether or not it is safe to ignore it. If it composes 75% of players, their reasoning behind using the feature to min-max their chance of doing well should be of no concern. They're your target audience, and you should try to maximize the fun they have; that's why they pay you. Not to fuel your artistic expression, but because they want to have fun. Unless you want to deny them that, you must try to cater to them.

But then...is it really worth maximizing their fun by doing something that will probably also inconvinience 30% of your players greatly? The choice is bipolar. But to me, the conclusion of this discussion is clear: If you want to design good, solid games, you'll put care into make the right decision about what save game system you choose for your game, and you'll take both the fun of your audience, the current perception of the save game feature, and the non-linearity of your game into account.

Now that I feel I've argued how to best approach the problem, I want to go over some different save game systems; I'll probably only blog about one today.

The first system is the no-save.

This is often used with arcade shmup games; it's impossible to save the state of the game, often because games in arcades are simple, easy to play, and revolve around learning level patterns in order to optimize and anticipate events that always occour in the same manner. Also, player death is directly what earns the arcades money, so if the player could skip over difficult sections after completing them once, it would be a less efficient manner of getting the players cash.
Another advantage is that playing the same levels over and over again is how you get good at many shmup games - there is no arbitrary skillset, only how good you are at the specific levels. This no-save system, then, lines up perfectly with what the game is trying to do - make the player feel as if he's constantly improving, getting better. But it comes with many drawbacks too, one of them being that when not alligning

It seems that games with more than 20 hours worth of playtime would be impossible to complete for any single player, as that appears to be the point where most get sick without rest. There have been reports of heart attack and similar ails setting in after 36-50 hours of playtime, for instance.

So there is a theoretical limit to the no-save system, as well as a, presumably, much lower practical limit. An estimate for the practical limit could be as low as perhaps 2-3 hours.

This is where the players behavior comes into play however. Some players will only be able to accept a sessionlength of 10 minutes or less for a no-save system game, whereas some players will be willing to accept much longer sessions without the ability to save their games.

This is perhaps one of the largest problems I've encountered so far in my work on game design patterns. Which demographic groups are able to accept which playsession lengths, and which invonviniences? And if so, does a particular type of content, which attracts a particular demographic group, need to be paired up with a particular kind of save game system in order to optimize the design? And how exactly should your demographic distribution be before you should cater to the convinience of one part, or the fun of another?

Naturally, my greatest interest is within one particular type of game - those with adaptive narratives and non-linear storylines. Sadly, those do not even fall within any one of the commonly accepted genres - and they make up only a small minority of those genres they do fall within. So there's no real chance of finding empirical evidence one way or another.

Instead, I have to approach the problem using only anecdotal evidence collected from various demographic groups. And in order to really capture the possibilities, I'll of course have to go in depth with examples from different genres and what kind of concequences game systems can have.

Oy vey. This pattern will take a while.

The "save" pattern

2008-12-01T14:58:00.000-08:00

Many games implement some manner of saving and loading progress and game state. I've been thinking over, for a while, just how these various features affect the game play experience.

Some examples of the pattern are in order:

- A friend of mine played max payne with me many years ago. In my games, max, the titular character, was often limping around on low health, dodging bullets and dodging death with them. In my friends game, he was always stacked with 5 bottles, the maximum number, of painkillers, the games healthpack, and he was always at full health.

The difference was, he always loaded if he got hurt and he had the clear sense that he'd be able to do better. He would replay some encounters 3-4 times on occasion, till he got it "right". I only ever loaded if I died.

The game had an adaptive AI - it would leave a lot of painkillers around for the player if he was hurt, leave few if he had a good stash and he was healthy.

It should be painfully obvious that our different utility of the save game system made for different gameplay. I was consistently running the risk of bumping into an encounter that was too difficult for my hit point level, forcing me to reload over and over at the same place 10 or 20 times. He was constantly reloading nomatter what, but rarely many times at the same place; it would be wrong to say that he wasn't challenged, because clearly, it was more difficult to do every situation perfect rather than only those where max was low on health. But he always knew he had leeway, if it came down to it, whereas I always knew I didn't. Quite possibly, I might even have had easier encounters, and I deffinately had more healthpacks to pick up, than he had, so in some manners I was challenged less.

The point is not that there is a wrong and a right way to play a game. The point is that if you give a utility, such as saving games and reloading games on demand at any time, to the player, you may greatly impact his play experience by doing so. Certainly, you could argue that the how responsibly the player uses it is his choosing, not yours; but if you know that whatever you choose to make for a save game system will effect 99% of the players playing your game, and that 30% of those people will use the save game system to play the game in a min-maxing fashion, your choice concerning the system could make a difference between the game being called good or bad by many players, so responsibility doesn't even come into it.

The save game system is therefore part of the game as a product. So, the application of the save pattern, then, is concerned with a very product-oriented manner of percieving the game. It relies far more on outside context than many other patterns I have described thus far.

As such, boiling it down to rules will take a lot of work, and will likely relate a lot more to the consumer-producer analysis of the game as a product, and the context the consumer provides, rather than the contextual constructs which we, as game developers, provide within the internals of the game.

I'll be fun to write more about this in the future =]

Converting the decision pattern into rules

2008-11-30T12:56:00.000-08:00

The summary of the previous two articles I wrote on the decision pattern goes as follows:

If you hide the concequences of the players actions from immediate view, the player won't be tempted to choose both actions via savepoints and savegames. But, if he chooses to reload based upon alusions made post-decision, and these alusions differ, he will be able to verify that his choice likely matters - just not right now.

If you do not allude, show the concequences immediately, and the concequences are shallow, allowing the player to try both will break the game - the player will no longer feel he has any influence, and he cannot consider his choices, former and future, actual gameplay, but will rather consider them out of his hands, and he will cease trying to influence it.

So: When implementing decisions, in a game that allows reloading, these rules apply:

- Always allude to concequences both before and after the player makes a decision.
- The closer to the action you show the concequences, the larger and more impactful the concequences must be.

The second bit also makes sense conversely; if we presume that a decision is supposed to have a big impact on a story, and the full effects of it are something the player might be unhappy with, he should not be "punished" with having to do-over very much.
The psychology here would say that the player should be conditioned to choosing his actions with great care, and that punishment would be effective; but if he regrets a decision enough to discard his current thread and wants to do it over, he is _already_ as into the story as you could want. He cares about the story and the characters. You're not only punishing him for making the wrong decision, but also for caring. The whole reloading thing should be avoided when possible, as a concequence. As such, the player should generally not experience concequences to his actions that there's a high probability he would regret. And if you must take tis route, make a do-over easy.

A couple of examples are in order: in Ultima X you encounter a deathly ill orphaned girl, and you're offered the choice of wether or not to euthanize her. No matter what you choose, the games villain taunts you - either over the fact that you now have the blood of an 8 years old girl on your hands, or that you left one to a slow, grueling and cruel death over the next couple of hours.

Nomatter what the player chooses, the adverse reaction, the long taunting session, and the guilt will likely make him try the other option if he cares about the story and his influence. When he finds out that negative concequences are unavoidable, and that he has only been presented with wrong choices, at the very least he will be glad that he can do over easily. But even then, he is still getting punished for caring about the game world by having to use a lousy interface to explore the concequences; all because some developer somewhere thought it would be a good idea to punish the player with concequences he will be likely to reject nomatter what decision he makes.

In the end, I played through the above sequence 4 times - one euthanizing her, one saving her, and one euthanizing her, then after spending 15 minutes on gamefaqs before I concluded that my first decision was what I really wanted to do, I euthanized her _again_.

- The player must generally not experience concequences he will regret.
- Concequences that the player cannot escape must not be attributed to his choices if he is likely to reject them, and he is able to figure out that there is no way around them

Or, all in one place, the decision pattern in summary:

When implementing a decision, follow these guidelines:

- Always allude to concequences both before and after the player makes a decision. Make the post-decision allusions differ depending on choice made. Exceptions can be made if, and only if, you can be certain that the player won't reject the concequences in favor of a do-over.
- The closer to the action you show the concequences of it, the larger and more impactful the concequences must be. Long stretches are therefore cheaper to make and implement with the same impact. You can even allude to something that never happens if it's the exception rather than the rule.
- For big concequences, the player must not recieve punishment for attempting to figure out all possible outcomes. You would punish him for caring.
- The player must generally not experience concequences he will regret to such a degree that he would be willing to go through anything more than a quick and painless do-over to rectify it.
- Do-overs should happen out of caring for the world, not out of frustration with the concequences.
- Concequences that the player cannot escape must not be attributed to his choices if he is likely to reject them, and he is able to figure out that there is no way around them. There must always be a "right" choice, so to speak.

Storyline concept

2008-11-22T11:52:00.000-08:00

I need to dump this concept somewhere:

As a method for international star travel, in an age where human science has conquered star faring propulsion technologies but not the human lifespan, nor the ability to store a computerized mind more powerfull than a cat in anything smaller than the volume of an elephant, humans develop a mechanized shell with the ability to grow a humanoid host.

Designed as a cyborg, the shell is 2 stories tall, with a life support chamber within that can grow and support a human being. If the human is ever killed, dies of old age, or leaves the shell, or is terminated, a new one can be grown to serve as host based on a storage bank of zygote clones with identical DNA to the former host. The shell nurtures and raises the human within the chamber, utilizing hormonal growth regulations, optimized sleep cycle regulation, and databanks containing interactive virtual reality recordings that allows the human to be raised, and eventually come to understand it's position, based on the lifes of the previous hosts.

Any space travel accross long distances means the death, rebirth, and re-raising of the host upon closing to the destination, effectively leaving the shell as a whole immortal, but always alone, and suffering from varying degrees of amnesia depending upon it's development.

I'm not quite sure what this concept means, but I thought it was cool when I came up with it....

The decision pattern, some refinements

2008-11-22T05:24:00.000-08:00

In my last post, I described the decision pattern as something pertaining to the rest of the play-experience within the game. That's a pretty loose definition, so I'll try to narrow it down a little further: The concequences of the decision should influence either the main plot or a diverse number of distinct and unrelated subplots, such that it is different from making a different decision.

Implementing decisions is one of the greatest ways to give the player the impression that his performance matters, if he is able to recognize that his decisions actually make a difference. In other words, if the player does not realize that judgment is being passed on him, he will not modify his manner of playing, and thinking, accordingly, and his experience will arguably be more shallow.

This is perhaps one of the most problematic aspects of the decision pattern; since a lot of games do not pass permanent judgement, and chooses not to have significant concequences for many decisions, a game which utilizes the decision pattern will necessarily need to make the player understand that that it utilizes it. That is to say, one can safely assume that the player, at the onset, suspects the game is very linear, and that he will suspect any choices implemented of being unimportant.
I can be quite difficult to dispell this suspicion, and perhaps calls for a special "tutorial" section to help the player understand the dynamics of the game.

It's actually worthy of note that once the player has become convinced that judgement will be passed on him, his manner of thinking will be henceforth modified. So, theoretically, you could have very intricate manners of passing judgement in the beginning of the game, and then later introduce choices whereupon the same judgement will always fall, without the player realizing it if the judgement is a reasonable response to all choices.
This utility is exceptionally conniving and very powerful as long as the player is fooled, since you can make the player think he's being responded to without actually being responded to. In other words, you get the same effect that non linear storytelling offers without actually having to make it particularly non linear.

There is a huge problem with this approach however: The player may be inclined to reload the game at an earlier point and try again if he is unhappy with an outcome. If he realizes that you're not actually judging him anymore, he will likely immediately modify his behavior and be inherently suspicious of the implementation of decisions again, a suspicion that may not go away as easily a second time around; fool me once, shame on you, fool me twice, shame on me, and all that.

The trick is to make the player see that there is an immediate difference; there has to be a distinction which is deep enough that the player thinks it may matter in the long run, even after playing through the same 5 minutes of game to try out deffirent choices. If the player can tell that it doesn't even matter immediately afterwards, the choice won't matter much to him because it doesn't matter much to the game.

A good idea is to implement distinct rewards and punishments for different choices in the immediate term, since at the very least, that will make the player care out of greed. But additionally, it's important to have a large amount of long threads; this is to instill in the player that not only is there an immediate difference, but there may well be long term differences as well. In fact, foreshadowing can be a powerful tool in this regard. If a character openly tells the player that he hates the player in one branch, and not in another, then the player will expect that there may be concequences to being hated. There doesn't have to consistently be concequences, as long as the concequences pop up later often enough that the player starts trying to act based on the idea that there may be concequences.

Once the player is in that mindset, doing a conversation where a character decides to now hate the player, that conversation will have an impact. It doesn't actually matter wether or not the player always or never have a future confrontation about something or other; all that matters is that if the player does have a confrontation, it gets tied to the conversation where the character admitted (or didn't admit) to hating the player, such that the player is able to tie the idea of judgement to his earlier action.

If the confrontation and the conversation are spaced far enough apart, the player won't be inclined to reload to check the difference; he may speculate that, if he didn't make the character hate him, the character'd been more confrontational, perhaps the character would have brought a lot of goons along with him; or, if he did make the character hate the player, then he may speculate that the confrontation wasn't inevitable. Either way, it's possible to do a tangible feeling of judgement without actually doing a lot of work to implement that judgement.
On a second playthrough, such things will be revealed to the player, but if you've actually made a game that is good enough to warrant two playthroughs, that's good enough, so you should just take that and be glad. At that point, you can live with the player deciding not to play anymore; he'll still, undoubtedly, recommend the game far and wide.

The decision pattern

2008-11-21T08:55:00.000-08:00

One of the things that a fair amount of interesting games do is provide you with a meaningful choice you can't go back on that will affect the entirety of the rest of the game.
I'd like to talk a little bit about the concequences of this type of design, and what it entails.

The choice is often placed either at the beginning or at the end, and only rarely in the middle. It makes "sense" to place it in the end because a 2branched choice placed 3 hours before the end only necessitates about 6 hours of gameplay, of which 3 are the price of the choice.

A choice placed at the begining, on the other hand, is arguably either very expensive to design, or it doesn't diversify the experience afterwards as much from the other options - only few games will place a choice before the player 40 hours before the game ends, and effectively pay 40 additional hours of gameplay time as the price.

Various strategies are can be used to lessen the price. Some go so far as to rely on the player forgiving the lack of concequences of most choices because it would be too time consuming to implement. It's a completely viable strategy, since players expectations are measured by their perception of viability and quality. If they find that implementing proper concequences would have been detrimental, they may be willing to accept the compromise because they cannot think of a better one.

Applying the decision pattern, then, is a question of weighing returns. A lot of older games provide much more detailed responsiveness to choices than many state of the art modern ones. The newer games gamble that gamers are very forgiving; since the demographic of gamers has changed over the past decades, it may well be a sound gamble. All the same, I do not feel that blindly submitting to it is the optimum choice.

A good example of the application of the decision pattern is the choice of wether or not you save Paul Denton in Deus Ex. A bad example is wether or not to be bad or good at the end of Deus Ex, if not for the fact that the choice was placed right at the very end.

I'll go into the intricasies of the decision pattern in a later post, and narrow down how to apply it correctly.

From patterns to rules: The McGuffin Pattern

2008-11-17T10:10:00.000-08:00

I wrote earlier about what I called the McGuffin Pattern.

The basic idea was that if you drive your quest with a McGuffin, like a unique stateless item, the player will be able to figure out the solution to the quest at it's onset. The player doesn't, as a concequence, have to solve a problem; he simply has to provide a specific, choiceless solution. Now, this can work if you want to imply that the player must do a very specific job within very specific parameters. But the player won't own the solution, he will be following orders. If you want the player to commit, you must make him own his choices, and therefore his solutions. At the very least, it must be this way in the general case. The McGuffin pattern hinders that.

Within gaming, the McGuffin pattern is without a question an anti-pattern, so it should not be followed. It should be known, because it should be avoided. And what's more, it doesn't simply concern McGuffins - it can be characters or fairly abstract concepts too, that provide the player with the solution at the onset, and on the other hand, McGuffins can be constructed to avoid the McGuffin pattern. Yes, that makes it sound like I just coined a misnomer, and I kinda sorta did, but I didn't because the pattern emerges through the brainless use of McGuffins 99% of the time. The generalization simply says: If you abstracted the McGuffin out of the equation somehow, while keeping the solution within the definition of the quest, you didn't solve anything at all, dummy.

Now, as a quick interlude: I like rules. Rules partition everything into right and wrong, that which follows rules and that which doesn't. Any good pattern can be made precise and easily applicable through the use of rules. So, what rule can be taken away from this?

Baseline rule of it is: Do not present the player with unfulfilled solutions. Present him with problems.

The fine print should add: And perhaps hints, but never reveal to him the number of possible solutions to the quest at the onset. He needs to figure out the solution. If you want to optimize the players experience so open quests don't confuse him, be certain to inform the player of his progression through 2nd person narrative; but even then, only log what he has done and discovered in a clean cut, unambiguous fashion. And here's the cigar: try to always make hints ambiguous in their certainty: Make them suggestions rather than plans.

The McGuffin can almost always be avoided, if desired. Say the quest is to look for the holy grail. Firstly, try to make the grail an ambiguous item. Now generally, there can be no more than one holy grail, but that's because the holy grail doesn't have a purpose. Suppose it did have a purpose; suppose it gave eternal life if you drink from it. Then, what the player ostensibly needs is to be searching for is something that gives eternal life.

At times, you cannot make the item itself ambiguous though; perhaps it's a holy grail without a purpose, perhaps it's a smoking gun. But the maxim holds: if the item is unambiguous, it's location, or it's validity, must be ambiguous at the onset. The player must make a choice on how to make the solution less ambiguous. Perhaps it turns out that there is no imposter, that the location is obvious, or that the task can really only be completed in one way. But narrowing this down should be a process, and not revealed through the initiating dialogue. Hitman is perhaps the most excellent example; there's typically a myriad of puzzles built into each level, and many have multiple solutions. But there is only 1 goal. The player owns the hit, however, because he owns the process; he was presented with a problem, rather than a solution.

To reiterate the first rule of non-linear narratives :
- Do not present the player with unfulfilled solutions. Present him with problems.

The McGuffin Pattern

2008-11-13T02:25:00.000-08:00

http://en.wikipedia.org/wiki/Mcguffin

I'm going to go out on a limb here and define my own terminology for some patterns I believe are occouring within non linear narratives. Terms are useless in the broader context; noone will ever come to know and use mine, to be sure. But I had to put some sort of memorable title for this, and various other patterns that are emergent within non linear narratives so my own terms will have to do untill I find a more official theory that agrees with my own.

And really, that might sound exceptionally lazy, but within non linear litterary theory, very little context is available. Indeed, the best topology I have come upon is from 95 and has 10 hits on google for most of the terms it defines. And even that is very basic; it simply defines names with meaningful etymology for some of the most basic constructs within this area. I'm speaking of Espen Arseths essay called something to the effect of "a topology of "....and I forget the rest. It's in my bookcase, and if you google arseth I'm sure you'll come upon it...eventually.

At any rate, the McGuffin Pattern. What am I on about?
In books and novels, a McGuffin is a unique item that is intrinsically linked to the plot in some manner; in fact, the whole point is that it's linked to the plot, and has been since it's conception. It's such a fundamental piece, by definition, that the plot designer invented it to help him rationalize something he wanted to do. For example, it is the holy grail of the arthurian legend, or the ring in the lord of the rings.

In computer games, it is an item that allows the game designer to fashion his quest in a manner that makes sense to him. To follow the McGuffin pattern in game design, though, is to make major parts of the game play experience linear. Within non linear narrative theory, then, it imposes a linear narrative on an experience that is, at a lower level, non linear. Many will see it as a necessary evil, probably, and I tend to agree if you're ok with imposing a linear narrative on a non-linear experience. If that somehow makes more sense than the alternative, then it's obviously the sensible thing to do.
But let me step back a bit and explain why the application of a mcguffin makes the game experience linear:
Fallout 1 and 2 are both driven by the search for specific items at the outset, or so it seems. In fallout it's the waterchip, in fallout 2 it's the garden of eden creation kit. But these are, in fact, not McGuffins. At least, the waterchip isn't; what you're really searching for is a clean, permanent source of water for the vault because the waterchip broke. And in fact, there are more than one solution to this - you can aquire a waterchip from a number of sources (though that number is not sufficiently high, in my oppinion) - and you can, similarly, get water merchants to bring water to the vault.
To be a McGuffin, it would have to be a unique item. Had it been a unique item, the game would necessitate that you do certain specific actions on any given playthrough.
In this fashion, the McGuffin pattern necessitates that the player commit to certain very specific actions, and a very specific narrative, whenever he accepts any sort of task that involves a McGuffin.
So essentially, the McGuffin Pattern is an anti-pattern - when utilized within RPG's and similar games, you lock down the narrative, and this is the kicker: You do so, because you, as a writer, want to do something specific with the narrative. You take away the players liberty because you feel you have something better than liberty of narrative to offer him.

Now it may be that you do, but you have to realize that you make the player into a passive observer rather than an active participant.

So how do you avoid that? Don't use unique items. And try not to make characters the goals of quests. Ideally? Present the player with open ended problems rather than solutions that need to be filled in.

Why writing and programming are fundamentally different

2008-11-11T06:01:00.000-08:00

A lot of people spend time writing stuff on their computers. What and how they write depends almost entirely upon what their goal is first, and their personal manner of going about things second.
Take this blog. My goal is mainly to express various essays that are bubbling and steaming in my head and are just begging to become a little more concrete, and a little less elusive. Perhaps help me cut the crap from the cake with a little bit of written analysis afterwards. My goal is not, on the other hand, to explicitly to argue why I believe all my presumptions to be true.
Since my readership is likely to be exceptionally limited, I'm fully expecting it'll only be me, it seems like I would per default agree with my own presumptions if they're worth agreeing with.

As such, you'll see a focus on presenting an idea in a manner which seems to be sorta correct to me at the time of writing, but also which does not get lost in too many trivialities; and one which does not make being right a more important property than being written.

So various writers write for various reasons; programmers want to be absolutely precise, and absolutely correct. Of course, that is not enough, but those two are preconditions for writing working programs.

Writing political arguments is different; there, the goal is to be convincing. Being precise is not important, but always being right, at least in the eyes and ears of your followers, is very important. It is no suprise, then, that programmers aren't terribly interested in popular politics - the lack of finesse and precision, in favour of vague omnicorrectness, can be particularly jarring when you're used to dealing with absolutes and total precision. To a certain degree, this makes perfect sense - it is very hard to get someone to like you if they don't agree with you on things you purport to be of the utmost importance.

Writers who focus on a whole lot more than being right. Certainly, what they write must make sense, but they attempt to invoke much more varied responses than agreement or disagreement. As such, they employ language for a completely different reason than that of programmers - who are attempting to achieve something very specific. And different from politicians - who are attempting to be correct while saying something you agree with.
All because a writers goal is completely different. Certainly, the goal may be fairly specific, so it is akin to what a programmer does - but the writer does not have the option of being entirely precise. And certainly, he wants the reader to accept what he writes rather than reject it - but then, the writer does not need to prove that it is right, just that it isn't wrong granted fair suspension of disbelief.

Any writer who does not realize that making factual arguments, or attempting precision or correctness is not the focus of the discipline is, as such, doomed to fail. It's supposed to be about the story, stupid.

Concurrent behaviours within non-linear dialogue

2008-11-10T23:04:00.000-08:00

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

2008-11-09T21:13:00.000-08:00

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

2008-11-07T09:33:00.000-08:00

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.

This blog

2008-10-11T23:36:00.000-07:00

Why, writing, blog, this, you, the reader.

As in, why do a blog, what do I write about, what is this, why a blog, and who you are.

A blog, because I wish for some of my thoughts to be accessible from the web by myself and others.

This is therefore a log set up on blogger with an account I already had. More specifically, what you are reading right now is a brief guide on the context.

For a context to make sense, there has to be a reciever - someone who needs the context to better understand what I'm on about. The reciever is you - wether you are actually exists - that is, wether I have more than 0 recievers, including myself - is up in the air.

But if you are there, this is what I assume about your context:

It doesn't matter why you are reading this, and it doesn't matter if I know you, but it does matter that you don't mind thinking over and analyzing what you read here, because my writing is habitually convoluted. It also matters that you have the patience to deduce my intention from the context. Finally it does matter that you ackknowledge that I don't write anything here if I don't have a point to make.

It may be an incorrect point, or incorrectly made, perhaps even incorrectly thought out if such a thing is possible. It may be a point relating entirely to me. But either way, there's an intention behind putting it up here.

The context I provide is this:

You may be able to take something away from this blog - fine. That's good. Allow yourself to be inspired. But don't steal anything. What I write here belongs to me, so if you take something, make sure it's something original to you. It will be a distinct advantage, when reading this blog, to be into culture, computers, programming and language. It will also be a distinct advantage to know me. In fact, it will be the most advantageous if you are me, which you probably are.

I will be writing here to jot down ideas, and weed out inconsistencies.

I do this, now at least, because I feel the need to keep this stuff in a central location where it will always be available and where I won't forget it.

Good luck reading and have fun with it. And don't take it too seriously - I'm not a particularly serious person. I just happen to enjoy expressing my ideas as if they are serious.

Tejlgaard