[spoon-discuss] Re: [Thermo] (unknown)

[Doctor Ducker <drduck@xxxxxxx>]

Orc In A Spacesuit wrote:

> This message is going to B, Market, and Thermo, and first is an attempt to standardize things
> a bit:
>
> I think that it would be a good thing if you send emails regarding just the Market itself just
> to the Market list, and those emails that deal with a
> particular Nomic's interaction with the Market just to that Nomic's list and the Market.  Only
> major things that affect all involved should be broadcast
> to all three.  Personally, I'm getting lots of double-posts because I'm subscribed to B as
> well as the Market.  And I'm sure that Thermo doesn't
> need to know the details of how B's stuff is going, or vica versa.  And there may be some
> players, especially those who don't devote as much time to
> playing, who aren't real concerned with events in the Market except as they directly apply to
> home.  If they want to look into it, they can check the
> archives.
>
> With that out of the way, here's an idea for reworking the Market:
>
> Rather than the Market simply declaring things that happen in other Nomics, and trying to
> interpert them, and trying to dictate specifics, I think the
> Market should be more of a standardized communication device, and each Nomicshould handle its
> own creation and destruction based on that communication.
> Here's what I suggest:
>
> First, before I get into the meat of this, there be a standard way that the Market looks at
> objects.  I'm thinking that each object have a list of
> Properties, which are named variables like "Name", "Charm", "Mass", "Text", etc; and a list of
> Attributes, like "Fuzzy" or "Pink" or "Wet".  Nothing
> else; these two simple lists will be all that gets communicated between the Market and the
> different Nomics.  To establish a baseline, there should be
> one required Property, which is Class, and can be Gnome or Coin or Kudo or Big Stick or
> whatever.  And to keep a good record of things, another
> property could be assigned and kept track of by the Market; a TransactionID or something, that
> the individual Nomics can largely ignore.
>
> Now into the important part.  I suggest things work like this:
> When someone goes to trade something, eir Nomic sends an Event to the Market, with the
> standardized object info and the Traders involved.  This
> event doesn't need to be a seperate email or anything, and once it's set up, the event can
> just be assumed to happen.  The Market then holds that info,
> and should the intended recipient accept, the Market sends that objetct's info to the
> recipient's home Nomic, and sends an Event to the sender's home
> Nomic that the object was given, and the sender's Nomic takes care of destruction.
> Should a player revoke an offer, or the offered object cease to be offerable (was destroyed,
> or the sender lost it, or something), the sender's home
> Nomic sends an Event to the Market, saying that the trade was aborted.
>
> All this can be simply what's written out, a single email to both lists from each Trader
> should take care of everything.  Just have the Events written
> out behind the scenes, so everything works out smoothly.  Here's a list of needed events:
>
> *object* = the object's full list of Properties and Attributes, _without_ a TransactionID
> *objectID* = the object's full list of Properties and Attributes, _with_ a TransactionID
>
> PlayerOffersObject(*object*,sender,receiver)
> Sent by senders's Nomic to Market.  Upon receiving this, the Market assigns it a TransactionID
> and sends the next event:
>
> MarketNotifiesReceiver(*objectID*,receiver)
> Sent by the Market to the receiver's Nomic.  This is so the receiver's Nomic can analyze the
> object and determine if the reciever may accept it.  If e can and e does, the Nomic sends the
> next event:
>
> PlayerAcceptsObject(TransactionID)
> Sent by the receiver's Nomic to the Market.  If the object is still being offered, the
> transaction concludes, and the Market sends the next event:
>
> TransactionCompleted(TransactionID)
> Sent by the Market to both the sender's and receiver's Nomics.  Signals completion, and both
> Nomics take care of destruction/creation in the approprate player's possession.
>
> OfferRevoked(TransactionID)
> Sent by the sender's Nomic to the Market.  Indicated the object is no longer being offered.
> After this, any Accept events for the tranaction will have no effect.
>
> Hmm... there should be an event to tell the home market what the
> TransactionID is, or maybe that communication could be a part of the Offer
> event.  Other events could be made as well, such as PlayerRefusesObject, but
> such really isn't necessary, as the players involved can just communicate.
>
> Finally, I think that keeping track of, or actually communicating, all the
> Events would be a royal pain.  So we should just assume they happen when we
> do the stuff, and actually track through the stuff only when needed.
>
> Orc in a Spacesuit
>

A lot of this is what I was thinking the Home Nomic sections of the Market Nomic's ruleset were
for, and why I thought that each individual Nomic needed a set of rules for "prepping" eir
things for introduction into the Market.

Let me give an example sequence:

1) I declare that I'm going to market.
2) The Thermo ruleset, says that all my Thermo::Player possessions then enter a state known as
"At the Market".  [These rules need to be defined]
3) The Thermo specific sub-ruleset of the Market examines my Thermo::Player's possessions, and
establishes appropriate objects in the possession of my Market::Trader self. [These rules also
need to be defined]
4) My Market:Trader self trades a Coin for, say, 1,000 BNS.
5) I declare that I'm leaving the Market.
6) The Thermo ruleset examines my Market::Trader's possessions, compares that with what my
Thermo::Player "At the Market" possesions are, and then creates and destroys things within
Thermo as appropriate. [More rules needing to be defined]

The equivalent set of actions could happen for a B Nomic Player.

Essentially both games (a home Nomic, and the Market) need some sort of synchronization rules.
You're message passing somewhat does this, but it isn't going to function very well between our
two Nomics at present, as, as far as I understand things, none of B's objects can exist within
Thermo, and what few object types Thermo has might not be creatable within B (I don't know for
sure), thus no reason to trade.  Thus what we need is a medium for exchange, the problem as I
see it is figuring this out.



_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss