Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Suggests for a 2d networked game  (Read 1900 times)
0 Members and 1 Guest are viewing this topic.
Offline Alien94

Senior Newbie





« Posted 2013-04-22 18:25:17 »

Hi,
i'm doing a bomberman game.
I have already did a peer to peer version for 2 players.
Now i want to do an up-to 2 players version using a client server architecture.
What do you suggest me to use?
TCP or UDP?

Thank you
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #1 - Posted 2013-04-22 18:29:42 »

TCP for important data, UDP for not important data
Offline Alien94

Senior Newbie





« Reply #2 - Posted 2013-04-22 18:35:42 »

So i should create a multicast socket for non important data and a thread with a tcp socket for every client?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #3 - Posted 2013-04-22 19:06:14 »

It all depends, i think bomberman wont use that many data, so i guess you could send everything over tcp.
just try both and see what works out.
Offline Alien94

Senior Newbie





« Reply #4 - Posted 2013-04-22 19:13:39 »

It all depends, i think bomberman wont use that many data, so i guess you could send everything over tcp.
just try both and see what works out.

Ok, so i need a thread for each client, right??
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #5 - Posted 2013-04-22 19:24:22 »

yes always at least one, otherwise the neworking would not work right?
you need 1 listener thread to bind client requests.
And then give each client its own communication thread.
Offline Alien94

Senior Newbie





« Reply #6 - Posted 2013-04-22 19:31:54 »

yes always at least one, otherwise the neworking would not work right?
you need 1 listener thread to bind client requests.
And then give each client its own communication thread.
Thank you, i will try
Offline Alien94

Senior Newbie





« Reply #7 - Posted 2013-04-22 19:34:39 »

And another question, i have positions to update, how can i pack my datas for sending??
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #8 - Posted 2013-04-22 20:20:51 »

Simplest way is sending the position and direction 0.5 to 2 times a second (try out what looks / works best).
for example: x, y, facing, iswalking
facing would be the direction the player is looking,

Both the server and client should be receiving this data about all players.

So in your client, you need to animate the player between the frames (10 steps between old / new frame for example), otherwise it will just telport to the new positions.
With frames i ment the dataframe you received about the player.
Offline HeroesGraveDev

JGO Kernel


Medals: 258
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #9 - Posted 2013-04-22 21:05:53 »

TCP for important data, UDP for not important data

Using TCP and UDP increases UDP packet loss.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #10 - Posted 2013-04-22 23:21:33 »

Not to mention if you use NIO, you don't need multiple threads, you can have all of it in one thread... nice and scalable!

Offline HeroesGraveDev

JGO Kernel


Medals: 258
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #11 - Posted 2013-04-22 23:23:32 »

Not to mention if you use NIO, you don't need multiple threads, you can have all of it in one thread... nice and scalable!

You mean asynchronous?

I had trouble trying to do that. I couln't work out how to send packets back to the client without the client opening a ServerSocketChannel. If you know a way, please tell me. It's something that's bugged me for a while. If there isn't, tell me too, so I can stop thinking about it.

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #12 - Posted 2013-04-22 23:26:31 »

I had trouble trying to do that. I couln't work out how to send packets back to the client without the client opening a ServerSocketChannel. If you know a way, please tell me. It's something that's bugged me for a while. If there isn't, tell me too, so I can stop thinking about it.

Are we talking UDP here? or TCP?

Offline HeroesGraveDev

JGO Kernel


Medals: 258
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #13 - Posted 2013-04-22 23:28:05 »


Are we talking UDP here? or TCP?

Asynchronous server with TCP.

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #14 - Posted 2013-04-22 23:50:34 »

NIO is my specialty! I built a fun library that is a generic client/server API where you can pick a UDP or TCP backend, and then also pick whether you want it synchronous vs asynchronous (OIO vs NIO)... works pretty nicely. </stroking-ego>

I'll start off explaining some basic concepts with NIO...

  • A Channel is either a connection to a client, or a server socket (see SelectableChannel).
  • A SelectionKey is something assigned to a channel, it has operations it's ready to do, and operations it's interested in doing.
  • A Selector has Channels registered to it, they register saying they are interested in performing some operation with the selector, and this registration process returns a SelectionKey used to tell or query the Selector.


A Selector is to be used in single thread, for the most part you shouldn't do anything with it outside it's thread.
It's thread consists of something like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
      try {
         // Enter the blockable area if the service has been interrupted.
        if (release.enter()) {
            try {
               // Select all ready events...
              selector.select();  
            }
            // If select throws an error (which will happen  its blocking
           // and this service has been requested to pause or stop).
           finally {
               release.exit();  
            }
         }
      } catch (IOException e) {
         // TODO
        e.printStackTrace();
      }

      // Only iterate the events if some were given (uninterrupted).
     Iterator<SelectionKey> keys = selector.selectedKeys().iterator();
     
      // Iterate through each selected key in the set...
     while (keys.hasNext())
      {
         // Grab the next key and remove it from the set.
        SelectionKey key = keys.next();
         keys.remove();
         
         // If the key has been canceled, skip over it.
        if (!key.isValid()) {
            continue;
         }
         
         // The adapter that handles all events.
        Adapter adapter = (Adapter)key.attachment();
         
         // If the key is acceptable assume its attachment is a Server.
        if (key.isAcceptable()) {
            // Accept the connection, then continue processing keys.
           adapter.handleAccept();
         }
         else {
            // If the key is connectable, handle the connection.
           if (key.isConnectable()) {
               adapter.handleConnect();
            }
            // If the key is readable then handle reading, but only if
           // the key is still valid. The previous connect may have
           // canceled the key.
           if (key.isValid() && key.isReadable()) {
               adapter.handleRead();
            }
            // If the key is writable then handle writing, but only
           // if the key is still valid. The previous reading or
           // connecting may have canceled the key.
           if (key.isValid() && key.isWritable()) {
               adapter.handleWrite();
            }
         }
      }


*pauses* Hmmmm, this gets way more complicated and gets me very involved... maybe I should just send you my open source library and you can look through it and take what you want.

Offline HeroesGraveDev

JGO Kernel


Medals: 258
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #15 - Posted 2013-04-23 00:02:18 »

My problem was not NIO. I (mostly) understood that.

My problem was the asynchronous part.

I started typing out a response, but then deleted it all when I worked out the solution and ways to counter all the problems the solution could cause.

Thanks for the response though.

Offline Agro
« Reply #16 - Posted 2013-04-23 04:25:08 »

Eh, I really don't like using Java's NIO. I had a few problems with it, had trouble understanding it and getting it to work. Involving networking, I came from C++ which made a lot more sense to me. I don't know, I think its a matter of preference, but I still have yet to make networking in java 100% work. I think the problem I had a few weeks ago was something to do with packet frequency. I sent a packet maybe 20 times per second, and it blocked out the chat packets, probably did something really bad there. Wink

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #17 - Posted 2013-04-23 16:31:45 »

I sent a packet maybe 20 times per second, and it blocked out the chat packets, probably did something really bad there. Wink

Sounds like you were using TCP+UDP

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #18 - Posted 2013-04-24 08:20:21 »

Ok so some totally terrible advice here, and some stuff that is just plain wrong. Don't take it personally, but i get a feeling there is a lot of regurgitated "i heard that you do it this way".

For any first cut, just use TCP. Only TCP. It does a bunch of hard stuff for you and has been tuned over the years to be pretty darn good. Only consider UDP if TCP is not working out. And then only if you understand the next points and you understand that its TCP that is causing the problems. Since your not networking with someone on the moon or mars, this seems very unlikely.

If you have never heard of flow control, or congestion collapse, then don't use UDP.

If you don't know what the 2 generals problem is then don't use UDP.

There are other things you should know too before you do UDP. But mostly just don't use it. TCP is *not* slower, its the same packets over the same network. In some cases it is still faster for reasons that its statefull and some routers and firewalls cache information about it, and ISPs typically prioritise TCP over UDP.

UDP packets *can* fragment and still incur  reassembly cost on the IP stack anyway.

When you have enough packet loss to make TCP slow, UDP is also slow. You can't change the fact that its still IP packets, and the packets get lost/reordered when you have congestion. TCP at least will deal with it properly (flow control).

TCP is far simpler since its doing everything for you and it just looks like a stream. Simple is good. Anything probably won't work at all.

Network code is most games is total shit. Really. Just look at the forums for the different games about all the network issues.  Right now a lot of games are moving back to TCP from UDP. Perhaps they finally didn't get a game programmer for the network code and got someone who knows what they are talking about.

Your blocking is a thread issue most likely. . There is no way, unless you are on a 9600baud rate modem that 20 packets a second will do anything to a 10Mbit Ethernet connection or even a 14k connection. Doing both TCP and UDP is fine from a technical perspective. But there really is no point. Once congested, both TCP and UDP will be crap. Otherwise they both just work. Right now there are lots of TCP and UDP happening from your computer at the same time.  

Note you can still do Asynchronous IO with just the streams that a TCP socket gives you. For a 2 player game there really is no need for the complications of NIO which is not really intended for such simple cases. Turn based listening could also work. Simple 2 threads with very little interaction could also work well.

I am not saying UDP is wrong. What i am saying is that its mostly used when TCP is better, and when its used its used Wrong. Very wrong. The overuse of UDP is based on the myth that its "faster". This is not the case. If you don't believe me. Test it.

I have no special talents. I am only passionately curious.--Albert Einstein
Online kevglass

JGO Kernel


Medals: 169
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2013-04-24 08:47:12 »

TCP is slower only because it ensures packet ordering - which means if you do get packet loss then you have no chance of getting a later packet since the TCP stack is going to wait for the earlier ones. Nagles sorts out the TCP window/buffering issues.

UDP works better for data where your game/app is capable of carrying on even if it loses some packets. i.e. movement data - if I send positions:

Time = 1 - Position = W
Time = 2 - Position = X
Time = 3 - Position = Y
Time = 4 - Position = Z

And I lose a couple of packets so I receive:

Time = 1 - Position = W
Time = 4 - Position = Z

I can ignore the packet loss since I can get the later packet at time 4 and update to that position. TCP would delay you getting the packet at Time = 4 until it had managed to successfully resend 2 and 3. So *if* this was your networking model UDP would certainly be more tolerant to packet loss and faster than TCP. It's a little more complicated when you want to do it in a real game because you'd like to be able to show smooth movement between point and you might now have the data - delta compression helps a bit here.

That said, knowing that your data channel is reliable lets you do some other optimisations on the client, so in certain cases TCP is way smarter way to go. For instance if you have no direct control over the actors in your game (think RTS with orders rather than shmup with direct control over your space ship) then you use TCP to great effect. Knowing the roughly consistent lag of a player and being able to reliably send an order to a server means you can loose-step things into place. (see HeadQuarter that one of the guys here wrote years ago). I wrote a blog on this ages ago - so long it's dead on my site, but the power of way back gives me:

http://web.archive.org/web/20101228192125/http://www.cokeandcode.com/rtsnetworking

FWIW, I'm not saying "i heard you do it that way" - I've implemented systems using UDP, TCP and a combination of both for games and applications. Live video codecs is a great example for instance where old data isn't very relevant once you've got a new key frame.

HTH

Cheers,

Kev
 

Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2013-04-24 09:10:09 »

Turns out doing UDP right is bastard hard. I recommend TCP.

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #21 - Posted 2013-04-24 09:12:38 »

Kev, i was trying to not confuse those new to networking. Your protocol is basically the quake3 protocol and is the very rare case of UDP being a good idea. There is flow control and even a solution to the 2 generals problem built in to it.

But i will take issue with the TCP slower comment. The only time you get "reordering" is with packet loss in practice. The internet is not the same place it was in the 90s.  In this case even the quake protocol doesn't work well in practice either (jittery lag). Also since for a lot of games you don't fit the whole state into a packet, you need the missing ones anyway. And now your implementing TCP on top of UDP again. Which a lot of people seem hell bent on doing. And doing badly.

FWIW I have done plenty with both. And even things like IPX stuff. Sure it can all work. But for most TCP "just works" and when it doesn't, the alternatives don't either. And they won't work without a huge amount of effort and experience and testing in REAL WORLD CASES. Not that LAN your working on. 

I have no special talents. I am only passionately curious.--Albert Einstein
Online kevglass

JGO Kernel


Medals: 169
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #22 - Posted 2013-04-24 09:23:46 »

I don't think I said you were trying to confuse people or that UDP was better than TCP - in fact I think I said (maybe I mistyped) that they both have their place.

Calling the quake3 protocol a rare case is a bit odd though - it's a pretty common case for the type of games people want to network here. I've got N entities running round a map and I want them to shoot at each other. Pretty common I'd have thought. Though as I said if your model isn't that then it doesn't fit.

The only bit I took issue to was the "regurgitated "i heard that you do it this way"".

Cheers,

Kev

Offline deathpat
« Reply #23 - Posted 2013-04-24 09:39:41 »

For info in Daedalus, I use TCP only ( via Kryonet ). Clients and server are sending update messages to each over 20 times per second and messages are sent each time an event occurs (bullet is fired, item is picked, player dies, player respawn ... ) ... so at the end it's quite a lot of messages exchanged ( should try to put a counter to get a precise count per second Smiley ) And all of this is running pretty well, even over internet.
Using UDP seemed to be really complicated to handle, and I was afraid to reimplement TCP over UDP at the end ...

So for a bomberman, for sure go with TCP Wink

work in progress : D A E D A L U S
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #24 - Posted 2013-04-24 10:22:57 »

That comment was clearly not directed you Cheesy. And lets face it, a lot of UDP is $THIS or $THAT mostly from circulated internet rumors. When you really measure things, its a different story.

I call the quake protocol rare in that you do need the whole state to fit into a packet. What people often miss with UDP is that you can send packets that are larger than the MTU. The ip stack fragments them and resembles, clearly in order. But will not request a missing fragment, but let the reassembly timeout. That means you need to fit it into 1400 bytes or so in practice (its mostly 1500MTU these days i think). That is not a lot of entities or data really.

Long story short. Everything works when you have a good connection. Mostly nothing works when you don't. And since when things stop working they often stop working in different ways, its hard to have a protocol that will work in that case, let alone all other possible cases.

I have no special talents. I am only passionately curious.--Albert Einstein
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (37 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (61 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!