Because they DON'T work best?
Problems with pure server based architecture:
1. Clients on modems find that their input lags, or that when they move, sometimes the server moves them back. When the lag is very bad, sometimes they will run up a hall, only to suddenly warp back to the start stuck against a wall.
If you have high speed internet you might not realise this is the case, but that is how gameplay was for me on a modem when playing Wolfenstein only a year and a half ago.
In a third person game, especialy a tank game where the characters are only supposed to move forward and backwards and turn smoothly, this client-local warping would look terrible.
My method does not suffer from this, even with very high pings.
2. Players with high pings appear to warp about the map, sometimes dissapearing and reapparing in new locations far from where they were.
Again, my method does not suffer from this. Players NEVER warp. They almost always move exaclty as they would if they were playing locally. Only lost packets can result in warping, and that happens very rarely.
3. Clients experience lag when moving as stated above, but they also experience lag when firing. Player pushes a button, and nothing happens for 200-400ms as message goes to server and comes back. Games like Half Life hide this by making you SOUND like you're firing, but you realyl don't start firing for 200ms, or however long it takes the message to get to the server. My tank game however fires single bullets. I can't just play a sound of the player firing. I have to show a bullet coming out. But if the bullet's location is dictated by the server then it won't start moving for 400ms if your ping is 200ms. That would look stupid. And bullets would appear out of thin air after your tahnk has moved on... Unless your tank is still sitting there 400ms later because you can't move until the server tells it it has moved.
4. The best way to code a server based system is to have one set of functions for doing all the things that the network dictates. Like firing. And those functioons would handle all the motions of objects and the spawning of them. But I am using BlitzPlay Pro, and that cannot broadcast a message to all players which also goes back to the server itself. So I need to have seperate functions for performing the same actions locally as I need the net to perform. Naturally I want to reduce code duplication as much as possible, lest I indtroduce bugs from things changing in one function but failing to be changed in the other. The only alternatives here would be to code some sort of messaging system on top of BlitzPlay Pro, to send messages to the server itself that the server sends, but this would cause all sorts of headaches.... And fixing BlitzPlay Pro is not an option as it is very complex. And writing my own netplay lib that does all the things Blitzplay Pro does would take months. As would swithcing to a new lib if a better one existed.
Problems with pure server based architecture:
1. Clients on modems find that their input lags, or that when they move, sometimes the server moves them back. When the lag is very bad, sometimes they will run up a hall, only to suddenly warp back to the start stuck against a wall.
If you have high speed internet you might not realise this is the case, but that is how gameplay was for me on a modem when playing Wolfenstein only a year and a half ago.
In a third person game, especialy a tank game where the characters are only supposed to move forward and backwards and turn smoothly, this client-local warping would look terrible.
My method does not suffer from this, even with very high pings.
2. Players with high pings appear to warp about the map, sometimes dissapearing and reapparing in new locations far from where they were.
Again, my method does not suffer from this. Players NEVER warp. They almost always move exaclty as they would if they were playing locally. Only lost packets can result in warping, and that happens very rarely.
3. Clients experience lag when moving as stated above, but they also experience lag when firing. Player pushes a button, and nothing happens for 200-400ms as message goes to server and comes back. Games like Half Life hide this by making you SOUND like you're firing, but you realyl don't start firing for 200ms, or however long it takes the message to get to the server. My tank game however fires single bullets. I can't just play a sound of the player firing. I have to show a bullet coming out. But if the bullet's location is dictated by the server then it won't start moving for 400ms if your ping is 200ms. That would look stupid. And bullets would appear out of thin air after your tahnk has moved on... Unless your tank is still sitting there 400ms later because you can't move until the server tells it it has moved.
4. The best way to code a server based system is to have one set of functions for doing all the things that the network dictates. Like firing. And those functioons would handle all the motions of objects and the spawning of them. But I am using BlitzPlay Pro, and that cannot broadcast a message to all players which also goes back to the server itself. So I need to have seperate functions for performing the same actions locally as I need the net to perform. Naturally I want to reduce code duplication as much as possible, lest I indtroduce bugs from things changing in one function but failing to be changed in the other. The only alternatives here would be to code some sort of messaging system on top of BlitzPlay Pro, to send messages to the server itself that the server sends, but this would cause all sorts of headaches.... And fixing BlitzPlay Pro is not an option as it is very complex. And writing my own netplay lib that does all the things Blitzplay Pro does would take months. As would swithcing to a new lib if a better one existed.