Hi, Is a multiplayer phyiscal game possible to become as smoothy as other types of game like MMORPG? i dun have any XP with that,but i'd like to make one. Best regard, Tim

Iam working currently on a realtime multiplayer game, with a maximum of 6 players and it is a lot of work.
I had done games before, but the additional multiplayer part must be considererd in every "normal" aspekt like graphic, AI and input, this is what it really makes it complicated.

But hey, nothing is impossible :-)

When you say, you have no experience, do you mean experience in game programming? When the answer is yes, i would recomment that you make an easier game first.

I can only agree with TimChan. It's tough work to make work right, look right etc. Nevertheless, it's possible. But I strongly suggest to make yourself acquainted with advanced mechanisms for dead reckoning, synchronizing, fighting lag, etc.

-codeandroid

I have programmed the multiplayer part of the commercial game FlatOut that was recently released in Europe, and will be released in Q1 next year in America. So here I'm speaking with the experince I got from programming that.

It's not physically possible to get it as lag free as MMORPG games, due to the speed the cars move. Think about it for a second. A car travelling 200 km/h, travels 55 m/s. Assuming a ping time of 200ms(a very good Europe to USA connection). Let's also assume we send the packets directly, and not through a server. That means, that the car travels 5 meter in that time. That's a long distance if it travells in the wrong direction, say a sudden direction change.

However if your prediction is good, that means that it uses the same or almost the same physics as the real game, you can greatly reduce the wrong predictions. Simple dead reckon is good, but the more advanced physics engine you have, the more it will go wrong. To get it as good as possible, you need to use all the info you possible can get, throttle/steering, acceleration, speed, rotation, rotation speed and so on.

Collisions are very hard to predict, especially with two remote cars, because you don't have the real position for either of them. If you are doing it clientside, which I strongly recommend(I'll explain why later), then you also have the problem of processor usege and complexity to face. To reduce this you could predict what's really happening when colliding, only during the simulation between the actual predictions. So your system would work roughly like this. When you get a packet, you predict where the car would be at the current time, then it goes into simulation mode and runs full physics with all collisions, until the next packet is received, and then the cycle starts over again. What is important to remember here is that the simulated position might be more accurate than the one that you just predicted(as the prediction is simpler than the real physics), so a clever system for detecting when this is the case is needed.

Ok, now back to the clientside thing that I mentioned earlier. A racing game needs to be responsive, there can't be any delay between the controller action, and the car reacting. In the same way you expect the other cars to react exactly at the same time as you collide into them. You also don't want to have correction of you own car position ever, as that would be REALLY annoying for the player, and in worst case could cause him to crash, when put in a situation he can't recover from. From all this comes that fully server based prediction is practically impossible to do. There would also be problems if you combine server and clientside prediction, as the server state could never be fully right(remember it can't move your local car). A dedicated server could still be used however, for example by having it detecting cheats and so on if wanted.

So following from this there's almost no advantages with a server/client based topology, commonly used in other types of games. It only adds additionally latency, which is the major thing you really want to avoid. So I recommend a peer to peer based sollution, as you get the best possible latency you could that way. Internet connections are also getting faster all the time, so the additional upload bandwidth required should not be a major issue, unless you want to support modem users. NAT and firewall issues are the major problems with this.

Another trick to reduce the latency is to use faster packet rates. With faster packet rates, you will also reduce the time the car is predicted wrong after an abrupt position change for example. However this should of course be balanced with your target bandwidth. You could even using some clever bandwidth throttling system.

There's tons of more things I could write about this topic, but I think this is good for a start.