physicsClient as source of event

Hello I'm new to this forum



I'm exploring JGN  to add some code to a little game written wih JME and JME physics and make it multiplayer.

Has anyone considered another solution instead of sending frequently messages  regarding a physics Node attribute?



I mean to avoid network congestion we could only broadcast InputEvents and then process them on the server side (in a peer2peer context obviously)

Is there anyone who implemented such a scheme ?

The problem with broadcasting events is that if you miss one then you've got problems which almost requires you to use TCP.  If you use TCP latency spikes are much more common.



Essentially what I'm trying to say is though your goal is to reduce network traffic thus increasing performance of your networked game, in fact you are quite probably doing the opposite and making it less effective.



The standard mechanism in JGN for the physics synchronization is actually far more efficient because it uses UDP and though it spams positional information it doesn't really care if it misses one so network congestion is less of an issue and there are virtually no worries of lag spikes.

Tnx for reply

Ok I agree … but there shall be an hybrid solution; consider a massive multiplayer online games with hundred thousands people connected… a server or several mirrored servers couldn't handle such massive traffic


This is true, but my solution (as the game I'm currently developing has that potential flaw) is to split out the "MMO" traffic from the "real-time" traffic.  So you can have less traffic for things that must always be in sync all the way across the universe (MMO traffic), but for the real-time traffic it can be moderately out of sync throughout the universe just so long as locally to the people that are near you the information is approximately correct.



Essentially what this means is having potentially several servers act as real-time servers (like several Battlefield 2 servers) and they manage their area of space (which would increase or decrease depending on the number of users) and then you can have fewer servers covering the same amount of space for the MMO style of information (trading, manufacturing, communication, etc).  Essentially in the networking concepts you've got two games running at the exact same time, an MMO and a real-time game.  That's how I intend to provide the dog-fighting capabilities in a space game, but still appeal to the MMO universe.

that's a great  idea i shall admit    in the worst case u could overcharge your real time servers … but  it' s the worst case  :smiley:

But see there's no reason that should ever be the case since you have complete control over when/where each real-time server takes control and completely separately when/where each MMO server takes control so you're not losing anything except problems.  :stuck_out_tongue:

you're right  :)  …if I discover some new idea I'll post here …however tnx!