I perceive 10 fps as quite fast for a MMORPG. As always, it depends on what you do of course, but unless you want some kind of ego-shooter element in it, I don't see how this is necessary. Mind you, we're talking "RPG". Many updates per second cause more bandwidth (bandwidth = money) and considerably add burden to the CPU.

Typical actions in a typical RPG may take anywhere from slightly below a second to maybe 4 or 6 seconds. Your berserker does not swing his axe 5 times per second, and neither does your magician shoot fireballs as if using a machinegun. There may be some special attacks like a rapid double hit, but those can be implemented in one action and just be displayed differently by the client.

You will need to cheat in such a way anyway to hide network latency, which is unpredictable and can easily reach 100 or 150 milliseconds on the internet. Many online games compensate for that just fine, with anticipation and at the expense of being "correct". You can see this if you double-box side by side. If you do something in the right window, you'll typically see it in the left window with *considerable* delay. I've seen games where there is well over a second of discontinuity, and it is not noticeable at all in normal gameplay (that is, if you don't double-box).

I feel like 1 fps is probably too slow for anything real time, and anything above 10fps is probably a waste of resources, but as you say, it depends on your game design. My project currently updates at 5fps and that seems like a good balance.

Quote:Original post by TheBuzzSaw
How fast should I push the logic? Are there any articles on the matter? Obviously, recommendations will vary based on the individual game's needs, but I'm just thinkin' in general terms.

Two things to keep in mind:

The clients are trying to catch up with the server, but should never actually catch up. If the update is too slow the avatars will move to the destination and stop, waiting for the next change. If it is too fast the avatars will gradually slip farther and farther behind. Whatever you end up with, both the clients and server need to coordinate it.

Latency and bandwidth are the Great Evils of online play. The longer you take the more things need to be updated, and the more you transmit the longer it takes. Add the fact that latency is always changing, sometimes spiking to several seconds, sometimes even dropping packets. The updates need to be fast enough that the game looks good, but far enough apart that bandwidth and latency won't kill you.

It isn't an MMO, but my current game uses 10 updates per second and the largest possible update is 200 bytes. That gives 2KBps of raw data, or about 10kbps once you've factored in the lower-level overhead.

Considering much of the world is still on the 28.8-56k modems, and considering latency, and that you aren't the only thing on their computer, it is a bad idea to go much beyond that for general use.

If you are requiring broadband connections you can adjust it, taking about half of your minimum required upstream rate as your maximum bandwidth.

IIRC, Warcraft 2 ran at 4 updates per second.

The server can make such big jumps because they aren't so concerned with the rendering, animation interpolation, user interfaces, particles, and other minutia processing. It is only updating the positions and stats of the important objects.

Once you get much below 250ms, or 4 per second, users start to notice the delay.

It is often enough just to give audio and visual cues that something is going to happen. A tiny audio and animation clip can buy you quite a lot of time. Consider how in Warcraft 2, the units would mutter something after you issued a command. That audio cue meant the unit was going to move soon, so it didn't need an immediate visual response.

I'm a novice, but I'll share my experiences FWIW...

We crashed and burned on our first attempt at an MMO where the server was sending 5 updates per second and the update size varied quite a bit but was generally in the range of about 1k raw data (but wrapped in xml) per update. The bandwidth use per user combined with the high percentage of total active players connected concurrently at peak times made for a situation we just couldn't sustain. I believe it was about 800 users where our dedicated 100mbit pipe was saturated and all kinds of really bad stability problems were hitting us as a result. It was my first experience with any form of MMO and I wasn't prepared to throttle users or scale up the number of servers. So, like I said ... it crashed and burned. Server CPU wasn't a limiting factor.

Our new attempt is trying to stay at 1 update every 330 ms with each update having roughly 400 bytes of data (no xml, just raw data). We are testing to see if we can push this to 1 update every 450 ms without the clients feeling it.

The actual server gameloop is running at 3x the speed of the client update speed. Again, we're still working through our load testing, but we're trying to target 5k concurrent users per server with this approach. In another few weeks I'll post up some more hard numbers and a link to the prototype so "real" developers/designers can give me blunt feedback on how well we're hiding the lag, etc.

Hehe wow, you were actually sending xml? Usually you just use xml to define message formats on either end, not actually send it. =)