[font="verdana, geneva, lucida,"]I'm planning on making a fighting game in C++ which multiple people can play over a network. I've never done any programming involving a network, so I have some questions.

1) What protocol should be used? I don't know the differences between TCP and UDP.

2) What changes would I have to make to play this over a LAN network, as opposed to the Internet?

3) How should I make sure that all versions of the game world are synced properly? I'm thinking of initializing one copy per computer, then only sending events like 'move up' or 'attack' between the computers, so not as much data needs to be sent. Is there a better way, or is this good enough?

4) If I do that, how do I make sure that I don't have timing issues? For example, A receives two events from C and D simultaneously, but B receives C's later, which could alter the internal state of the world. Butterfly effect and all that.

5) How should I make sure that random numbers are the same between all computers? Should I just send requests to one computer and have it send out a random number? Seems inefficient...[/font]
[font="verdana, geneva, lucida,"]
[/font]
[font="verdana, geneva, lucida,"]6) I have no clue which 2D graphics library to pick. I've looked at SDL, wxWidgets, Qt, and GTK+, but I don't know enough about any of them to decide. Also, [/font][font="verdana, geneva, lucida,"]I'm assuming I'll need a third party library for sockets and whatnot, so, do any of these handle that too?[/font]

1. TCP is reliable but laggy, UDP is fast but unreliable (that's how Understand it)
2. My little TCP game I just made worked in both. The socket API exposes a common interface.
5. You need send only the seed I should think. When the generator is given a seed it will spit of the same sequence of numbers.
6. For portability yes. I just programmed the windows sockets directly. But I'm crazy like that.

1. http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/

3. You still might encounter lag, but you should test it first. Do what you're planning with it, and come back if that proves ineffective. You may want to check out some network engines and see how they do it.

4. This is one of many issues in the peer to peer networking world... You could set up a small amount of inherent delay (perhaps a few hundredths of a second), as many RTS games do. But obviously that's not very preferable. You could try a system where the host of the game acts as a dedicated server. So all conflicts would be handled there, and whatever one happened first (or whatever one is more likely, but the former is easier to implement) takes precedence. So it all comes down to whoever has a faster connection, thus possibly making it slightly unfair, but it does keep the game synchronized. You could also try some kind of a phase system, where the data is sent in phases (so many packets every second), and just limit the speed to the slowest connection. So if the host, let's say A, is receiving packets from B and C at the same time, but D is slightly slower, you just wait for D's to come, then it calculates everything and distributes the game state back.

Okay, I feel pretty stupid about number 5 now.
So, transmitting game state would be better than trying to preserve it on all the machines? Then the host could use UDP to update the clients?

Alright, so for transmitting game state, UDP is preferable. What about transmitting commands? They still have to get there quickly, but dropping one would be a problem. So that should use TCP, right?

Alright, so for transmitting game state, UDP is preferable. What about transmitting commands? They still have to get there quickly, but dropping one would be a problem. So that should use TCP, right?

Your statement show a lack of understanding of the protocols, and a lack of understanding of several basic concepts of inter-process communication (IPC).


Being in the For Beginners forum, this worries me.

Learn to stand before trying to walk, learn to walk before learning to run.







Based on your statements it seems you don't understand IPC. In that case you should use TCP, or more simple forms of IPC such as a shared file.

Using TCP means you don't have to understand details about what has been sent and what hasn't. You don't need to acknowledge data or deal with lost data, or deal with out-of-order data, or deal with duplicate data. TCP handles all those nasty details for you. And trust me, based on the questions you have been asking you don't have the requisite experience to handle them. You will still need to deal with connectivity issues, ports and NAT and public addresses and private addresses and more, which are probably more than enough of an obstacle at this point.

Using TCP means you write to it as a stream, the same as a file. You read from it as a stream, the same as a file. Sometimes there will be lots of data to read, other times there will be incomplete data to read. Once you've got the connectivity issues addressed, TCP is exactly the same IPC form as a set of shared files.

As a wonderful side benefit, you can use a set of shared file to simulate TCP networking. Just run two instances of the game on your computer, and each file is opened once for append by the sender and for read by the receiver. This will make it much easier to track down the nasty networking bugs you are certain to write by allowing you to see exactly what was written across the wire. Networking code is just a form of IPC. Shared files are a much more direct and less buggy form of IPC.

I'd suggest you master the easier forms of shared file communication before entering the more complex world of networked communication.

Alright, so for transmitting game state, UDP is preferable. What about transmitting commands? They still have to get there quickly, but dropping one would be a problem. So that should use TCP, right?

No, TCP will still ruin the UDP part if you mix them.
Instead, you can make UDP reliable, I suggest you to read this series of articles
http://www.gafferongames.com/networking-for-game-programmers/

[quote name='Henry S' timestamp='1308675820' post='4826058']
Alright, so for transmitting game state, UDP is preferable. What about transmitting commands? They still have to get there quickly, but dropping one would be a problem. So that should use TCP, right?

Your statement show a lack of understanding of the protocols, and a lack of understanding of several basic concepts of inter-process communication (IPC).


Being in the For Beginners forum, this worries me.

Learn to stand before trying to walk, learn to walk before learning to run.







Based on your statements it seems you don't understand IPC. In that case you should use TCP, or more simple forms of IPC such as a shared file.

Using TCP means you don't have to understand details about what has been sent and what hasn't. You don't need to acknowledge data or deal with lost data, or deal with out-of-order data, or deal with duplicate data. TCP handles all those nasty details for you. And trust me, based on the questions you have been asking you don't have the requisite experience to handle them. You will still need to deal with connectivity issues, ports and NAT and public addresses and private addresses and more, which are probably more than enough of an obstacle at this point.

Using TCP means you write to it as a stream, the same as a file. You read from it as a stream, the same as a file. Sometimes there will be lots of data to read, other times there will be incomplete data to read. Once you've got the connectivity issues addressed, TCP is exactly the same IPC form as a set of shared files.

As a wonderful side benefit, you can use a set of shared file to simulate TCP networking. Just run two instances of the game on your computer, and each file is opened once for append by the sender and for read by the receiver. This will make it much easier to track down the nasty networking bugs you are certain to write by allowing you to see exactly what was written across the wire. Networking code is just a form of IPC. Shared files are a much more direct and less buggy form of IPC.

I'd suggest you master the easier forms of shared file communication before entering the more complex world of networked communication.
[/quote]

I don't know the intricate details of how each protocol works, but I do know their differences now. And why would this worry you that it's in the beginners forum? Isn't that where it's supposed to be?

And to wolfscaptain: the two aren't being mixed into the same stream, one is going to the host, the other from it. Would that still mess it up?
EDIT: Never mind, that article you linked was really helpful. UDP it is.