Netcode - How to design
Blitz3D Forums/Blitz3D Programming/Netcode - How to design
| ||
| Ok, I've never tried coding any netcode before but I figure my current project would be a perfect start to get experience. Still I just don't want to jump into it unless i'm certain that I do have a good design of my game so I know it's optimized for netcoding so here comes a few questions to those who might have more experience than me in this area: Gamedescription: Two players fight each other on a small fully visible arena. They control one unit each and the unit will probably have up to 3 bullets on screen at the same time. The player can before match choose from 10 different units so the steering, movements, weapons and their behaviour is very different. There are also obstacles on the battlearena (animated walls going up/down) Question #1: What kind of information should I send back and fourth? Is it simply position and rotation of the units/bullets? May I instead send over just controldata (mouse and keyboardpresses) and let both computers calculate it? Question #2: Who does the calculation? Will both the computers do collisionchecks or just the server? How do I transfer this correctly? What about velocities, damage etc? Question #3: Do you have any good tutorials or sourcecode where a similar game is setup so I can get any ideas? |
| ||
| It realy depends on if you want to play this over LAN only, or if it has to work over the web. Let me tell you, playing such a thing over the Web is pretty hard. Especially the moving walls make it hard to sync things correctly, and fairly. Maybe you'll have to use a mandatory Lag on the controls of all players, to be able to snyc things correctly. Because the web connection may take 200 millisecs or more. Dead Rekoning etc. as it is used for FPS games is not very usable here. So a LAN game would be much easier. There are several models. The most fair one is: one computer calcualtes everything, and the other computers only display things. This forces the mentioned LAG. At least, every player will see the things that are really counting. Whatever you gonna do, make sure nobody can cheat. For this you can send a checksum with every packet, that was made using a secret algorithm. The client will then use the paket only if the checksum is correct. There are several Network examples, in the archives as well as in the toolbox. They may work fine for you. MAybe you should use BPlay Lite from SurReal, that's free and open source. RakNEt uses an external DLL and allows a seperate thread for tcp calls during the came, so it won't pause (see userlib forum). |
| ||
| This will be a webonline-game only. It will all be connected via a lobbyserver that let players meet together and challenge each other. The lobbyserver will also contain lots of statistics and rankingsystems over all players. When a challenge is made and accepted the both players will be connected to each other (the challengercomputer will act as server in game) I've been studyin hard now (and as i can see it it will probably need lots of more studying) and this is some things that I was thinking about: I actually think extrapolation (and interpolation) is the way I must use with most units but i guess I probably will have to do one net-method for each unit (as they move very differently. Harder than I even expected. I am also thinking about each computer (both the server and the client) will calculate their own collisions and damage due to what happens on THEIR computer. They will also then send data about their own unit, it's position, rotation and gunstate. The only thing that server will control is the animated walls (will just send a moveup or movedown command to the client). Rest of the collisiondetection against wall is made by each computer. What will be the big flaws in this way of facing the netcode? |
| ||
| Even if you send the moveup/down commands from the server, there will be a lag, and it will be diffrent on each machine. It will be hard to sync things. One player may think he didn't collide, where he collided on the other players machine. Interpolation will be needed anyway, you can't sent a packet every frame (= 17ms), more reasonable would be somthing like 200 ms. If you find a good way to integrate a static Lag into the game concept then you might simplify the whole thing the way I suggested before. Sorry, I have no better Idea. Even in FPS MP syncing is a completely unexact science. |
| ||
| with UDP you should have no problem sending game updates every 17ms or whatever... The clients need to be able to change their view point and do a certain amount of movement independant of the server - with the server correcting that movement via updates - which is where client side prediction becomes important - if you were to send every mouse move and key press to the server and wait for the server to respond you'd get very jerky movement. |
| ||
| Something to consider is to take "screenshots" every 100 ms (a tick) and use those for references. So you can actually tell when the player *tried* to move according to their client, etc. And for the server, send the tick when a player is moving so the client can figure out "oh, they actually moved 300 ms ago, I should interpolate 300ms - 399ms into the future..." kind of thing. |
| ||
| call it "interpolate into the future", or "dead reckoning" it will however always be a vague guess of what's going to be. In a game concept that is based on quick reaction (eg. Ping-Pong) this can be fatal. Especially when the update frequence is higher than say every 100 ms. I still don't believe you can use a frequence of only 17 ms for the following reason: Data is transmitted trough cables, or trough the air by radio. Both use the speed of light for the transmission. Even if there is only one totally clean cable from EG. New York to Hong Kong, the distance is about 20 thousand kilometers. Since the speed of light is about 300 thousand km/s, it will take a min of 67 millisecs. In the real world there are lots of hubs, routers, gateways etc. that will delay it even more. A ping of about 200ms is realistic. So I don't see the sense of sending packets every 17 ms. Although the connection Lag doesn't have to affect the update frequency in theory, I guess this would end in buffer overflows and chaos etc. Please correct me if I'm wrong. (you may also consider there may be machines that will run with less than 60 frames per second) |
| ||
| I for sure know that 17ms totally impossible to achieve as you must make the game so mostly everyone can play it from around the world. Yes maybe if you are playing with people within your own region but not half around the world. It's at the moment physically impossible. Now, then again if such reactionbased game as UT200*** can make great (at least what it looks like) lagfree environment with let's say 8 people online (extra and interpolating all bullets and people) I think I could do that to at least playable level with 2 units. Still I know it's a hard task and using UDP I will start up with no interpolation at all and then start working my way back to some kind of smoothness in game. If we take Ping-Pong as an example, remember that the ball is very easy to predict it's course and you are updating your own paddle (and collisions) on your own machine giving no lag whatsoever. The only thing that you might find jerky is the other players paddle which in one way doesnt impact your gameplay. Now this is the 4 main different movements that can be used in the game I'm creating: Car-style: Meaning you accelerate with up, steer with left,right and reverse with down. Also you cannot rotate unit unless you do have some kind of speed. There is no skid whatsoever so when rotating it is kind of easy to somewhat predict where it will go (unless player does something else of course) Teleport: Now this is plain simple as the unit are not moving at all but teleporting to different places. No comments. 8-ways: Press up and the unit goes up, down it goes down etc. This one is the trickiest to predict as the unit can instantly change 180 without slowing in or rotating (well it does rotate but that does not impact the movement) Here it will be small interpolating with maybe lots of extrapolating) Floating: Just like Car-style except that it does contain lots of skid (like it's hovering over ground). So one vector for current movement and another one for thrust. This one may be tricky as well. Lots of interpolating and some extrapolating. |
| ||
| 17ms is extremely low *although* I did get out racer demo running on one update per frame (though in MP it ran at 30fps, around 34ms.) Thats a pretty impressive feat and we did test it quite playable with one player in the UK and the other over near California... |
| ||
| This is good to hear. What was the ping? I think we can say: Lag=Ping/2.0, right? How did you handle the lag? prediction? Or did you simply ignore it and accept some inaccuracy in the synchronisation of events? |
| ||
| "So I don't see the sense of sending packets every 17 ms. Although the connection Lag doesn't have to affect the update frequency in theory, I guess this would end in buffer overflows and chaos etc." The last bit is what I was trying to say the connection lag doesn't prevent you running a high update frequency - and it doesn't result in buffer overflows as the client is generally a fairly constant delay off the server and you just send the latest snapshot when they are ready - one of the important things is to make the network code work independantly of the renderer or you will get a lot of weird stuff happening and clients being able to use higher/lower fps to give themselves an unfair advantage. |
| ||
| Yeah, maybe I was wrong. I usually test my client/server code on one desktop, and there you better use a delay of say 200ms when there are multiple 3D windows open. But I totally agree, the framerate should not be connected with the net packet handler. Using a poll system may allow this even in plain blitz (without seperate dll threads). |
| ||
| Counter strike source is mine favorite. but it aint fun to have 200ms to Server.. that i can tell you :) in fact as soon as 50ms its realy crappy. |
| ||
| My only suggest (no, it doesn't answer any of your questions) is that you DO NOT make your players type in any IP information. It is a hassle that detracts from gameplay and also gives a "unprofessional" feel to your game. I have seen it all too many times with the multiplayer games around here; most require that you type in the IP address of the host. It is a really annoying issue that doesn't have to be there. Here is an example of how this can be done. Feel free to use any of the code. TCP/IP Network - WITHOUT typing IP's |
| ||
| This Lib of Krylar - didn't you say it's using DX9, does that mean it wont work with Blitz3D? I used to write however something similar too, although in plain Blitz3D. A PHP script is using a mysql database to store the active games. When the game host is calling the webserver for some reason, it usually takes several seconds until the handshake is complete, that's why a lot of people are using external DLLs to do that, that are running as a parallel thread in the background. A simple solution for blitz is not to wait for the answer, but read the webservers answer at a later state using a polling solution for incoming data (that needs an identifier, of course) And there's also Gnet: http://www.blitzbasic.com/toolbox/toolbox.php?tool=61 , that's what it was made for! |
| ||
| It works fine with Blitz - try my code. You just have to have DX9 installed on your computer (go to the microsoft website and you can probly find a free download. Any of the more recent store-bought games will likely have it as well. |
| ||
| Thanks. I have DX9 already installed. |
| ||
| No problem. You may use the code all you want. I just don't want anybody else to spend more than a week trying to find a way to join a multiplayer game WITHOUT typing in a stupid IP address. Yes, it took me nearly two weeks with the help of Kevin8084 to find a way to do this. |
| ||
| You may also want to contact RifRaf (from empowergames.com)... he is good at this type of stuff |
| ||
| But doesn't the K-Lib thing only work on a LAN? Not across the world? I suppose searching every computer everywhere would be too much... |
| ||
| There is no getting around using IP addresses to connect to network games on the internet... even if its just your mate on the same ISP, he could run a dynamic DNS host but you'd still have to type that in... The best I've seen so far is battle.net but that requires the developer/publisher to tie up some signifcant hardware costs. |
| ||
| For online games, yes, either you type in an IP address or the developer sets up a server. (ex. Blizzard set up battle.net) For a small online game, try GNet. (I personally don't know much about it, except that it is hosted right here on blitzbasic.com) But PLEASE!!! don't make the players have to type in IP addresses for LAN games. |
| ||
| What about having a website that somehow stores the number of online hosts and their IPs, for games that are hosted on players' computers? Can PHP do that? |
   |