http://www.stackless.com/ stackless python
See in particular the articles about Eve, who co-developed this to produce a non-sharded world (in other words, one that isn't split into virtualized incidences walling players in different 'dungeons' away from each other).
Eve can get away with fudging some of these problems to an extent because it takes place in space and so travel is achieved by use of things like warp gates and hyperspace jumps - you can just fly off into space with normal engines but given the astronomical distances being simulated this isn't practical for actual travel, only for tactical combat advantage (scouting or sniping at enemy ships).
As with a most other online games, players tend to congregate around a central point because of navigational and trade benefits. In Eve's case this is a system called Jita which regularly had 500 ships in one local volume, leading to horrendous lag. Load balancing can become a particular problem and so does client bandwidth since you're suddenly trying to feed everyone 1000 vectors per second.
Having played EVE I would suggest they use shard more than most games, they just let you move from one shard to another. They might call them star systems and let people move between them. And they don't repeat exactly from shard to shard, but that just means the world is filled with the same random quests given out by different NPC's. The point of shards is to limit the number of people in each area and they don't let 5,000 players into the same zone at the same time.
You could do the same thing with a classic MMO by having limited resources in a zone that respawn in real time. It actually a reasonable idea, kill all the gnoll's in that dungeon and they don't respawn. However, it's more fun to for most people to be able to repeat the same dungeon over and over with little effort. You could do the same thing with quick movement between zones but then you get the empty feeling when there are not enough players to fill the world.
It just works better in space, however, awsome random content generation could do the same thing on land.
PS: As to the market's being linked, City of Heroes does the same thing; all shards share the same market.
One thing has been bugging me about Eve lately: why are the "shards" tied to physical locations of all the same granularity?
If you made the unit of player interaction a "shard" this would yield inherent dynamic load balancing.
How about a space game that doesn't have any fixed locations of importance? Have space be huge, mostly desolate, scattered with raw resources. Everything is in terms of "motherships" warping between star systems, occasionally stopping at a system to gather resources. Players would berth their smaller ships aboard the motherships or at stations in the systems. However, everything of importance (resource spawns and quest sites) would only be reachable by hitching a ride aboard a mothership.
Most player ships would only be capable of warps spanning in-system distances. Really wealthy players would be able to buy their own "motherships." Motherships would be invulnerable to attack while in-system, due to the use of the drive fields in a defensive configuration. However, while in-transit between star systems, motherships are subject to "warp-intercept," which is the formation of a warp-bubble or "pocket universe" around the two ships when they get too close to each other in warp-space.
Motherships cannot be destroyed, but they can be captured. To capture a mothership, one needs to mount an attack with player ships and destroy enough of the mothership's defensive fields and guns to allow boarding. Boarding switches the game to an FPS mode, with the object of securing one of the ship's "command centers."
Some NPC motherships will be capturable. However, maintaining control of one of those will require a 24/7 presence. At the point that no players occupy the command center, a NPC mothership will revert to NPC control.
It does feel like shards because of the gates and the relative similarity between galaxies but the fact is that if every inhabitant of the game were to move towards the center they would all eventually converge (assuming the system handled it,) something not possible in true shards.
The game engine still fails if to many people gather in the same area. The game design and zone limts artifically avoid this, but it has nothing to do with stackless python.
What I should have said is each zone runs on a seperate physical server (or part of one) and their innovation is to build a game that let's move across HW systms with little issue.
Note: They use a shared database for some game states, but they don't let any CPU read memory from any other CPU directly. It's a question of system archtecture not language features.
- totally dynamic load balancing on the servers
- cross-game chat at all times
- cross-game market (well, there are multiple regional markets but distance is part of the game mechanic).