Jump to content

  • Log In with Google      Sign In   
  • Create Account

How does networking exacly work?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 savail   Members   -  Reputation: 333

Like
0Likes
Like

Posted 16 August 2012 - 11:58 AM

Hi,
I would like to create a network for my action 2d sidescroller, something similar to Little fighter 2. I have already read some tutorials but I'm actually not sure what connection to choose, UDP or TCP? Maybe it's becosue I also have no idea what should I send from client to server and vice versa. I want to create a lobby and make for players opportunity to team up and fight against each other through network. But how do I display 2 opponents on both different clients? Should I send information from server to client that an opponent needs to be created and create in each client? and would sending keyboard input be enough for action game? Basically what should I send from client to server and the other way round?
I would be very grateful for any help!

Sponsor:

#2 0BZEN   Crossbones+   -  Reputation: 2016

Like
3Likes
Like

Posted 16 August 2012 - 06:28 PM

You can abstract networking. Imagine you have an application split in two or three, each part representing a player's view, and each part can only communicate via sending messages to each other. That's pretty much how networking works, at the game level.

I would like to create a network for my action 2d sidescroller, something similar to Little fighter 2.


FAQ is a good start.

I have already read some tutorials but I'm actually not sure what connection to choose, UDP or TCP? Maybe it's becosue I also have no idea what should I send from client to server and vice versa.


TCP can be conceptually easier to understand. Think first class delivery, but a bit slow to make sure the content is always delivered in good condition. The messages you send will be received in the same order, and the delivery is always ensured.

UDP is more of an unreliable mail service. Sometimes the messages will get lost, sometimes some messages would be delayed and received out of order. It plays fast and loose.

You can also create a in-order, reliable message system on top of UDP (which is pretty much what TCP is).

For action games, sometimes it's not important to always receive a particular message, but speed of transmission is. Think of sending the position of a player at 20 fps. If a couple of frames are lost and not delivered, no worries, a new, more up to date position will be receive later anyway, and the player's position will be restored.

I want to create a lobby and make for players opportunity to team up and fight against each other through network. But how do I display 2 opponents on both different clients? Should I send information from server to client that an opponent needs to be created and create in each client?


Pretty much.

and would sending keyboard input be enough for action game? Basically what should I send from client to server and the other way round?
I would be very grateful for any help!


Usually, no. One problem with games is 'determinism'. Meaning, given an identical starting state, providing the same inputs, will your game always produce the same output? Think of a replay system.

More often than not ,it's not true, if you do not factor in external influences. That usually mean running a 'lock-step' algorithm, than makes sure all the players will share everyone's inputs every tick. It also means, more latency, as everyone has to wait for everyone else to receive the inputs for a particular frame. In short, the latency will be dependent on the player with the most latency / worse connection, which is bad for an action game, but ok for say, a turn-based or even real-time strategy game.

In a broad sense :

in a server / client model, the clients send their inputs to the server, the server computes each players positions, and then broadcasts the player's positions to every players in the game.

In a peer-to-peer model, each client updates its player, and each player sends the local player's position to all the other players in the game.

Google 'source networking', '1,500 archers on a 28.8 modem', 'Gaffer networking physics', and 'Beej socket programming' for basic message communications across networks.

You can use 3rd party library to do the dirty work (enet, raknet). Probably your best option.

Edited by papalazaru, 17 August 2012 - 07:32 AM.

Everything is better with Metal.


#3 philipborg   Members   -  Reputation: 331

Like
-5Likes
Like

Posted 15 September 2012 - 12:17 PM

No offence but to stay away from people defining you as an idiot it is spelled "exactly". Probably an typo but there are some people who don't think before defining people.

#4 hplus0603   Moderators   -  Reputation: 5297

Like
5Likes
Like

Posted 16 September 2012 - 11:51 AM

No offence but to stay away from people defining you as an idiot it is spelled "exactly". Probably an typo but there are some people who don't think before defining people.


No offense meant, but if you're going to call out people on writing, you probably should spell "offense"(*) and "a typo" correctly, and you probably should also use proper grammar and word choice. "No offense" should write out the implied "meant," "stay away from" should be something like "avoid" or "preclude," and "defining" should be something like "judging."

(*) There are parts of the world where "offence" is an accepted spelling, too, but that's not where Gamedev.net servers are :-)

enum Bool { True, False, FileNotFound };

#5 zfvesoljc   Members   -  Reputation: 440

Like
0Likes
Like

Posted 17 September 2012 - 07:35 AM

We used enet library, as suggested above. We ended up using reliable messages and "spam" messages. Reliable was used for "important" notifications, while spam was used for player/ai position, animation states, etc... All "important" game logic was done on server side (ai spawning, pickups, damage logic, score, health, etc...), with clients making requests from server (can I pickup this, can I use this, ...). We used the classic server/client approach, where even local player(s) was a client on the server.

#6 Xanather   Members   -  Reputation: 708

Like
0Likes
Like

Posted 18 September 2012 - 07:16 PM

Hi,
I would like to create a network for my action 2d sidescroller, something similar to Little fighter 2. I have already read some tutorials but I'm actually not sure what connection to choose, UDP or TCP? Maybe it's becosue I also have no idea what should I send from client to server and vice versa. I want to create a lobby and make for players opportunity to team up and fight against each other through network. But how do I display 2 opponents on both different clients? Should I send information from server to client that an opponent needs to be created and create in each client? and would sending keyboard input be enough for action game? Basically what should I send from client to server and the other way round?
I would be very grateful for any help!


When I developed my game just to test out and learn .net networking I tried to send messages only when actually needed. Some of the messages were

"player X started moving left/right" - this message was sent to all clients including the client that wanted to move in the first place, this resulted a server-based solution. The message contained the player ID that started moving, the direction in which he was moving (left/right) and the actual location where he started moving from. The received position allows all clients to sync together. After the message was processed every client just simulated the moving player (this includes increasing the velocity over time, etc...), the player would only stop moving after the "stop moving this player" message had been received.

"stop moving this player" - this message basically told all clients to start reducing the velocity of a connected ID from a specified position (so like the "player X started moving left/right" but in reverse).

Of course though I had to use TCP to do all this (because ALL messages were important as you can tell) but the bandwidth consumption was EXTREMELY small.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS