A new client/server model

[sidereal]

One of the more serious constraints on MMORPG developers is server resources.  Lack of server resources results in extensive instancing, reduced interactivity, putridly stupid AI, and so on.  The primary reason for this is that the games are heavily server-weighted client-server apps. . to the extent that most clients are just pretty-graphic rendering dumb terminals that maybe do a bit of trajectory prediction.

The main reason for this, of course, is that a good percentage of the playerbase is made up of tablescrap pilfering grabasses who would crush their mother's skull with a jackboot if it increased their mana regen rate, and they will cheat if you give them any control.

As is often the case, game developers, being the neurotic prima-donnas that they are, fail to realize that software often is an analogy of the real world and the real world has already provided solutions to many of their problems.

Take taxation.  A significant number of tax-payers are tablescrap pilfering grabasses who would . . etc.   In the MMORPG model, the IRS would simply do your taxes.  They would get all of your income statements, and track every expenditure, send you copies, and then tell you what you paid.  This would be fucking burdensome.  Instead, they do two things.  They red-flag anything that stands out as absurdly wrong, and they investigate it.  And they randomly audit.  Between those two, the system more or less works, and the IRS doesn't have to employ 15 million people to get it done.  The same model applies.

A majority of the computational functions can be farmed out to the clients.  Probably even monster AI.  You have tasks constantly watching the game state, and if a player acquires experience or wealth or anything else absurdly out of place for their level, you red-flag it and either dig through detailed logs or hook up an audit process to their setup, in which a server thread cocomputes their environment in realtime looking for cheating.  Also, you have a flexible number of audit threads that just do this all the time to random clients at random times.

The delegation of server resources to clients can be done intelligently, so clients are tested for quality and the fastest machines with the biggest pipes naturally graduate to be supernodes and take over more of the work.  Having this work shifted around also reduces the quality of cheats, since you never know when you'll be responsible and when you won't.

So let's get started

[Viin]

I believe some of this is done already. I know that at least some of the MMOs use a comparison technique to make sure the client is behaving as it should.

While having the client do some of the work would be awesome, how do you know who does what in a multiuser environment? Does Bob control Mobs A B C and D while Joe controls Mobs E F G? Who handles the distribution of the client's processing? Are we talking Peer-to-Peer or is the server handling it?

I've not seen too much about the server side of MMOs, but isn't the main bottleneck connections and network throughput? If zones/instances/shards/whatever are handled properly, I don't see how a beefy server couldn't easily handle thousands of players along with whatever AI pulses it needs to take care of. Maybe the auditing of client commands is the bottleneck and does need to be offloaded onto it's own cluster?

I guess my point is: how do we know it's the AI and physics that's causing the bottleneck? Or did you have other things in mind for the client to handle?

[Samwise]

Pushing some of the processing off onto the client saves a lot of network bandwidth in addition to server CPU (which I agree probably isn't the bottleneck in most cases).  If the server is the one computing the behavior of (for example) an AI, it needs to keep updating the client on the AI's position.

Conversely, if the server can simply tell the client "you found a mob at these coordinates, have fun", and the client runs the encounter on its end, the server and client don't need to communicate on that matter again until the encounter is over.

I agree, though, that things get tough once multiple players are in the same area.  Peer to peer seems like a good way to go - pick one of the clients to be the "server" for that encounter and have it handle all the interactions of the other clients, reporting back to the central server when appropriate.

[ajax34i]

It's true that I do my taxes myself, and that saves the IRS a whole lot of cost, but no one else needs to know the result of my taxes.  Whereas in MMORPG's, in a lot of cases the result of a computation must be sent to multiple computers, and since net traffic is the speed bottleneck, the best place to do said computation is on the server.  It'd be horrible if someone in Japan had to report the result of every sword hit back to the server, so the server could then multicast that to the rest of the group and me in the US, considering that it takes half a second for lightspeed to travel half way across the globe.

As far as peer-to-peer networks, doing that will disable a major security feature:  the fact that I don't know any other player's IP address.   A peer-to-peer connection between clients would make finding IP addresses easy, and then DOS attacks can be finely targetted to anyone you wish to disconnect so that you can prevent them from looting or PVP their linkdead defenseless toon.

In addition, for the client to be able to do said calculations, it must actually have the code locally.  Not only do hackers get access to the client code, but now they get access to portions of server code...  If my client calculates to-hit chances, it must do it exactly like the server, so in effect you've just told me exactly how the server does it.

And finally, despite PC's being extremely fast nowadays, they're still pretty much struggling to compute most of the new games, and not just graphics.  To make it all work, instead of designing a client to run well on a 3 GHz processor with 1 GB RAM, you're forced to cram the client AND portions of the server processing on the PC box, meaning you need to desing a client for 2 GHz and 500M RAM, and server for 1 GHz and 500M Ram.  In effect, both the client and the server are less than cutting edge.