Implementing online play to a game

[Vot1_Bear]

Hello again everybody!

As the title might imply, currently I'm thinking of implementing networking to my game Blastorium. However, having zero experience with networking, I need to ask a question or two...

(For those who are not familiar with the game I'm developing, It's a bomberman-esque game (meaning it's real-time). I figured this info would be necessary)

• At a target of 30FPS, How much and what kind of data can/should I send?
  Should have both player calculate the logics themselves and only send the commands used by another player (Risk of missing some packets and making both players lose sync)?
  Should I instead just send the important informations (Player position, HP, and weapon usage) and let each machine handle commands themselves?
  Both of the above?
  Or should I have one server who receives commands of client players, calculates logic and sends the important information (Position, HP, etc) in return?
  
  I still have zero idea on how much I can send/receive with a reasonable enough connection, so please help
  
  
• Which socket type?
  Reading the tutorial UDP seems to be a good idea here (speed), but any expert insight on this?
  
  
• How do I connect two separate players through the net?
  Do I have them each send their IP adresses to each other prior to play? Or host an online server which catalogues online IPs and matches up players with each other? If the latter is possible, how (What kind of online server do I need to use, etc)?
  
  

And as a disclaimer, I suck at am still learning C++, using competitive programming as a base. I understand the basics and algorithms like dijkstra or segment tree or something but still have zero idea on class inheritances and stuff. Thus, I'd like to apologize beforehand if some of these questions have trivial answers or you have troubles explaining something to me... But I'll do my best to learn.

Thanks in advance!

(I'm still unsure whether this belongs in general or networking subforum. I'm asking about implementing networking, but I feel like some of the questions refer more to general topics instead of the actual networking module)

[Geheim]

Try to send as little as possible!, all calculations should make the players themselves.
As you said, players should just send the commands like "moved-right", "layed a bomb".

Socket type: definitely TCP, if you have a connection, all packets you send will be received on the other side with the correct order.

Make a simple server which handles all the connections and which sends the informations from one client to all the others.

To sync smooth things like the position you could send the position if you press the key and once again if you release the key, the other clients then set the position and it will be synced (Don't send the position every frame!)

With this you should easily get 60+ frames

[Ixrec]

These links explain all:

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/
http://gafferongames.com/game-physics/
http://gafferongames.com/networking-for-game-programmers/

But I can give really quick answers to the explicit questions you asked.  I'll basically be summarizing some of the stuff those articles say.

1) Depends on the genre, but in most action-like games, you can just send player input, which is an absolutely tiny amount of data.  Though sending position/HP/etc wouldn't be a big jump either way.  How much data you send really doesn't matter that much unless the quantities are enormous; what really matters is the network latency, which you have no direct control over.  If latency were 0, you could easily have infinite frames.  It latency were abysmal, 30 fps would be impossible no matter what you do to the code.

2) Yes, it kinda has to be UDP.  The problem with TCP is that if a packet gets lost, it will take as long as necessary to successfully resend it.  In a multiplayer game, if a packet gets lost, then it's already worthless.  Newer input always trumps older input.  Thus TCP actively works against you.

3) The two things you mentioned are essentially the two ways you go about doing it.  Somewhere, you have to deal with literal IP addresses.  Either two friends use each other's IPs, or you give the client the IP of a server on which you have a Blastorium server program running 24/7.  The server itself is just an ordinary computer that you run the server program on, which constantly listens for connections from players' clients.  Of course, writing a proper server program that does matchmaking (which is what I think you described) is a lot of work, and even professional developers often can't get it to work well.

[Geheim]

2) Yes, it kinda has to be UDP.  The problem with TCP is that if a packet gets lost, it will take as long as necessary to successfully resend it.  In a multiplayer game, if a packet gets lost, then it's already worthless.  Newer input always trumps older input.  Thus TCP actively works against you.

This happens if you send too much data, but in this "simple" game TCP is totally fine.

The best will be both: UDP and TCP, tcp for important things like a message, a name, important commands...
and udp then for the position and all smooth stuff (where the specific order has no matter, just the speed).

However it is easier to deal with tcp, thats the reason I suggest making it tcp only, because it is good enough for what you are trying to do.

[Vot1_Bear]

These links explain all:

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/
http://gafferongames.com/game-physics/
http://gafferongames.com/networking-for-game-programmers/

The articles are awesome, thanks!

1) Depends on the genre, but in most action-like games, you can just send player input, which is an absolutely tiny amount of data.  Though sending position/HP/etc wouldn't be a big jump either way.  How much data you send really doesn't matter that much unless the quantities are enormous; what really matters is the network latency, which you have no direct control over.  If latency were 0, you could easily have infinite frames.  It latency were abysmal, 30 fps would be impossible no matter what you do to the code.

2) Yes, it kinda has to be UDP.  The problem with TCP is that if a packet gets lost, it will take as long as necessary to successfully resend it.  In a multiplayer game, if a packet gets lost, then it's already worthless.  Newer input always trumps older input.  Thus TCP actively works against you.

The best will be both: UDP and TCP, tcp for important things like a message, a name, important commands...
and udp then for the position and all smooth stuff (where the specific order has no matter, just the speed).

However it is easier to deal with tcp, thats the reason I suggest making it tcp only, because it is good enough for what you are trying to do.

Since I believe the quantity is still small, I guess I'm going to try TCP first then (Though since this is a practice project I would try UDP too later on). But by "This happens if you send too much data, but in this "simple" game TCP is totally fine.", does this mean TCP data losses only happen if the data sent is enormous, or are you saying that minor data losses are negligible?

One more concern: What if I'm trying to connect more than 2 players?
TCP is said to be one-on-one, so does that mean I have to create a TCP connection connecting each pair of players (3 connections for 3 players, 6 connections for 4 players, etc), and if yes, how feasible is it? What about UDP, and how do they compare?

I guess I should try implementing 2-player feature first before adding anymore players, but I believe this should come to consideration.

Thanks for the answers!

[Ixrec]

What I meant was that if the data is small, you can send it more or less constantly.  Those articles describe this in more detail.  I was specifically referring to his point that RTS games are stuck with P2P lockstep because the state information of thousands of RTS units is far to much to send 60+ times a second.  Your game does not appear to have that many things going on at once.

As far as I know there's no reason you can't make a TCP connection for every pair of peers, but it seems like it'd be a lot easier to organize everything with one central server, even if there's no theoretical performance issue.  If nothing else you'd have exponentially more packets flying around with pure P2P rather than a server, and that's probably going to aggravate latency issues.

Also worth mentioning is the possibility of having one of the players let their computer be the server.  I've heard even some XBox Live games do this.  Of course you still need a system for getting his IP to everyone else.