January 2009

• [Design] on the game mechanics of open questing Siege)
• • RANT: The Future of Quests Mike Rozak
  • • RANT: The Future of Quests Amanda Walker
    • • Players are shallow [was: The Future of Quests] cruise
      • • Players are shallow [was: The Future of Quests] Amanda Walker
        • Players are shallow [was: The Future of Quests] Mike Sellers
        • Players are shallow [was: The Future of Quests] John Buehler
        • • Players are shallow [was: The Future of Quests] cruise
          • • Players are shallow [was: The Future of Quests] John Buehler
          • Wikia MUD project Raph Koster
          • • Wikia MUD project Nabil Maynard
            • • Wikia MUD project Raph Koster
            • Wikia MUD project Peter Harkins
        • Players are shallow [was: The Future of Quests] Mike Oxford
        • • Players are shallow [was: The Future of Quests] cruise
          • • Players are shallow [was: The Future of Quests] Damion Schubert
            • • Players are shallow [was: The Future of Quests] Threshold
              • Players are shallow [was: The Future of Quests] John Buehler
              • • Players are shallow [was: The Future of Quests] Mike Sellers
    • RANT: The Future of Quests Mike Sellers
    • • RANT: The Future of Quests Damion Schubert
      • • RANT: The Future of Quests Mike Rozak
• [DESIGN] How big is enough? Ian Hess
• • [DESIGN] How big is enough? Mike Rozak
  • • [DESIGN] How big is enough? Mike Oxford
    • • [DESIGN] How big is enough? Vincent Archer
      • • [DESIGN] How big is enough? szii@sziisoft.com
  • [DESIGN] How big is enough? Siege)
  • [DESIGN] How big is enough? Threshold
  • [DESIGN] How big is enough? David Johansson
  • [DESIGN] How big is enough? Roger Durañona Vargas
• Persisting a MUD state with plain binary serialization Tiago
• • Persisting a MUD state with plain binary serialization Jon Mayo
  • Persisting a MUD state with plain binary serialization Jeffrey Kesselman
  • Persisting a MUD state with plain binary serialization Chris White
  • Persisting a MUD state with plain binary serialization Mike Oxford
    Tiago wrote:
    > Thing is, binary serialization has a few drawbacks, in terms of versioning
    > and it's a pain to control which parts of the graph are serialized or not
    > (it's perfect to serialize everything tough).
    Not sure what you mean by "binary serialization." Just copying out of
    memory won't work as I'm sure you're aware.
    
    Couple thoughts here.
    
    1) Version every single object. Every object knows how to serialize
    and deserialize itself, with a version header. You then pass around
    your "save context" and the object knows how to get itself out of it
    (switch() statement calling, say, DeserializeV1()) or put itself in. If
    you never have more than one "saved graph" you can even go with
    "Deserialize() and DeserializeFromPrevious()" or some such.
    2) You just version the entire graph. Every time you touch a
    meta-element (schema) ANYWHERE you roll the version up one. This leads
    to "version 1418437113" but it's an option. There is no "upgrade path"
    between versions.
    
    The problem with versioning "subtrees/subgraphs" means that the
    interactions across boundaries becomes an issue unless you encapsulated
    everything very very very well and don't pass structs and such.
    
    I would recommend #1 with good encapsulation/data hiding practices and
    virtual function calls. It's a bit more work but for any project of any
    size you'll more than make up for the time in maintenance. Also, #1
    gives you the ability to save everything out, stop the game, fire up a
    newer version of the game (with the correctly versioned deserialization)
    and everything will load.
    
    -Mike
  • • Persisting a MUD state with plain binary serialization Tiago
    • • Persisting a MUD state with plain binary serialization Jeffrey Kesselman
      • • Persisting a MUD state with plain binary serialization Mike Oxford
        • • Persisting a MUD state with plain binary serialization Tiago
        • Persisting a MUD state with plain binary serialization Tiago.matias@gmail.com
• [DESIGN] Clojure? Matt Cruikshank
• • [DESIGN] Clojure? Richard Tew
  • • [DESIGN] Clojure? Matt Cruikshank