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
>From: Vincent Archer <archer@frmug.org>
>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).
This is true, but not all games will scale that well internally. Not
all games will grow to UO/EO/WoW proportions. It's just something else
to consider is all, that regardless of how big we may want to make the
world a grandiose plan still has to fall within the technological limits
(and the price to build out that technology) which not all companies can
attain or support.
-mox
- [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 DuranĚ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.matias@gmail.com
- [DESIGN] Clojure? Matt Cruikshank
- [DESIGN] Clojure? Richard Tew
- [DESIGN] Clojure? Matt Cruikshank