C-man wrote:
Basically I want to create a battleship game that can be played by having
two clients connect to it. I was wonder what the best networking principal
would be. Basically I suppose I would have to pass an int value or something
representing the x,y coordinates of each shot. Should I use some type of
Socket programming or RMI or what else should be used|?
Thanks
It depends if you want to learn or if you want it to be easy to work.
You could use RMI but if you've never done sockets, why not do that?
MulticastSocket s is data that is sent to a particular adress but is
"broadcaste d" to all the nodes on a network. But be carefull its not
routeable (meaning that routers won't foward it onto the other network,
unless they have a wierd configuration thing). So if its just meant to
talk within a school lab, then you can use those. They are pertty easy.
You can use either UDP or TCP programming. UDP doesn't guarantee that
the client will get the data. Its like an answering machine. You say
"Send it to there", but there is no 'connection' per se. Its a lot
faster, but your data might not get there. UDP packets are called
DataGrams and there is stuff in java to do them. DatagramPacket for
example.
That leaves TCP programming. This is what you use when you use a web
browser. The web browser connects and you get all of the data. Its
slower but you are guaranteed that the data packets will get to you in
order.
To do that you should check out ServerSocket and ClientSocket. This is
usually how the application loads up. Remember this means that you have
to make your own protocol between the clients (IE: first byte is the
version of your software, then what type of packet it is (data like your
oponent shot x y, or the type of ship is stored where etc...)). This is
a lot of fun, do it on paper on in word and print it out, it will help
you during programming.
I don't know if it would help you but check out andre.bonin.ca under
projects, there is a report with the "Marathon" project. It was a
netmeeting-like (voice over ip) application and there is a big
description on the protocol and why stuff was used).
Usually when your application loads up, it starts listeningon a port
(lets say 5670 or whatever). When your game tries to connect to the
remote player, it instantiates a ClientSocket to the IP address of the
remote system on port 5670. When properly connected, you can send the
data like the data like the person's nick name and his boats and stuff.
The remote computer should dry then to conect on your local port 5670
to do the same.
Instead of doing a protocol you can also use serialized objects. A
friend of mine did that and he says it worked quite well. The
Serializeable interface is what you want here. It takes a class and
makes a "string" out of it that you can pass down the pipe. You can
then unserialize it at the other end and use it as an instance of an
object. Pretty cool, and that would elliminate you haveing to write
much of your protocol.
Anyway just my thoughts, the net a is pretty good resource for most of
this stuff if you want to learn more.
