Server and Client Connected... Now what? How to see another client's character or model by another

Dear monkeys… I’m stuck with another problem… I can already connect a client to a server and has already learned about messages. Now, i’m planning to make the client load only a single model and place it on a random location. And what i want to do right now is that when i open another client, of course it will load the model and put it in another random loc… I want that model(from second client) to be seen on the (first client). How can i do that? I’ve researched the net and came across worldstates and entities… But I don’t know if it is the correct topic to start.

I am not sure if I got your question, but if you want to have both clients to show same model at same position you broadcast a message with the modelinfo from the server and then place the model at that position in the clients. If the client generate the random position you first send a message to server who then send the info to the other clients.

Yes, world state and entities is the correct topic.



You really want the random model to exist on the server… at least as an ‘entity’ with a position and orientation. Then you can construct messages that broadcast this “world state” to the clients.



The tricky part will be that SpiderMonkey calls the message listeners in a separate thread from the rendering and JME won’t like it if you move models around from a separate thread. There are a few ways to handle this. JME has the ability to add Callables/Runnables to a queue that gets executed at the start of the next render frame. So you could wrap your position/state messages in a Runnable that applies the changes to the scene graph.



Another more manual approach is to put a java.util.concurrent.ConcurrentLinkedQueue somewhere that both your listener and simpleUpdate() method can access. Add the incoming messages to the queue, pull them off and handle them in simpleUpdate(). It’s only benefit is that it’s slightly less magic than the Runnable approach, though the Runnable idea is ultimately the JME-prescribed way and is more flexible.



For a real game, the above will eventually have performance implications, etc. but for trying to figure out how things work it’s a good first step.