sychronization in network game
i want to write a simple game which would have multiplayer mode over network.
(maybe lan or internet) so i have many questions...
how to write network multi-player game? without serious lagging (not due to network) but a lots of data to transfer?
how to transfer data? multi-unicast/multicast? what model would be better? server-client?
how to ensure fluency in the game?
what technique can i apply to make the game running more smooth?
any idea?
[491 byte] By [
huehuehue] at [2007-9-27 16:02:28]
> how to write network multi-player game? without
> serious lagging (not due to network) but a lots of
> data to transfer?
instead of things like
send("PLAYER_1_XPOS 50") //16 bytes
use
public static final char PLAYER_1_XPOS = 0;
public static final char PLAYER_1_yPOS = 1;
public static final char PLAYER_2_XPOS = 2;
send(PLAYER_1_XPOS+"50") //3 bytes
if you're using LOADS of data, you could try using gzipstreams, I'm not sure how to cut up the data as it's sent as many streams and decoded as one, so you have to know the original length of the gzipped data to get it back (wyvern uses this - http://www.cabochon.com )
> how to transfer data? multi-unicast/multicast? what
> model would be better? server-client?
regular sockets are usually ok, and more stable. server-based is fairer as all players have equal(er) CPU usage and lag
> how to ensure fluency in the game?
> what technique can i apply to make the game running
> more smooth?
fluency? like speaking foriegn languages? if you mean speed / cutting jitteryness, try giving a seperate thread to network reading, then read into a command stack and have the main game read from that
> any idea?
yes, see abouve :-)
Shish
Several quick tips for adherance to sound software enginering techniques for any type of multiplayer game design:
1) depending on the complexity of your project I'd devote at least 10% of your total development time in the design. The better your design, strong oo, data coupling issues, thread manager, bufferStrategy... the easier it will be to actually finish the game. 98% of all games started never get finished. This means having all of your Network communciations in one class or subclassing out extra features that might not be needed for your based network messaging system.
2. Always thread your communications with higher level priority then your draw method. I've found that setting my network thread to normal and my draw thread to low priority yields far less lag then having them both set to normal priority. The reason for doing this should be evident. Messages are much more important then repainting the display as far as multiplayer games are concerned.
3. create any new 2d game in Fullscreen Mode and use a bufferStrategy that allows you to flip between offscreen buffers. This will speed up any application written in java tremendously. Repress the repaint call that is normally triggered by the awt. You will be designing your own painting alogrithm so having repaint still active will only slow things down.
4. Create a separate physics thread from the paint thread. These 2 things need to be separated in order to create fluency in your game. Depending on your actual game desing the physics thread will be responsible for moving things around in your world and handling most of the game communication with other players. The paint thread should only be responsible for drawing the current state of the world. This is probably obvious to most without being said but I've seen a lot of people make this mistake in their initial designs and they updated their game objects just before or after each repaint..
5. My last point addresses your network traffic issues. There are a lot of techniques out there that can improve your data transfer rate. For example a technique called deadreckoning is often used to reduce the amount of network traffic by 90% or more. Deadreckoning, simply stated, estimates what every other persons objects will be in the physical world since the last message you received. If plausable for your game idea you could send routinue messages to each other player in the game world every 1/2 sec or second and between message communication have your physics thread estimate changes in the world until you receive the next message. Then verify that your estimate were correct/incorrect and reset them if needed.
Make sure you are only sending data on objects whos modes have changed. If nothing has changed with an object then its data doesn't need to be sent to the other players.
Hope this helps. you were rather vague about your development so it really isn't possible to suggest one protocal for your network over any other protocal.
