Timothy Lochner

To leave WoW behind for a second and talk about the massively multiplayer world sim problem for a second, though; you’re absolutely right - geography alone is pretty terrible.

Like, completely abstractly, the question we *should* be trying to answer is how to weigh the trade off of latency/complexity/visibility? Let’s take movement for example: a desired solution must be low latency and high visibility. Complex systems are out.

Can you take complexity out by interpolating between fixed positions instead of playing back movement streams? Can you reduce the number of positions as you get further away from the mover?

I feel like the “right” way to solve the problem is to break up a simulation using k-clustering (with interaction, not geographic weights) and move players among the clusters and their interactions shift.

But the problem rapidly becomes the Kevin Bacon game: where do you actually cut long interaction chains?

Interesting! I've always thought k-clustering was a good solution too, but never had an opportunity to try. Although I tended to think geographically, because for movement updates and combat, that's mostly what you want.

The clusters effectively create something of a voronoi pattern too, and it seemed like a good opportunity for LODing updates. In a neighboring cluster? Get every 2nd update. Neighbor's neighbor? Every 4th update. And so on.

Although, I do think that it's better for all this to be on one process, rather than a process per k-cluster, just for the headache of replicating across server boundaries. Instead, I'd be interested in seeing a process own a subsystem.