Java game networking question, please help
Ok, so im not to java and new to these boards and have a question about a game im working on. My game im working on is basically an overhead view of tanks, right now its pretty basic and I just have some blocks that shoot some projectiles but its set up to accept alot more. I know its going to be networked so i figure it will probly be best to do it now while its a smaller program. Im working out of Deitel and Deitels 5th edition of Java: how to program. Its a really good book and im using the TicTacToe multi threaded server that has 2 client applets connect to it source code. I experimented with basic server client stuff and have gotten stuff connected over the internet or anything but ive read all i can find and when i went to impliment my game as a server that has two applets connect and i found that I had no idea at all how to implement this. How I have it now I have a Tank1(player1) and Tank2(player2) classes that extend from a main Tank class, I also have a projectile class and put it all together in the main. I have no idea what the Server side should be doing and keeping track of, and I have no idea what the client should be doing and there relationship together. Can anyone help me out with setting up a server/client for this game, I know I haven't given alot of usefully information and its being long winded but ANY help would be VERY apreciated. Thanks alot! And if it would help at all I can get my source code up, or the applet of what I have. Thanks again
[1497 byte] By [
MoO_coWa] at [2007-9-28 14:07:59]
>I have no idea
> what the Server side should be doing and keeping track
> of, and I have no idea what the client should be doing
> and there relationship together.
This is a pretty broad topic with lots of details,
and it sounds like you could use a broad mental model
to get you started. Here's one that has served me well:
1) Think of the game as running only on the server.
2) Think of a client as a dumb terminal that simply
relay a player's input to the server, and display
the game server's responses back to the player.
3) If you want the game to run without a separate
server, then keep this mental model but have the
server run on one of the computers that also has a
client on it (i.e. don't to combine the client and
server -- keep them logically separated even if
they're physically on the same computer).
If you have performance/latency problems, then later
you can move functionality down from the server to the
clients. However, don't do that yet. It's easy to do
that later if you need it, but it's very difficult to
go in the reverse direction if you discover that you
put too much stuff in the client. Believe me, I've
seen huge online game projects derailed because they
thought it'd be easy to hoist functionality out of the
client into the server.
About the network communications itself... I assume
you're familiar with the ISO/OSI network model and the
TCP/IP version of it. Use something similar for your
communications, i.e. the server and client should talk
to each other with a game-level protocol, and all the
networking details can be hidden in the lower
transport layer.
Another thing: your game protocol should be versioned.
You'll revise it several times during development, and
it's better if the code is self-aware about the versions
rather than you trying to keep it straight. You'll end up
with old clients connecting to the new server or vice
versa, and if you don't know the version of the incoming
data stream then it's hard to verify its validity, which
means your server is going to crash or won't be able to
give intelligent responses during your multiplayer tests.
You MUST validate that data, or your game will be too
fragile to play.
For the same reason, you'll need version info in any
data structures that are passed between the client and
server.
Hope this helped.
--t
