I previously made an RTS, network playable.It functioned by having the game divided into frames, each frame basically being the game loop.Each player/client had to send a datagram containing movement info for that frame to the server, which was relayed to each client.Is this the reccomended way to do the network aspect... with datagrams?or is there an input / output stream, preferred way?

I think people typically send the moves back and forth with Sockets (by moves I mean the keyboard input), often along with timestamps. But that's mostly what I've observed here, because I've only made a couple networked games and they weren't at all sophisticated.

I'd like to go with TCP, then.Would that mean each player/client has a connection to every other client? relaying out timestamped activity info?Isnt that a serious burden, or will an array of OutputStreams and a separate array of InputStreams be quite managable?

So, would my client constuctor take an array of outputstreams and InputStreams, or IPaddresses? Should I choose any port number for my game?

Would that mean each player/client has a connection to every other client? relaying out timestamped activity info?

No ! That would be a hell to synchronize everything . You should either have a centralized server in a dedicated machine, or have one of the players to host a game (but that would lead to a lot of issues for people behind NAT) . Then all players connect to the server .

In both cases, each player send their actions to the server . The server then validates it and broadcast to other players . In short, that's it .

Maybe you should try and create a simple chat application with the same architecture before moving on to your RTS. You'll learn a lot and anyway you'll probably want to reuse the code for an ingame chat .

In my main( I create two instances of ChatClass,both with localhost addresses...With an ObjectOutputStream on one connecting to an ObjectInputStream on the other?And I have both with chat windows ...TextArea, Textfield?There should be no firewall issues with that? Thanks

I didn't quite understand what you meant, but I think it's not a good idea to implement a "client-server" , if that's what you meant . Some games do it like this, for example Tetrinet . I think it's better if you write just a server, and then both clients connect to it (even if one of the clients is localhost) . this way you can keep things separated and organized, and you dont need to deliver your server to every client .

The server should wait in a thread for incoming connections, with socketServer.accept() , and as soon as a connection is established, put this connection in a list . Each connection instance in the server will have an input and output stream . When a client sends a message (client output stream -> server input stream) , iterate in this list and send the message to all clients (server output stream -> N client input streams) .

I think that should be enough for you to begin with . Afterwards you have to deal with stuff like connection loss, concurrency, etc , but I wouldnt care about that now .

I'd advise you to start with a line based (text based) protocol. You can dump the stream into a file (or to the console) which makes debuging a breeze.

Later, once you are confident that everything works as you like, you can switch to a binary protocol, but often you don't have to. If you think that this makes it too easy for cheaters, well, they don't seem to have much problems figuring out binary protocols, so why bother with security by obscurity. You can make a text based protocol just as safe as a binary one.

ObjectInputStreams / ObjectOutputStreams can be very surprising, if you haven't read the javadoc top to bottom.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

About half way down the technical bit starts. I like lockstep synchronization but I hate the one laggy client lags out everyone. The article talks about loose step approach which doesn't have that problem.

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