So more or less I’m attempting to create the Hello Collision tutorial (https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:beginner:hello_collision), but over a network where multiple players can join the game. The only thing that I can’t figure out to this point is how to, and I don’t know how to correctly word this, but create the actual scene itself and pass it from server to client. I tried sending the sceneModel, bulletAppState and landscape variables to the client and then constructing the scene (correct terminology?) client side and it threw an error when sending the message, so then I treid simply sending the location of the .zip and main.scene as Strings and then constructing the entire scene client side. This compiled fine, but all that showed up was a blue screen with the player in the middle of it (I had a third person camera).
I guess my question is, how should I go about constructing the scene and synchronizing it between server and clients. I need someone if at all possible to steer me in the right direction.
Regarding “threw an error”: computer-generated errors usually give clues as what went wrong so you can fix the issue. Next time you get a runtime error, save the message and any associated stack trace in case it might prove useful to you (or those trying to help you).
Try encapsulating the minimal information needed to reconstruct the scene and physics situation: not the materials, collision shapes, and landscape geometries (which probably don’t change) but the parts which do vary (position of each character, for instance). Write methods to convert this information into a renderable scene. Test these without the network first. Have the server send this information to each client periodically (or at least the changes) and make clients reconstruct the scene from that.
You’re going to have to create several messages which you’ll use to add or remove nodes, and to update their state. This could be as simple as
AddNodeMessage (1 field being a long GUID, 1 type field probably an integer)
RemoveNodeMessage (1 field being long GUID)
Then
UpdateNodePhysicsStateMessage (GUID, Position, Orientation, any physics influencers e.g. velocity)
UpdateNodeLookMessage (GUID + information on the nodes appearance. If it’s an object, maybe an identifier. If it’s a player, then player information, particle id, etc.)
What I would personally do is create static objects (e.g. buildings and terrains) on the client and only add players, npcs etc over the network.
There’s 2 quite nicely documented applications (by the same developer) in the RuneScape Private Server communities named Apollo and Hyperion. The knowledge is transferable to most server applications.
These 2 have lists of local players. Once a tick, this list is updated with new and removed objects from updating (based on distance and other factors), then they’re updated based on what has changed (if they’ve just been added, then every field is updated, and then it listens to update flags from then on)
I finally found out a day or two ago that my second idea was working just fine, I had just forgotten to add message listeners for my client to receive the messages containing the location of the scene to be created and the hashmap containing player locations. Oops. Thanks for taking the time to respond and linking me to interesting articles, though.
