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
    Ian Hess wrote:
    
    > I've been thinking about a world size in terms of howlong it could take
    > a determined character to walk fromone side to the other. I was curious
    > if there are othermetrics that might be better used to determine a
    > maximumscale to plan for.
    
    You first need to answer (at least) two questions:
    
    (a) How many players will occupy a shard at one time?
    
    (b) How many hours of content will there be? (Or, how many hours of play
    before most players get bored and go elsewhere.)
    
    
    Here's how the numbers fit together:
    
    Player density is important. If you have too many players in an area, the
    game feels more like disneyland, waiting in line. If there are too few, it
    feels like a poorly written single-player game. When I played WoW (a few
    years ago now) it felt like a good player density. If I stopped at a quest
    site and waited, another player (doing the same quest) would come along
    every 6-10 minutes. Inverting that: you need 6-10 players per hour of
    gameplay in each shard. What that means is that if I have a game with 500
    hours of content, I need a world with 3000-5000 players.
    
    How many hours of content is important depending upon what market you're
    going after. Game playing time (even for non-MMORPGs) has gotten shorter
    over the past few decades because players are less-and-less hardcore. Fable
    1 was about 15-20 hours. Mass Effect about 20. Fallout 3'd main quest around
    30(?). Baldur's Gate was... immense, 50-100 hours(?).
    
    So, if you want a game that can actually be finished by a majority of
    today's players, it needs no more than 20 hours of content. x 6-10 players
    per hour => 120 - 200 players in a shard. How large does your world need to
    be so that 120-200 people fit it in comfortably? Not that large.
    
    If you target your game at hardcore players who can commit 500 hours, then
    you need 3000-5000 people in a shard, and a much larger world.
  • • [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
  • • 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