No NOT a turn based RPG's that's NOT what I'm talking about. Ever heard of fighter Ace or Air attack years ago? They were massively multiplayer flight combat based games that could support an (X) amount of players. Don't jump to conclusions thinking you know what I'm talking about before asking, ok?
Flight Sims combat is not really all that different from an RTS. The game loop is dominated by client-side simulation, it's mostly all deterministic except for user I/O, and user I/O patterns in flight sims are very different than FPSes, and there are few if any non-linear events introduced by the server. Velocity changes are gradual and predictable, you don't see enemy planes able to point in any direction and accelerate nearly instantly in a single frame, but you do get that in FPSes, where users whip the mouse around, that's why FPSes end up sending control updates anywhere from 20-100hz, and because of server generated events (e.g. admin plugins for example "Ultra-Kill!") you have a separate command channel for all these server generated events which disrupt client-side determinism.
In FPS games, you have outgoing packets practically every frame updating the server on the user's current state (new forces and constraints that modify the position/velocity of the user, events like switching stances, weapons, firing weapons, character emotes, etc) And for accuracy sake, the server has to have a very high sampling rate of client I/O. We're talking games where you snipe people at long distances, and the hit box records hits down to very small areas. The DICE engine fails miserably in this regard IMHO, the experience is pretty bad compared to a game like DoD, the sniper rifle sucks ass. Anyway, when you have 64 clients sending you constant updates, client-side simulation has its limits as it is quickly invalidated, which is why games like CS transmit entity updates at high frequency, and limit client-side sim to position interpolation and non-interactive effect physics.
Interesting but I doubt it was more efficient then the limitations the games VR1 made 8 or 9 years ago. The games I'm talking about predate both CS and starcraft by years, supported more players via the server, and ran on dial-up connections. Those games are dinosaurs by todays' visual standards but the networking software could still hold up anything out there today.
Apples to oranges. Flight Sim != FPS, the bandwidth and latency requirements are far lower. And the less dynamic the character (no fast weapon switches that are externally visible, no emotes, no character model changes initiated by user. Hell, did Fighter Ace even show Rudder/Aileron/Flap changes on the plane models?)
I could make a multiplayer flightsim run on 1200baud modems if all I ever needed to do was transmit simple force corrections at 15hz for a convincing simulation. I played Modem Wars on my Commodore 64 at 300 baud (real-time RTS with action/shooter elements) and it worked fine.
Even still just because this article says these two games have a small packet size doesn't mean they are the most optimal games out at the time.
Packet Size is proportional to latency and churn. If you use larger packets, you face more fragmentation, you lose alot more data if a packet is lost (easy with UDP), and if you opt for larger packets, you must aggregate several updates worth of info. If you're updating at 60hz, and all the user did was press the fire button, you can't increase packet size unless you wait a few frames to collect more data to send. Likewise, the server already uses compression and filtering to reduce transmitted data. if a user is standing in a particularly quiet part of a map camping, there is no choice but to send this client small packets, since nothing is going on.
It's better depending on the type of game. Or it might not matter at all depending on the size of the game. You know there's lots of games out there that used servers and when you meet up with someone it disconnects you and re-connects those users directly. Again I wasn't talking about turn based online games MMORPG, or RTS games. Stop putting words in my mouth please. I mentioned massively multiplayer. that doesn't mean it's an RPG.
Any massively multiplayer game is going to be better with a dedicated server than not, period. I don't care if it's RPG, RTS, Racing, FPS, whatever.
First, the larger the number of users, the more you need to locate the server at a network junction that has a shorter path to the most number of users. If you've got hundreds or thousands or players, not using a dedicated co-located server is going to balkanize your playability with a few lucky bastards being able to have a quality game together.
Secondly, the more players, the higher the probability of routing issues caused by fubar'ed NATs, more easily solved by DMZ servers at co-los. This is not speculation, it's fact.
Third, higher bandwidth takes pressure off peak scenarios that cannot be easily forseen as the game scales.
Fourth, the lower the network requirements, the higher the degree of simulation needed on the server, which means whoever is hosting the game must devote more CPU per client, not good for predictable and resource-constrained consoles, where now, everyone's game code must fit the requirement that they be able to run a server concurrently.
Fifth, there is less room for cheating and security exploits when the server code is centrally administered and acts as validator.
Sixth, many many users, especially in the US, has crappy upstream bandwidth. "128k DSL" is not a myth. DSLReports shows over 50% of people have less than 200kbps upstream peak.
Anyway this is way off topic, but I find it annoying to see people assuming dedicated servers mean a lag free gaming experience . As I was saying before I don't think a dedicated server is needed for anything bigger then 64 players.
No one ever claimed "lag free", the predominant claim is *better lag*. As for optimizing CS packets, good luck. The entity information distribution is already very efficient and compressed. It uses both visibility information and delta compression. Every frame, the server transmits the new state of every entity to every client. However, it only transmits entities that are visible to each client, and it only transmits what's changed since the last client update (delta compression). The information sent is mainly a few floating point numbers for yaw/pitch/velocity/position/etc, and data compression on these packets isn't going to do much.
More compression would save only a trivial amount of bandwidth. The only way to reduce bandwidth is to reduce the update rate, but CS users are used to high Hz updates, and reducing it lower will seriously detract from the gaming experience (you can try it yourself, set update rate to 5 or 10 and see if you like it better than 20 or 30)
), but it'll be hard to know just how much of an influence something like Home will have on things until probably three years out from now. We'll have initial reports from the Beta starting sometme soon I imagine, which may give an indication as to the staying power of this concept.
