[Divunal-author] tasty paste from toxic waste

[Glyph Lefkowitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday, May 8, 2003, at 03:23 AM, Allen Short wrote:

>>>>>> "Glyph" == Glyph Lefkowitz <glyph@twistedmatrix.com> writes:
>> On Tuesday, May 6, 2003, at 01:35 PM, Allen Short wrote:

>>> Looking further ahead, I'm not sure storing room/item
>>> descriptions in a normal schemamatic file is a good idea; if
>>> possible, I'd like to see them loaded from a CVS-friendly
>>> format.
>
>> haaaahahahahaahahahahaahahaha. ha.
>
> Yeah, i was afraid you'd say that.

"CVS-friendly" and "scalable" are almost directly at odds.

>> If you want that, then the object descriptions should probably
>> be stored in the code.
>
> nnngh, this feels like a poor separation of concerns :) but it's the
> approach i'm taking for now, just because i know it can be made to
> work.

It makes sense to me - the formatting component can be a different 
component, if you _really_ want your concerns separated, but we do have 
the notion of objects knowing how to describe themselves dynamically 
rather than being given static descriptions.

This does place more of a burden on the programmer, but hopefully once 
we've got our writing hats on we can go through and clean up a lot of 
the descriptive text.

The database's concern is storing _relationships between objects_, not 
the text that describes them.

>> There is a larger issue here of how to version & checkpoint the
>> map.  I'm not sure where to go with that, really.
>
> well at the very least, we can backup the entire dataset. versioning
> within the database itself seems cool at some level but i am having
> extreme difficulties thinking about low-level issues at the moment so
> i wont. :)

Hooray, we're back to Pickle.

> Indeed, Tenth is a special case. :) From div-vision it wasn't clear
> that the archetypes weren't all intended to be specificially
> represented all the time.

I didn't spell it all out, but the general idea is: "In this iteration, 
I'd like the archetypes to be separate from their specific instances; 
we should be able to have multiple author characters playing into a 
particular archetype."

>>> etc?
>
>> The questions you're asking here should be answered by a giant
>> database full of different answers to them in various
>> combinations.  The questions are much more important than their
>> answers, since they define what the fields will be in the
>> database :-).
>
> Oh indeed, which is why i asked them. I have felt certain that you
> crazy game-writing people have done enough of that sort of thing befor
> e to make it a commonplace, but i'm not used to, shall we say, "data
> driven" software on that scale.

Yeah, pretty much.  It's too bad Sean isn't working on this.

> So, after reading Graham Nelson's advice for IF authors on 
> descriptions, i've been trying my hand at a few, and wishing TR 
> supported my efforts better.

We should probably discuss his advice here.  Some of the things he 
suggests are peculiar to a linear, directed plot (which we don't have) 
and some are specific to a very slow-paced single-player experience.  
While we should be pushing online gaming closer to those goals, we do 
have to make some concessions to the fact that the game is real-time 
and open-ended.

Examining each point he makes for its context with respect to these 
ideas might yield some new and interesting conventions we could follow.

> In specific, i wish two things were done differently:

> 1) not defaulting to listing exits by name and direction (I want to do 
> this in the description)

I don't have an answer here yet, but I'm thinking that this is a 
questionable UI decision.  Having them listed twice might make sense 
(though in the telnet interface there should be a visual distinction 
between "textual description" and "spatial layout information").  
Players are going to have the ability to add additional exits to almost 
any room, and someone moving through the map quickly could easily miss 
the existence of an exit.

Of course, I have no problem with rewarding attentiveness, but I would 
rather make only things that would be non-obvious to a casual observer 
in a real environment be non-obvious to a player who is only skimming 
descriptions.

> 2) Not listing all objects in the inventory list (some also need to be 
> in the description).

The inventory list should list all _portable_ items, methinks.

> In olden days, this was done by adding extra items to the description 
> dict, but in these modern times it appears only __main__ is displayed 
> unless something akss for another key. Any thoughts on strategies for 
> making descriptions of this sort easier?

Mmm... only __main__ being displayed is a bug.  I'll have to look at 
that at some point.  The description code is obviously only a prototype 
at this point.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+ulhgvVGR4uSOE2wRAu7BAJ9Qufxkm6YSk+dt/2zIk2uBNeIj4wCeIf94
aW742NZABwxHP38bO/+klOg=
=+vwC
-----END PGP SIGNATURE-----