Object oriented adventure design

[buzz]

I don't know if the technique needs to get as complicated as some may think. One could probably create blank forms for each of the nine classes described. A given object is not always going to use every other object, so you could just plug the objects as needed into your writeup of the adventure.

That, or just use them as checklists for each part of the adventure. E.g., when writing up a scene, you run down the attributes and make sure you haven't forgetten anything, particularly "how many ways are there from this scene to another scene?"

I guess it's not that much different from making a flowchart, but with more structure for each element.

I'm going to give this a shot the next time I write something up.

 

[Castellan]

Bah. Real DMs can write Fortran adventures in any ruleset.

Ick! Straight machine code, for me, please!

 

[Janx]

As a programmer, I've looked at this problem myself. Mostly its been a problem of time to write the software to manage it.

I had an idea to write a relational database to organize the most basic of those object types (locations, people) into a tree. Thus you'd have things, which contain things.

This would let me make a website where you would traverse the nodes, seeing places and NPCs, and the whole thing would be managed by a database (thus no pages to write and cross-reference). An example would be:

World: Drasil
--Continent: Latra
----Country: Stagheart Forest
------City: Wyliath
--------NPC: Janx Jelantru
--------NPC: Bovart Seeslom
----Country: Arcapan

and so on, with each of those nodes having a page of information. It would seem that adding events and motivations to NPCs and places would fill in the other objects (need to fully read that article) and then I'd just have my laptop out and traverse the tree to where the PCs are and see what's going on...

I've got a type definition system already, so I could probably prototype this in software pretty quickly, given a few spare hours.

Janx

 

[Psion]

Has anyone done a programme from that? would be kind of nice.

Well, I used to use my Corel card file program for something similar. I had default card formats for secrets, NPCs, events, each having certain attributes I would fill for instances of the card type.

It was a bit costly in terms of time, but it really helped me keep things straight. I was considering at least digging up the event cards again, as those were really effective.

 

[Castellan]

Although it doesn't strictly fit the Object-Oriented concept of DMing, I'd suggest trying a Wiki out. There are some nice Wiki projects for use on a laptop (both PC and Mac) and if you have the Apache web server installed, you're pretty much able to use any of the Wikis out there.

What's nice is that you can have one page per "object" of interest, but you can cross-reference things with hyperlinks. Since links are automatically made whenever you name things appropriately (usually things like WikiLink, or Wiki_Link) you can have all kinds of information available at the click of the mouse. And no need to shuffle index cards.

 

[Asmor]

Ick! Straight machine code, for me, please!

Machine? Man up, Nancy! In my day we programmed our adventures using abaci and quipus. And ya know what, WE LIKED IT. When we had to generate a random number, we just shook the abacus around a bit.

 

[Asmor]

Although it doesn't strictly fit the Object-Oriented concept of DMing, I'd suggest trying a Wiki out. There are some nice Wiki projects for use on a laptop (both PC and Mac) and if you have the Apache web server installed, you're pretty much able to use any of the Wikis out there.

What's nice is that you can have one page per "object" of interest, but you can cross-reference things with hyperlinks. Since links are automatically made whenever you name things appropriately (usually things like WikiLink, or Wiki_Link) you can have all kinds of information available at the click of the mouse. And no need to shuffle index cards.

That's a damn good idea!

 

[Asmor]

As a programmer, I've looked at this problem myself. Mostly its been a problem of time to write the software to manage it.

I had an idea to write a relational database to organize the most basic of those object types (locations, people) into a tree. Thus you'd have things, which contain things.

This would let me make a website where you would traverse the nodes, seeing places and NPCs, and the whole thing would be managed by a database (thus no pages to write and cross-reference). An example would be:

World: Drasil
--Continent: Latra
----Country: Stagheart Forest
------City: Wyliath
--------NPC: Janx Jelantru
--------NPC: Bovart Seeslom
----Country: Arcapan

and so on, with each of those nodes having a page of information. It would seem that adding events and motivations to NPCs and places would fill in the other objects (need to fully read that article) and then I'd just have my laptop out and traverse the tree to where the PCs are and see what's going on...

I've got a type definition system already, so I could probably prototype this in software pretty quickly, given a few spare hours.

Janx

It seems to me that this is the sort of thing XML was designed for... Any XML editor should be sufficient.

 

[MonsterMash]

That OO approach is similar to what I try and do in scenario and world design anyway as I find players don't do what I expect, so I have to be ready to take NPCs, creatures and locations into places I didn't expect.

I like the wiki idea as it'd be quicker and easier than a relational d/b, even though I've spent 9 years developing on various RDBMS.

 

[Desdichado]

I'm not sure how it will get you out of writing story-like adventures if you're planning all of your scenes ahead of time, as well as all of the exits from those scenes that you can think of. In fact, it seems like it would do the opposite; drive towards more GM-driven adventures rather than PC driven adventures.

As to the other concepts of the design, its seems like its needlessly formalizing and quantifying something that I do more or less subconsciously anyway.

Anyway, I guess I wasn't really all that impressed with the article. It seemed less like a useful tool for module design and more a way to combine two geeky passtimes just because you can, and it's "k3wl" to do so.