Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Multiplayer games  (Read 3028 times)

0 Members and 1 Guest are viewing this topic.

mimipim

  • Newbie
  • *
  • Posts: 49
    • View Profile
Multiplayer games
« on: April 13, 2011, 01:55:18 pm »
I'm interested in how multiplayer games works.
I'm having plans to make a TD(Tower Defence game) which can play with 4 players.

Can someone explain how exactly system must work so when Plr1 make a movement Player 2 see it too. How controls on players are divided.

I'm thinking about TCP.
Everything about online games will be interesting for me.

JAssange

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Multiplayer games
« Reply #1 on: April 13, 2011, 08:57:08 pm »
You either have a player that hosts or a server, and all client information is sent here from each client and the other clients information is sent to the other other clients from there.

drakelord

  • Newbie
  • *
  • Posts: 22
    • View Profile
Multiplayer games
« Reply #2 on: April 14, 2011, 08:07:20 pm »
To elaborate a bit further on the post above me, there would be two main functions for the internet here.

First, you'd need some sort of lobby/matchmaking system.  You could use the old methods similar to back in the day where one person just "listens" for other users that would connect, and other players obtain their IP address and connect to them.  But in this day and age it doesn't work as well due to firewalls/routers not letting packets in indiscriminately without having to configure port forwarding.  

So an easier method in this case would be to have some kind of centralized server that people connect to for matchmaking purposes.  With this, you can still have a player hosting the game.  The reason it works a little better is that, with the modern firewalls and routers, if you send a UDP packet out to a destination before you receive any packets, it temporarily allows you to receive packets on that same port from your destination.  

So, when you join together in a lobby and start a game, the server would send the host the ip's of the other 3 players, and the ip of the host would go to the players themselves.  The ports would be opened, and data exchange can begin.  


The second main function of the internet is of course sending data throughout the game.  For either of the above, you can use TCP or UDP.  TCP opens up a connection with another computer over a socket.  You can only (for most intensive purposes) only have one computer connected per socket.  The upside is that there is procedures in place for TCP connections to check for lost packets.  The downside is that you use up extra sockets and you have to manage all of those incoming and outgoing connections.  

For UDP, you can have all the players connected to a single port and just broadcast changes out to everyone through that indiscriminately.  The downside is that you have to employ your own method of checking to see if packets were dropped or not.  

Kind of a long bit, but I hope it helps, :3

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Multiplayer games
« Reply #3 on: April 15, 2011, 08:21:34 am »
Quote from: "drakelord"
For UDP, you can have all the players connected to a single port

I guess you meant to a single bound socket, right?

Quote
The downside is that you have to employ your own method of checking to see if packets were dropped or not.  

Which looks like re-implementing TCP. ;) It has been common for many years that games relied on the datagram protocols like UDP, but in my opinion the bytes you save by dropping the TCP overhead is nowadays minimal (compared to available bandwidths).

I'd say start at least with TCP and see if it works well. The big advantage is just that you don't have to care about requesting missing packets or even packet ordering, because your OS' TCP stack handles that. If things go slow, investigate your protocol and optimize it. If there's no room for optimizations, stick to UDP. In most cases, however, TCP does a) a good job and b) isn't as slow as so many people are telling.