This day has largely been spent reading further articles on Gamasutra about narratives and open worlds. In addition, I've familiarised myself further with Pyro, and despite finding areas that are clearly unfinished, I have a good feeling about what it can do for the project. As a matter of fact, I believe the fact that it is indeed unfinished is a boon, rather than a curse.

When I started out, my examiner/supervisor Staffan Björk suggested that I modify some pre-existing game engine for the practical application of this project. I agreed; adopting freely available code would save both effort and time, without compromising the research itself, as ultimately, the topic is not about the grittier lower levels of game programming. Anyway, my thoughts immediately turned to Roguelikes; unburdened with distracting demands for high quality graphics and other media, control schemes and complicated and time-consuming mathematics, and already having a firm tradition of randomly generating content, they were perfect candidates.

A few requirements were required of a good candidate: It must be freely available, for one thing, preferably with a license that wouldn't place too strenuous demands on me or the institution (I expected that this wouldn't be a problem, as most Roguelikes adhere to various Open Source principles). Furthermore, the engine ought to be developed enough to provide at least basic functionality; re-implementing the wheel is not desirable when it's not the central focus of the project. On the other hand, it couldn't be *too* sophisticated (and ultimately this was the reason a lot of potential candidates were rejected), as too many unnecessary features would distract and get in the way more than they would help. It would also be nice if the base was written in a high-level language, because performance was not a factor, and ease-of-use and rapid development was highly desirable.

Some early candidates included Nethack, Angband, and the original Rogue. They were ultimately rejected, however. Nethack is written in C and is highly complex, to the point where simply beginning to understand how it worked would've taken weeks or even months of hacking before any real progress could be made. Angband suffers from a similar fate, being complicated and unwieldy for no appreciable benefit, and would only serve to slow me down. Rogue, also written in C, was significantly simpler, and while its language made it somewhat undesirable, it was an acceptable candidate at first.

Looking around for Roguelikes written in other languages, I came across Pyro (http://pyrogue.sourceforge.net/), a Roguelike written in Python, a high-level language with which I am fortunately familiar. Further inspection noted that it's released under the MIT license, a highly permissive Open Source license suitable for this project. The project is relatively new, the last updates being from late 2006. Its dungeon generation algorithm is slightly more sophisticated than Rogue's, and allows for basic dungeon crawling and limited character creation/advancement, but lacks any highly complicated features that would make it unwieldy. The code base appears relatively sane despite a few mystifying constructs here and there. In short, Pyro seemed like the perfect candidate, and was adopted as the base engine for this project.

So far, the initial assessment appears to remain true. No particular hurdles have been encountered; it's merely an issue of becoming familiar enough with the code at this point.

This Gamasutra article reminded me of another aspect I had been wanting to cover at some point; open worlds. Generative game content is especially suited for open world-type games, as there will potentially never be a dearth of locations to visit when new ones can be generated on-the-fly as the player progresses, and as such I feel it relevant to look into a little bit more. This in turn leads me to remember the three-tiered system of narratives I'd earlier devised.

In short, I'm envisioning gameplay as being furthered by three different categories of narratives. Perhaps a better word is “quest chains” or “sub-stories”, but they're all part of what I'd collectively call “video game narratives”. We remember that narratives in video games are not ultimately about dumping text on the player, but about presenting coherent challenges and let the player live through them as if she indeed was part of the story.

The three categories are trunk narratives, branch narratives and ad-hoc narratives (though they aren't really much of narratives, in reality).

Ad-hoc narratives are the simplest kind, and can be found in some games such as Elder Scrolls II: Daggerfall. Basically, these are just simple, randomly generated quests with no particular narative investment. Usually an archetypal quest template is simply chosen, and then nouns are plugged into pre-set spots. The result may be something like “You, fighter's guild initiate, will be paid <108 gold marches> and <a new sword> if you kill the <ravenous mountain gorilla> that has been terrorizing <the village of Happywater>.” In the long run only being fed quests like this, with no consistency other than the similarities brought on by the use of templates, would surely quickly become very boring. It is my opinion, however, that they form a welcome diversion from the main storyline and allows the player some breathing room, in addition to providing necessary character advancement (in the form of experience points, upgraded equipment, or whatever is suitable to the game in question). Having the opportunity to “kick back and relax” and do a simple, no-complexities mission, secure in the knowledge that you can't screw up the main storyline and that there's a reward at the end of it all, I believe is a potent way of making a game better, so long as the bulk of the game is not composed of such missions.

It should be noted that quests highly resembling these ad-hoc missions are present in a few other games, such as Final Fantasy Tactics Advance (I think it was, anyway), where the player may, after a certain point in the game, go and accept missions from the local mercenary guild. These missions are not randomly generated; they are all pre-scripted. But the interesting part is that when played for the first time, the player can't really know that. There is nothing particular about these missions that reveal they are manually created. This leads me to believe that generating such missions using a computer, with a little ingenuity, would result in missions that most players would find both acceptable and entertaining. Again, we're dependent on not flooding the player with such missions; after a certain point he will surely be fed up with only being fed what he interprets as templated missions with no real variety. I similarly don't think we can rely on the player to simply stop playing them when he starts being fed up, because at that point the damage has already been done. Instead, we should gear our algorithm towards only deliberately generating enough missions to keep the player occupied for a short time, then steer him back towards one of the main narratives. After engaging in the main storyline, which is hopefully a bit more intellectually stimulating, we can again begin to offer ad-hoc missions.

Time's running out for today, so I'll think and write more about the other two narratives tomorrow.