Pages: [1] 2
  Print  
Author Topic: Multiplayer Roguelike: UDP or TCP  (Read 3622 times)
Smok
Defender
*****
Posts: 64


View Profile
« on: September 29, 2010, 10:06:58 PM »

Hello.

I've been checking progress of libtcod now and then, and since I have some spare time (finally got to 4-th year of studies) I'm looking forward to write my RL in next few months.
I've decided to go realtime multiplayer some time ago, and since I know only the TCP-way of talking through the net I ask you, fellow coders:

Is it really such great thing to use UDP in games, why, and does this rule apply to roguelike gerne?
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #1 on: September 29, 2010, 10:38:06 PM »

I'd recommend TCP.  The slight amount of overhead is worth it, to ensure your packets are delivered on time.  UDP seems like overkill, assuming you design your project right from the start, and don't try and send unnecessary data over the network.  That's my two cents, anyway.
Logged
Warmist
Guardian
**
Posts: 110



View Profile
« Reply #2 on: September 29, 2010, 10:50:41 PM »

It depends on a lot of things. E.g for real-time roguelike TCP could be too slow (not sure if it was design flaws on protocol in my case). Also they are totally different in implementation. TCP offers ways of seeing if connection is still on, connecting, disconnecting and so on... As for UDP is pure "send data to" design.

Also i wanted to ask you, what will you be using for TCP/UDP?
Logged
jice
Administrator
Master
*****
Posts: 1456


View Profile WWW
« Reply #3 on: September 30, 2010, 09:59:38 AM »

Except if you're very experimented in network programming, use some game network dedicated library like torque network library. Else you'll enter a world of pain, network timeouts and constant loss of connection...
Logged
Smok
Defender
*****
Posts: 64


View Profile
« Reply #4 on: September 30, 2010, 02:22:50 PM »

Im planning to write entire game (both server and client) in C#, so I'll be using System.Net.Sockets bundled with .NET.
I've managed to sucessfully write MUD game using TCP/IP so I have a little experience with it, and I don't know what are advantages of UDP over TCP.

I have read that UDP is usually used to send entire game state to the client. But when I think about sending whole game state - only thing that comes to my mind is - send the whole screen to client.
Simple calculations make things clear - this is not the way to do it:
1 char per tile and two colours (background and foreground) - 7 bytes per tile. Having gamescreen like 80x40 its 22400 bytes = 21,875 KB.
If I would refresh screen only once per second it's still way too much.

Obvious solution is sending only the things that can change (monsters and items), and that is not necessairly the best way - almost amount of data, X,Y,CHAR,R,G,B = 6 bytes.
When entering shop that is full of items, or big town - player gets the same amount of data.

Okay, we don't send things that aren't in FOV: depending on radius its more or less acceptable: R=10, we get around 314 tiles. Each tile is minimum 7 bytes, since we have both BG and FG colors + character byte and that's 2198 bytes max.

From what I understand - sending this constantly is a must in UDP, since you are not sure if datagram reached it's destination.

From my understanding what is written in Wikipedia (http://en.wikipedia.org/wiki/Transmission_Control_Protocol):
UDP adds 32 bytes overhead per packet.
TCP adds 128 bytes overhead (minimum) per packed, and it has 3-way handshake, so it is actually 384 bytes per packet (or did i messed sth up?)

Even if it is 384 bytes. Sending packet with 384 bytes overhead each time when something moves is better than constant sending 2KB+.

Am I right?
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #5 on: September 30, 2010, 04:25:54 PM »

I don't think you need to send the entire screen.  I'm definitely no networking expert, but it seems unnecessary to me.  You can calculate the screen on the user's end.  Things that you definitely need to send for updates:

Player movement
RNG Seed for monster AI, then calculate their movement on player's end
Effects of combat, what exactly happens (damage, durability loss of equipment, item drops, etc.)

And probably some more stuff.  The real challenge will be to prevent cheating, but that's always a risk in any multiplayer game.
Logged
Smok
Defender
*****
Posts: 64


View Profile
« Reply #6 on: September 30, 2010, 08:07:51 PM »

I'm not putting anything valuable on client's side. Everything must be calculated server-side, monsters move also.

Client will be only issuing orders: Go left, go right, attack him, send me my inventory, use item, weild that, wear this, open chest, take this quest.

Logged
george
Master
****
Posts: 216


View Profile
« Reply #7 on: October 01, 2010, 01:55:34 AM »

Back to your earlier point -- just send the information that changes. You don't need to send all the map (or even map in fov) every frame, unless it all changes, right?
Logged
Smok
Defender
*****
Posts: 64


View Profile
« Reply #8 on: October 01, 2010, 06:23:25 AM »

When using UDP - you can't be sure that packet containing changes will reach destination unless you implement some special error checking method.
That's why you are supposed to send view constantly instead of submiting changes.
Logged
george
Master
****
Posts: 216


View Profile
« Reply #9 on: October 01, 2010, 03:54:46 PM »

What you do is calculate map changes on the client side, and then correct with the server-side update if you drop a packet. You see this fairly often in online games where models will seem to 'jump' if you get a little lag or something on your connection. The client was calculating their motion for example but then you got the next packet from the server and your client corrects.
Logged
Smok
Defender
*****
Posts: 64


View Profile
« Reply #10 on: October 01, 2010, 08:23:45 PM »

Yes, but according to your previous post: imagine following situation

Spot X is 1 tile North from our character.
Spot Y is 1 tile North, and 1 tile West from our character.

Monster moves from spot X to Y - this packet doesn't reach destination
Nothing happens, so we don't get any new information.
View isn't constantly updated, so client thinks that monster is still on tile X.
Player casts firebolt spell, choose direction - he chooses North.

Bolt misses the monster, and player doesn't know why.
Logged
Warmist
Guardian
**
Posts: 110



View Profile
« Reply #11 on: October 01, 2010, 09:53:54 PM »

If i were to do new online roguelike (or anything) i would use TCP (saves all the managing lost packets, etc) but if a lot of data needs to go, i would do it so:
  • Send map (all of it, or part thats important)
  • Send changes as they happen
This is how WOW works, and minecraft (in a sense) and i think lots of other games. If map never changes -> pack it to the release.
Logged
george
Master
****
Posts: 216


View Profile
« Reply #12 on: October 02, 2010, 05:42:16 PM »

Yes, but according to your previous post: imagine following situation

Spot X is 1 tile North from our character.
Spot Y is 1 tile North, and 1 tile West from our character.

Monster moves from spot X to Y - this packet doesn't reach destination
Nothing happens, so we don't get any new information.

But how is that different from dropping a packet when you're sending the entire view? You'd get the same result, no?
Logged
Smok
Defender
*****
Posts: 64


View Profile
« Reply #13 on: October 02, 2010, 05:43:40 PM »

Yes, but since im sending it every second - player will eventually get the actual view.
Logged
george
Master
****
Posts: 216


View Profile
« Reply #14 on: October 02, 2010, 07:12:15 PM »

Ah I see -- you don't send every second with TCP? My only experience with TCP is with muds, and I thought you basically send every frame/tick anyway (however the mud server defines its tick).
Logged
Pages: [1] 2
  Print  
 
Jump to: