Two communication channels?

Networking & Multiplayer
#1

Hi!

I would be glad to have some feedback on my idea. I’m currently in the middle of implementing networking in my first networked Java game (http://sourceforge.net/projects/motopain).
I have implemented two communication channels, one reliable (TCP) and one unreliable (UDP). UDP are used for position updates and TCP are used for messages such as collisions, inhabitants removed or added in the game world and other stuff that affects the game state more severely.
I’m pretty confident that I’m not the first to have these thoughts, so if any of you have tried something similar I would appreciate if you would share some of your experiences.
My main concern if is there is a cost involved with having a connection open (I set keepAlive to “true”) to the server?

Regards Anders

#2

That’s actually pretty typical I believe. It’s the way I do all my game development. JGN has built-in functionality to provide dual connections per client to the server (or P2P) and the system manages what stream should be utilized. I think the only place you’ll really run into performance ramifications is if you are not using the NIO functionality in Java.

There are people here much more knowledgable than myself in here, so I’ll wait to see if I’m corrected. :wink:

#3

from experience, collision on the client side is just a bad bad idea that going to bite you…What if client1 says he shot client2, but client2 says that client1 didn’t? What are you going to do then ?

Just do collisions server side…

#4

optimistic checking? (as stolen from optimistic locking.) only wenn clients disagree should the server check whois right? kinda offtopic.

#5

“only when they disagree”…thats sorta like 99% of the time in fast action paced games…

#6

Yes…
The problem is that I do not have a server who holds a state, the server only keeps track of participants in the game and relays messages.
My idea of collison detection is to let the client who has the object (car) locally decide if there is a collison or not.
Somehow I will try to make it beleivable in the gameplay, one idea I have is to make the bounding shape used for collision detection somewhat smaller than the sprite, thus a “near hit” will be more beleivable as a hit for the part who did not perceive a collision.
This approach means that each client is authorative over its local objects and acts a server for them, whereas it will not perform collison detection for objects residing on other nodes.

#7

Sure, go ahead - Write the game, get it working play with it - but know that you WILL have to THROW AWAY the code if the game ever gets popular OR you ever want to re-use the code for a future game.

Most people here like to re-use their code from half-made project to project, hence they worry about making something first time that is actually usable. If you’re that kind of person, never ever ever think you can get away with “the client being a sort of server” - it will never work (modulo you can actually make it work, but in ways that are so much hassle and pain you honestly don’t want to even think about going there).

#8

Unfortunately I’m going to have to agree with blahx3h moderately. One thing that you can do is “elect” a client to be authoritative (which I believe is how most P2P games work) but that’s messy and problematic if the person you elect decides they want to cheat. A server is always the best way to go if you can get away with it. Even if you make the server just another client that can throw red flags if there’s ever a dispute someone has to be able to overrule.

#9

Hmmmm interesting.
I don’t mind pain generally but when implementing… Naaaa…
Can you give an example of the “hassle and pain” with this approach? Not because I don’t beleive you but of interest.
And thanks for the feedback, I will probably reconsider my network design.

#10

Now I’ve refactored the game into a pure server-client architecture.
And I must say it has really made development a lot easier and the code tidier.
So I must give you guys (or gals) cred for pointing this out to me.