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
    On Fri, Jan 16, 2009 at 4:51 AM, Tiago <tiago.matias@gmail.com> wrote:
    > Hello all!
    >
    > I'm building a (classical) MUD server as hobby. I would like to have a fully
    > persistent game state and thought of using simple serialization to dump the
    > entire object graph to disk periodically.
    >
    > 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).
    >
    > So, I would like to hear if someone here has had any (bad) experiences with
    > serialization (applied to this particular domain) and if they recommend it
    > or not.
    >
    > Thanks!
    >
    > tiago matias
    
    I just append my binary blobs to the end of a journal file and update
    hash table entries to point to the new offset. I write the entire
    record out to the journal so book keeping of the blobs is relatively
    simple. When I boot and reply the journal I immediately rewrite a
    compacted journal to a new file (and rename the old file to a backup).
    Compacting can be done as often as you like, but in my system it means
    you're writing the entire graph to disk in one go. Which causes a
    moderate amount of pausing for players depending on disk performance
    and size of the graph.
    
    I keep a generation number in every object, but I don't use it for
    anything. It turns out I didn't need it. And accessors for setting all
    the fields of an object also set a dirty flag so I know that it needs
    to be serialized.
    
    My binary serialization uses a printf style string to describe the
    format. It was easier than my other experiments using ASN.1 to
    generate routines or doing it by hand with a (large) hand rolled
    function for every type of object. I think if I were to do it again
    I'd write an XDR parser (as in Sun RPC) and my own code generator, the
    printf one was neat in that I could get gcc to warn if I passed the
    wrong thing, but with many many fields to dump I either needed a
    function that took many arguments or I needed to call the routine and
    update an buffer offset each time to do the serialization process.
    
    --
    Jon Mayo
    <jon.mayo@gmail.com>
  • 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
  • • 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