Haha i just pictured where i would be without these forums, i'd prob still be figuring out how to make something move graphically lol. This is made in Java BTW. Ok so down to business, ive implemented the multiplayer network side into my game, and after much frustration i've learn DO NOT USE ObjectOutput and Input Streams in ur game, haha just a massive pain. So then i thought ok ill just use DataInputStream and DataOutputStream, but while i was reading up i found out about UDP, Datagrams and DataPackets. Now im in a delima: From your experiences: A: Should i use the streams and sockets. or B: Should i use a stream to send the the server, a datagram to send the the multicast address and then a datagram on the client side to listen on the multicast address? (Is this how it works?) My game is a 2D Shooter with max 16 players (Top down view) Thanks in advance, Nick

Hello Nick,

I've never touched Java in my life, but I can speak from my C++ and C# experiance in theoretical terms.

When you speak of "streams and sockets" as opposed to UDP, I assume you are refering to TCP connections.

With the TCP connection you get the reliability of knowing your data will be sent, and sent in the right order. If you want to send objects, you can convert them down to their byte or char form (Not sure what Java uses) and send them out that way. When you get the information on the other side, you just type cast it back to the object type. TCP streams are pretty nice for that. However, they are a little slower due to checking every packet.

UDP becomes a little problematic, because you're goign to have to impliment code to make sure that the important packets are received (like dieing) and you'll have to check the states across all the clients to make sure everyone is staying in sync. The multicast is used to lower your programs time spent on processing IO. Your users can join your group and then when you send a packet to the group, routers along the way will duplicate the packet for you. This replaces having to loop through your client list and send the packet to each. This sounds great, but often you don't want to send packets to everyone, it depends on your game. But either way, it's still UDP and you'll have to do all those UDP-esk error checking, because you never know if it'll actually make it to the target or not.

For your game, with only 16 players top down. I can't see there being TOO much information to sent. Sticking with TCP is probably quite acceptable and isn't going to get bogged down.