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
        According to Mike Oxford:
        > You're going to hit technical limitations for scalability as well as
        > your planned content base. Doesn't do much good to plan for 500 hours
        > of content (projecting 3-5k players at a time) and then be capped at
        > 1000 concurrent users. C10k today may be C20k in reality with today's
        > hardware (I haven't done any profiling in a number of years,) but it's
        > just a heads-up to keep your pipes/memory/bandwidth/CPUs/etc in
        > consideration.
        
        Note that you do not need to serve every single simultaneous player
        from a single server front-end. Unless you plan for large-scale
        battles in which the entire server gets concentrated on a single area,
        you are better off with segmenting your world into individual zones,
        with a transparent or specific zoning (transparent zoning means you're
        handed off to a new server at "an appropriate time" without any
        obvious effects, while specific gives you the loading screens almost
        every MMO player is familiar with).
        
        You usually need multiple servers to handle the game world itself,
        so your architecture can either have a lightweight front-end that
        essentially dispatches incoming connexions to the various zone back-ends
        (which, if I remember right, is how UO worked), or you have a master
        control system that tells your client to switch from one zone server
        to another (which is how EvE handles its enormous world cluster, I
        think).
        
        --
        Vincent Archer Email: archer@frmug.org
        
        All men are mortal. Socrates was mortal. Therefore, all men are Socrates.
        (Woody Allen)
      • • [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
  • • 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