I've been playing on my phone's Internet sharing these last few days, and XIV uses about 15-30mb per hour of play. It's much more sensitive to latency and jitter than it is to bandwidth. Really, when you think about it, the game can send extremely small bits of data to tell the client what's going on; you need 32 or 64 bits for an event ID, plus 3-4 more of these for event parameters (target, coordinate location of effect center, actual effect to display). MMOs typically don't transmit a lot of position or asset information for objects not in the immediate vicinity of the player, and even then, we're still talking a few bytes per character per update (current position, motion vector, asset ID, some packed array to specify the rendering if it's a player character).
In terms of the AI, the real limiting factor is the speed of the simulation. A game server typically needs to run at twice the frame rate of its clients at least to get an acceptable simulation speed; otherwise, you get people getting killed by attacks they escaped, "You can't do that right now" messages, etc. The time in the game loop between frames is, thus, rather short. Single player games have less to deal with (they don't have to update 1000+ mobile object positions, process several hundred combat and other events, manage crafting results, transfer characters across instances, etc.) so they have more time for their AI routines. That said, complex goal-driven AI is tough to do and requires substantial computational resources, which is why you only see something similar to the state of the art in games that tend to make it their selling point (such as Bethesda games). Natural language processing is functionally impossible to do in a game because of its obscene processing requirements.
One way out of this is event-driven programming, but event-driven games aren't as well understood from a performance standpoint and are harder to code due to their much more complex multithreading. The other approach is to offload as much as you can to the client; for instance, world collision detection and self animation is done client-side. The problem here is that the client lives in a hostile environment, so you can't really trust anything it says. Trusting the client is how you get speedhacks, teleport-hacks, and the like. In EQ, for instance, the server always trusted the client's statement of the character movement vector, so the speedhack involved altering that value on the client to have an excessive speed component. Later countermeasures (having the server periodically send out an update to that) were defeated by patching the client or having a debugger rewrite that part of RAM.
At any rate, I hope the above sheds a bit more light on the way these servers typically operate.
In terms of the AI, the real limiting factor is the speed of the simulation. A game server typically needs to run at twice the frame rate of its clients at least to get an acceptable simulation speed; otherwise, you get people getting killed by attacks they escaped, "You can't do that right now" messages, etc. The time in the game loop between frames is, thus, rather short. Single player games have less to deal with (they don't have to update 1000+ mobile object positions, process several hundred combat and other events, manage crafting results, transfer characters across instances, etc.) so they have more time for their AI routines. That said, complex goal-driven AI is tough to do and requires substantial computational resources, which is why you only see something similar to the state of the art in games that tend to make it their selling point (such as Bethesda games). Natural language processing is functionally impossible to do in a game because of its obscene processing requirements.
One way out of this is event-driven programming, but event-driven games aren't as well understood from a performance standpoint and are harder to code due to their much more complex multithreading. The other approach is to offload as much as you can to the client; for instance, world collision detection and self animation is done client-side. The problem here is that the client lives in a hostile environment, so you can't really trust anything it says. Trusting the client is how you get speedhacks, teleport-hacks, and the like. In EQ, for instance, the server always trusted the client's statement of the character movement vector, so the speedhack involved altering that value on the client to have an excessive speed component. Later countermeasures (having the server periodically send out an update to that) were defeated by patching the client or having a debugger rewrite that part of RAM.
At any rate, I hope the above sheds a bit more light on the way these servers typically operate.
The Freelance Wizard
Quality RP at low, low prices!
((about me | about L'yhta Mahre | L'yhta's desk | about Mysterium, the Ivory Tower: a heavy RP society of mages))
Quality RP at low, low prices!
((about me | about L'yhta Mahre | L'yhta's desk | about Mysterium, the Ivory Tower: a heavy RP society of mages))
