[Divunal-author] tasty paste from toxic waste

[Allen Short]

----Security_Multipart(Thu_May__8_03:23:28_2003_861)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

    >> Also, there's no InterfaceFilter class; _implementorFilters
    >> apparently was designed to accept anything that implements
    >> IInterfaceFilter. I imagine this isn't good enough for
    >> persistence, is it?

    > Twisted World is dynamically typed.  It would be a
    > ListOf(Storable) (which is syntax sugar for StorableList,
    > anyway).  This assumes that int and str can't implement
    > IInterfaceFilter but I really hope that is a safe assumption.

Me too. 

    >> Finally, how does inheritance interact with __schema__?

    > Ngh.  Have to check this out.  Basically I guess it should just
    > aggregate the __schema__ dict, and blow up if any column
    > declarations conflict.

    >> I see that MetaStorable takes bases into account, but can
    >> classes be replaced by their subclasses within a schema? For
    >> example, Thing._links is a list of Things; will it work out OK
    >> if some of them are Movables?

    > They can be any kind of Storable.  They could be
    > divmod.schemabox.Message instances, for all I care.

It wasn't made clear to me that the type specified in the
schema beyond "Storable" was not too important, thanks for clearing
that up.

    >> Oh, and: does it matter if Movable.location is set on the
    >> class? will Storable deal with an unset attribute on the
    >> instance?

    > Hmm... it will assume the attribute is None... so in this case,
    > yes.  It will work as you expect.

Okay, good. :)

    >> 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.

    > If you want that, then the object descriptions should probably
    > be stored in the code.  This might not be such a bad idea - we
    > are probably going to need to eliminate support for persistently
    > storing tuples as description elements anyway, because "list of
    > tuples of arbitrary length" is a pretty hairy datatype to
    > specify in datamatic, and it's more flexible to be able to
    > adjust the specifics of your text output by adjusting a method
    > than by running an update script over a database.

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. 

    > This is pretty consistent with the worldview we've got now, I
    > think.

    >> From what I can see, descriptions are going to be the most
    >> work, after code; diffs and history for them will probably be
    >> important.

    > 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. :)

    >> What role will game developers play in divunal? presumably we
    >> will not have 'normal' characters, nor will be have
    >> near-absolute control over our environs ('zero-story' again). I
    >> assume some of the 'archetype' stuff goes here?

    > We play the game normally.  If you want to do something funky,
    > create a stat to do it, create tools to do it, then artificially
    > boost your stat.

    > However, I'd like to discourage authors from thinking too hard
    > about these special characters up front.  They should, largely,
    > be observers to the greater universe as the players are, and not
    > an integral part of it.  Unless an author has particularly
    > strong role-playing and writing skills, they should not have 1-1
    > parity with an archetype.  (What I mean by this is - tenth is a
    > special case.)

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.

    >> At the start of the game, what will motivate players to collect
    >> Stuff?  presumably once they have enough, they'll be looking
    >> for more stuff to maintain/complete/explain the things they do
    >> have

    > External direction of some sort.  Possibly, external compulsion.
    > If it's compulsion, then the collecting of Stuff should enable
    > them to throw it off.

yay!

    >> (o/` the more you have, the more you have to have to take care
    >> of the things you have o/`)

    > Where is this song from?

Not sure where it's originally from, it's been in the attic of my mind
for years from a children's radio program.

    >> What's the deal with libraries? are we operating from
    >> Pratchett-like L-space assumptions?

    > Not quite.  L-Space is just silly.  Everything in the Library
    > has a reason for working the way that it does, and a great deal
    > of conscious effort went into making it that way.  There is a
    > reason that it's an archive where they put all this stuff, too.

Well, yes, it's silly, but it's the nearest sort of explanation i
could come up with. :) 


    >> What are the gameplay mechanics of dealing with friendlies?

    > YES

    >> 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.



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. 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) 2) Not listing all objects in
the inventory list (some also need to be in the description). 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?


Allen

----Security_Multipart(Thu_May__8_03:23:28_2003_861)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+uhQDEd6n5DRBYM4RAr0EAJ48lgY58ELj+qFbv/s7sS+b5CUUTQCdGQKl
5oKuR99DYDjqfMY6wS87hYc=
=OytH
-----END PGP SIGNATURE-----

----Security_Multipart(Thu_May__8_03:23:28_2003_861)----