xtank port: Am I basically screwed here?
BlitzMax Forums/BlitzMax Programming/xtank port: Am I basically screwed here?
| ||
| I've spent about 500 hours on a project to port and implement a modern version of the classic game xtank in BlitzMax. For those of you unfamiliar with xtank, it is a multiplayer tank combat game where players design vehicles and duke it out in a maze-like arena. The original game was designed to run on a bank of xterm clients, in essence treating the game server like a machine with (say) 8 monitors and 8 keyboards. All processing of input and generation of output was handled on the server, and the clients were responsible only for displaying the game output. The game only worked on a LAN. Performance was great. This architecture is archaic, and I envision something akin to a more traditional client/server setup. Each player would run the game on their PC, and communication would be handled by a central server whose main responsibility would be to relay messages between the clients. The game would be playable over the internet, and would have the interactive multiplayer feel of bzFlag (a pretty cool interactive online tank combat game not entirely dissimilar to xtank in some respects). The creators of bzflag have created a very slick environment where you rarely notice lag and vehicle movement feels very smooth, but the differences between xtank and bzflag make me wonder if the same will be possible for xtank. In xtank, vehicles move quickly, making sudden, sharp turns, and their precise location can be very clearly seen on the screen. And the vehicles shoot a lot of bullets. In bzflag, by contrast, tanks are slow, lumbering vehicles, with limited motion and slow, plodding shots. The graphic style is 3D, making it more difficult to visually pinpoint the exact location of a vehicle. Because xtank vehicles change direction so rapidly and frequently, even very short lags can cause dead reckoning algorithms to go wrong, making a vehicle appear to jump around a fair bit. I feel I have a respectable architecture in place, but I am not getting satisfactory results even on my own machine running just two clients -- pretty much the absolute best case scenario. I am coming to the conclusion that the nature of the game may make implementation impractical, and so I bring this question to the forum: Is is possible to implement a multi-player highly interactive rapid-paced arcade like game that plays well over the Internet? Are there any good examples out there? Can it be done in BlitzMax? |
| ||
| yes but it can be hard... checkout movement prediction and tweening remote objects back on real course when real and local info don't match up. |
| ||
| Try sending every keypress that occurs to the server, then out to the remaining clients, and use UDP. |
| ||
| It is possible, look at racing simulators, cars move very fast and lag isn't a big issue. There's a couple of things to bear in mind. Firstly the millisecs() counter isn't totally accurate, every machine can be up to +/- 5% either way of true time. You need to measure the time differential between each client and the servers clock and modify your delta accordingly. However you problem is more pronounced than this, because you've got problems on local loopback. If using TCP. Stop now. It's great for reliable data transmission but it's adding 30 odd bytes to every packet (it adds 96 I believe, UDP adds about 65 or so). Make sure that you are not using writeline() and readline() to send/receive data. When you send this over the web it will be truncated because writeline and readline end in a carriage return and this is what the web uses to close connections when browsing. Again, this isn't your problem, because it's failing on local loopback... Firstly, do away with timed packets. They do you no favours. Keep it in but set your packet times to 1 second. There is a reason for this, it's just a 'backup' in case a packet is lost. Add some bytes to your packet order: #define byte packetID #define byte verify Use these to order packets at the other end and request missing packets if the verify flag is true. Whenever the state of control keys is changed send a new packet immediately. This way you've just illimated 1000ms/packetsPerSecond of lag from your game. Send the control key combination being pressed and continue to process movements on the remote machine as if they are a local player. Using the above method so far should give you 100% stability locally, it should be perfect. If it isn't then there's a bug in your code. Now for remote play we need to adjust the local delta according to the speed of the server's clock. Measure a fixed interval (10000ms works ok) and send it to the server, remove pingtime from the calculation by requesting a receipt, then you know how fast the local delta clock moves. When receiving updates of positions that show your calculations to be innacurate, smooth the positional changes over time. It is true that fast moving objects are much harder to do multiplayer for, because the difference in ping between one packet and the next causes greater disruption. If you do it right, however, then it is still possible. |
   |