I haven't seen any MMO games with vehicles with realistic physics and that could achieve high speed, why? Is it because of network bandwidth limitations?
Second Life has vehicles, but physics are poor and max speed is pathetic.
Yes and no (but mostly, no).
Any MMO game has several limitations that affect its physics. The most important of these is latency. Latency is time it takes a client to send a request to server and receive an answer back. Even in very best circumstances, this time is around 50-100 milliseconds. In real world, it can be as high as 500 ms. This means, that whenever a players does something - like, say, turns his car's wheel - he can see the game react to it only 100-500 ms later.
100 ms is actually quite a lot. Any game that has as much latency will feel unresponsive, and 500 ms feels downright unplayable. That's why game clients employ a lot of tricks to mask this latency. For example, the player's car can begin turning the moment he turns the wheel, without waiting for the server. However, these tricks only mask latency, and can never actually reduce it.
Suppose, for example, that we have two players in cars steering simultaneously towards one another. Each client will start turning its own car immediately; but the other player's car will not turn - because the information of it changing course has not yet reached the client, because of latency. Both players happily steer theirs cars, and then bam! - the server notices that they actually crashed into each other.
Situations like this cannot be prevented. No matter what clever prediction schemes we use, where there are other players, there's always a chance for things to go wrong. In any MMO game, about half a second that you just saw hasn't really happened yet, and can change in any moment. Now, in slower-paced games like traditional MMORPG's, half a second is not really that long. Characters only move maybe a meter or two during this time. However, if we're talking about fast-paced car race, half a second is a really long time! You could crash, like, three times in half a second (-8
Actually, a fast-paced game can work even with these limitations. It would have some unpleasant moments, but as long as all players have good connections, it would be playable. That's how multiplayer racing games work. However, there's another MMO limitation: the N-squared update count.
Imagine 10 players playing simultaneously. For them to see each other, the server has to send every player information about every other player. This means, in our example, 10x10 = 100 pieces of information to prepare and send. That's the number of players squared, hence "N-squared". This number grows quite fast, and even traditional MMORPG's begin to struggle when there are lots of players in the same area. For our imaginary fast-paced game with cars, these pieces of information have to be sent much faster than in a slower game. AND they probably are bigger themselves - you have se send not only positions, but velocities, acceleration, angular velocities etc. This means that any fast multi-player game can only have a limited number of players.
Both above problems cannot in principle be solved by software, only masked to some extent. They can be reduced a bit by limiting number of players - so, for example, a game where fast cars are only used in instances with limited number of players is probably doable. I believe that's what APB did. But a full open-world MMO game with fast cars is just not gonna happen. Not until we have quantum-entaglement network interfaces or something.
You have to deal with network latency and syncing the game state across the network. The faster the cars move the more notable the network latency becomes. Players might crash into a wall, because their game client fails to update the game state on the server due to network issues. Which isn't an issue when players move at walk speed ;-)
An MMO server has more load. A multiplayer racing game might run fine with 10 people connected, but will crash and burn if the server gets unresponsive under heavy load from hundreds of users.
Second Life's vehicle physics are just badly implemented. (Is this still alive?)
Garry's Mod is pretty much all physics. I don't think it counts as an MMO as such - though it will support 32 players per server - and that has the most realistic physics I've seen (not just vehicles).
I guess that there hasn't been an MMO designed with physics in mind.
They tried to accomplish this in a major fail of a game called all points bulletin. Well the concept was great the execution not so much. Random cars would appear out of nowhere. You would be driving and just hit a wall which would then turn into a car. I can see it being done somehow in the next five years though more cpu less gpu.
Let's look at your reference first.
GTA itself has a few problems with multiplayer, but this is to be expected. An example is when latency turns your car chase into a nightmare. Sometimes players kill each other because of the latency.
But latency is not the only problem, you can not run an MMO only with clients, you need servers and these servers have to manage most if not all of the physics to avoid cheaters.
So imagine having to run with thousands of players. Imagine also the stress on the CPUs during physics intensive activities. You can offset a chunk of the stress to dedicated GPUs. Bullet Physics has an implementation that runs on CPU.
But to avoid overload in a server you will need to implement a mechanism to handle dynamic zones redefinitions depending on players density. It is much more important in that case than in other MMOs.
It is doable. The issue here is the need to scale the game to handle more players and to run the main instance of the game distributed across servers.
If you manage to optimize your physics, transfer objects quickly and efficiently across servers and find a way to avoid mega crowds (instances for example), then you can do it with similar limitations as your reference and a few other ones due to the MMO nature of the game.
Remember that you don't have to send all game state updates to all players all the time, just the changes that are immediately relevant to the player should be sent constantly, the rest can be sent at a lower rate.