Hello, I''m currently thinknig about the minimal amount of data a client must send to a server in a Massively Multiplayer Online Game. In the scenario I''ve imagined, an object (P) poles say the joystick 50 times by seconds and an other object (S) sends those events to the server. Now I can handle those events in two ways: -1- S sends the events 50 times by seconds and I must reduce to the minimal size the packets sent. -2- An intermediate object (I) manages the events sent by P and produce requests packets that S will send to the server like: Can I go to the left? Can I jump?... I think their are other ways to handle this problem, if so, can someone give me some hints? Thanks, Wonder Sonic

Method 2 is perferable for large scale MMORPG games whose pace isn''t as fast as a FPS. If however, your trying to make a game like Planetside, which is a MMORPG and FPS, then method 1 is the only way to go, but i wouldnt send and event 50x a sec, a more reasonable pace would be send a single or repeating event at a maximum rate of 15x sec, but at a time resolution of atleast 30ups. The timestamp is sent with the event, so concurrency issues can be resovled on the server side, as to who did what first, and to serve as a refrence for time based events.

For method 2, the more abstraction from raw input to desired event, should reduce the amount of data sent from client -> server.

Good Luck

-ddn

In fact, I''m planning to make a MMOARPG (A for Action).
My goal would be a LandStalker (http://www.shinforce.com/genesis/reviews/Landstalker/ look at the bottom for screen shots) game like but massively multiplayer.

Thanks for your comments.
Indeed, solution 2 may reduce network traffic but would be less secure than joystick inputs (or am I wrong?).
Actions could be interpreted from joystick:
- UP+RIGHT => go forward => request = can I go forward?
- Button 0 => jump => request = can I jump?
- Button 1 => fight with my weapon => ...?
- Button0 + Button 1 => fight with my weapon while jumping => ...?
...
But their can be a lot of them according to the context
So I''ll first try using joystick-input with less than 50 updates
by second sent to the server. What about 50x updates on the client and 20x updates for the server using dead reckoning?

I''ve red the article: http://unreal.epicgames.com/Network.htm and found it very interesting! I think I''ll use some of the ideas.

As mentionned earlier, I''m currently studying dead reckoning algorithm and I find the principle quite interesting, I didn''t thought such idea could be used in FPS, I wonder if new problems may occurs if applied to MMOARPG? (especially the amount of data the server must handle) And I''m searching for a Java implementation...

Yes, I''ll use the Java language. I know a lot of people think "this language is too slow..." but I can answer that with the 1.4 JDK family, SUN made a lot of progress see the screen shot: http://sourceforge.net/docman/display_doc.php?docid=9837&group_id=45052

Well, back with the subject: I''ll make some prototype using the JavaGroups API (http://www.javagroups.com/). And be back for more questions...

WS

20x is quite reasonable. However most FPS network code abstracts the events a step up from the raw input data. Also they give the clients more authoritive abiltites, to reduce the perception of latency even further.

For instance most FPS actually let the client dictate the players position to a degree as well as hit events from bullets.

What usually happens is the client send the pos of the player every 10x sec. The server extraplates to the true pos based upon the timestamp and send that info to the other clients. It also does various anit-cheat checks like making sure the player isnt moving too fast or going through walls, etc..

To the player, all thier actions seem to occure instantly but it''s actually extrapalted for 2/10 of a sec, until an event from the server arrives to either correct the player or if everything is ok, nothing happens and the player state isnt changed. Ofcoruse if your lag is higher than 2/10 of sec that adds onto the amount of extraplation you have to do as well as more potential to get out of sync with the server. Thus the anoying rubber banding effect on low bandwidth connections when playing FPS multiplayer. This can also result form packet loss.

That should get you started on a FPS network model. Areas for optimzation, include more robust deadreckoning on the client side to reduce the amount of data that needs to be sent, as well as more robust concernecy model on the server side. This will allow you to even out the game play with respect to latency. Not everyone will have 60 ms pings to your server. The more fair you make your play field the more players you will attract.

Good Luck

-ddn