Quote:
Well I would use UDP but TCP is better for games, right?

It depends on the game.

Turn based strategy games can get away with it. I've also heard that world of warcraft uses TCP. But in general, action games use UDP.

Often, they build a reliability layer on top of UDP. This is why I suggested researching some high level libraries to handle the networking for you.

TCP tends to have a higher latency than UDP, because it must act like a stream. If you send 10 UDP packets and the middle one is lost, you will receive 9 packets at the end point. If TCP sends 10 segments and the middle one is lost, even if the others arrive they won't be delivered to the application until the lost one is successfully retransmitted.

This leads to artificial latency, which can be made worse if the data doesn't need to be 100% reliable anyway. In a game, the latest packet is usually more important than earlier ones, so it doesn't usually make sense to have these buffered somewhere waiting for an earlier packet to arrive.

The other thing is that TCP tries, as the name suggests, to control congestion in the network. It limits the amount of data it will have on the network. If it detects packet loss it will lower this limit. This can result in data being buffered on the sending machine, waiting for the receiver to signal that they can handle more data or for the network to allow packets through. This can cause further delays, in addition if the local buffer is exceeded your program will block on a send() call.

It might be interesting for you to look at how other games handle networking, for example, Quake 3 or Unreal.

My lag problem seems to be in sending and receiving packets, because client sends all the time packets to server and vice versa.
So what I'm thinking, I should change the client's packet sending code to that it only sends packet when user does something, like moves or shoots. Then the server receives the packet from client and sends it to all the other clients.

ps. thanks for the links, I'm looking in to the Unreal Networking Architecture.

EDIT: I'm trying to get this basic client-to-server, server-to-clients structure working, and implement it to my small tank game. The multiplayer idea was by my friend so I decided to try if I could somehow get it working.
Screenshot: http://www.nukecorruption.com/content/terminus/ter23.png
The actual gameplay is done with bots, so a little over-internet-play would be nice. Though..this far, this haven't been easy hehe.
I need to plan what to send to the server from a client

[Edited by - NukeCorr on April 22, 2009 9:06:38 AM]

How can I check on the client if server is sending a packet, or how can I tell client that server is sending updated game state? So it would not send the packets all the time... or is that even right way to do it?

I don't think that is the right way. What about sending at a fixed rate? Example X times a second, send a gamestate update.

Well it updates the player position now at the same time on the other client's screen, but the player is warping since it's not updated all the time

Have you looked at the Multiplayer and Network Programming Forum FAQ? In particular Q16 and Q27. The links I gave you earlier may contain information about this, too. There is another link for how the game "tribes" (and others) handled networking in the same FAQ under Q12.

The moderator of that forum has an interesting home page that includes (among other things) some networking related articles.

You need to do a good bit of research to get this to work properly.

Interpolator..err what? This goes too complicated for me, I suppose I'll just give up this project

Quote:
Interpolator..err what? This goes too complicated for me...

It sounds harder than it is. The basic idea is very simple.

At time T you get notification from the server of the whereabouts of a particular object. Until the next notification, the client moves the object to where it thinks it will be. This is client side extrapolation.

Sometime later, you get another authoritative update from the server. But its quite different from your guess! Perhaps its another player, and they have changed direction or speed since the last update.

If you just directly set the position of the object to what the server tells you, you will get "snapping", where the object instantaneously moves in an unrealistic fashion.

Instead, you use interpolation. You remember where you predicted the object would be, and where the server says it is. Then, over a number of frames, you move the object between these two locations.

Most of the time, the client will guess quite accurately about the state of objects, so this won't be too noticeable. But even when you do get some inaccuracy, it doesn't look quite as terrible.

Quote:
I suppose I'll just give up this project

If you give up when things get difficult, you aren't going to be able to make great games. You don't have to give up. If you are finding it difficult, sometimes it might be better to put the project on hold temporarily and come back to it later when you have a deeper understanding.

It sounds like you are adding in the multiplayer because of your friends suggestion. Maybe if you comment out (or use the preprocessor) the networking aspects of your game you can concentrate on the main application for a while.