Allright, Ive known the basics of networking(BSD sockets) for sometime. However, I recently moved from linux to windows, and decided to begin learning Windows programming and Winsock. I wrote a simple Pong game(in GDI, using Winsock async sockets), which has a client-server model. 2 clients connect, and the game starts. Works fine...and data is being parsed and sent and recieved all perfectly. However, the way I am making this pong game forces the clients to handle almost all calculations(server sends a toggle for every tiem the client moves the paddle(1/-1/0 for up, down, or stop)). This means that the client and server must sync up properly, which they do not. The problem is as follows: I press the up arrow, and process a WM_KEYDOWN message to send data to the server(MSG_UP), which sends it to the other client. If I reliease the up arrow immediately, a WM_KEYUP message is recieved, and a message is sent to stop the paddle moving(MSG_STOP). Now the problem is...the game has to toggle this, and do it in a 30 fps environment. If I just tap the arrow, the data is sent, and the remote paddle moves..but by the time the next data is recieved, its been 2 frames instead of the 1 frame on the sending comp, so now the recieving comp is out of sync with the sending one(heh that was a poorly written sentence). Is there any method I could use to make sure that the data is synced between client and server, yet speed is preserved? Or should I just force processing(its not much processing anyways) onto the server and send messages every second or so with updates?

the only way i could think of is to move all your calculations server side then have the server send it to both users. This should (unless one is lagged) keep both clients and the server perfectly in sync.

Yes,

You can''t process anything on the local machine. When you press a button all you can do is send a signal, you cannot have the local machine "think" for itself. Everything has to be done on the server and sent out to clients at the same time or you''ll always have the delay of sending the signal through the server and over to the other client.

Yeah,

Once you start having the client think for itself you then run into games like half-life and SWAT 3 - speed hacks, autofire, and other.. uhm.. "goodies"

--LordKaT

I dont see how putting too many calculations on network games that YOU write will affect how OTHER programmers design commercial games like half-life that are already release...

CorsairK8

could you repeate that in english next time? thanks.
[edit edit!]

Sorry about that, that came off smartassed and I didnt mean it too

--LordKaT



Edited by - LordKaT on March 9, 2001 7:21:09 PM

You may have bitten off more than you can chew Doing an ip network based pong game is going to be complicated.

Two main methods:
1) One server, two clients (one client could be running in the same process as the sever). Clients send to server, server updates state & sends to clients.

2) Two peers. Each sends updates to each other, both maintain the state.

Probles for pong:
1) with locked framerate: Shitty framerate ~10fps

1) with floating framerate: Player with the server has a serious advantage - he gets the state info in microseconds, not hundreds of milliseconds.

2) with locked framerate: Shitty framerate ~10fps

2) with floating framerate: Need prediction, interpolation, & timesync code. That works extremely well. That ball can hual ass - you can't be lagging 200ms from where the ball 'really' is. The client will have to determine its own hits.

Ans you'll need to send at least 10updates/second.

Magmai Kai Holmlor
- The disgruntled & disillusioned


Edited by - Magmai Kai Holmlor on March 11, 2001 1:48:22 AM