I think your on the right track using method #2. For instance using spatial sorting you can ignore the inputs of players outside your view, and as i mentioned previously you can compress down all input command packets into about 2 bytes. So even if all say 10 players pressed fire at that tick and were in your view, it would be about 20 bytes. Using tcp-ip will simplify your network architecture however it will suffer badly if your connection is noisy, and droping packets. Since this is a starter project i dont suggest tackling the complexity of a purely UDP based protocol yet.

-ddn

Hi ddn or BlackSideSnap,
thanks so far !

So I will try to realize way #2! So I only send the player input to the server. The server will validate the input of all players and send it back to them. How often shall I validate the player input? 2 times a second ? I only know that the server has to update all players at the same time, to make them stay in sync.

I suggest validating the inputs at 10 update per second. Yes, you''ll have to send the input changes (no need to send redundant inputs) to all the players if you want to keep them in sync. Unless your using the spatial filter I talked about previously. In that case you''ll need a special state packet which initializes a players position when they enter the screen area of the current players viewable area. In that case you only need to send the player inputs of current visible players but there is no need to add this complexity if the number of players are low (about 1 - 20).

Note when you validate and proprogate the users input, is when you apply it server side. That is postpone processing of the user input you recive out of sync to the 10 ups. The reason for this is becuase your not sending absolute states of the entities but the relaitve state changes, which is quite time dependent. The small error of applying the input at time of arrival and the proprogation of input to the clients will eventually acculmulate and the clients will diverge from the server drasticlly.

So basiclly dont forget to send the timming tick every tick, this frames the user inputs packets and guarrenttes they are executed at the proper time and durration. (with TCP IP)

If your up to it, there is a simple extension using a UDP only protocol is possible, with the exact same network architecture.

Bascilly to compenesate for packet drop, you have to add a absolute state packet, which is sent peroidiclly. So lets say at 1 ups a absolute players state packet is sent to the client. Each player is on its own timmer so the packets are spread out over time so they dont flood the line. A absolute state packets contains the players postion, direction, and speed if you use speed.

Also the client side timming algorithim needs to be flexible enough to compensate for loss of a timming packet. So given that you know the rate of update on the server side you should be able to predict the next tick packet, whether it arrives or not.

The framming of the player inputs isnt so important as the absolute state packets will synchronize the player state every 1 sec.

I look forward to seeing your game.

Good Luck

-ddn

Mhmm
I wanted to make it easy for the beginning. Just wanted to send the input updates and the time passed since last update. The only problem I had was the time between one update and the next. When a frame takes for example 15-30 ticks and I only get a validated update all 100 ticks. Shall I then create 5 identical frames?

Aaaaaahhhhhhh
so you mean sending a small packet with 1 or 2 bytes for example, containing the time passed since last tick packet. And when e.g 100 ticks happended since last input update, I send a new input update. Ey Cool! Thats great!
So the clients can draw/calc new frames every time a new timing packet arrives.

Thank you Thank you Thank you!

You should really write a tutorial, covering all the stuff you wrote above!!

Hey GameDev.net- staff get this guy, and make him write tutorials.