Just an FYI:
http://www.captiveimagination.com/forum/index.php/topic,94.0.html
If anyone here is interested in a Xith or Java3D networking extension for JGN 2 please let me know. It would take all of 5 minutes to add with the new architecture.
Enjoy. 
At the time I was new here you were bothering everyone to use JGN and I promised I would use it 
ā¦ Iāll try it as soon Iām done with my own NIO networking (plus whole game), couple of months from now at this rate.
Bothering everyone is a bit strong right? :o Well, if I convinced an extra person to try it I guess it was worthwhile.
You know, you might find looking at JGN earlier may offer the possibility of switching to it and completing your game even sooner. Or at least maybe getting some better ideas about abstraction at the least? If nothing else perhaps you can give me some good feedback about what I can do better. 
Iāll look at the code to see what can I learn from it, but in this project it speed dosenāt matter only me learning stuff so first Iāll finish it with my networking. Later Iāll do polishing and then Iāll implement JGN.
Great! Besides, youāre more benefit to me if you know networking.
only thing I canāt be sure is if I would be able to get it then becouse all of the people interested in it, it might kill your bandwith ;D
Well, why not. But Iām curious how would you do that ? How is it currently working in jME ? What are the practical applications ? Can networking be handled only in reference to the graphic API ? Please shed some light on this, Iām so ignorant you know
hehe, well, I have an interface called GraphicalSynchronizer that contains all the methods JGN needs to communicate with the graphical engine. All that creating an engine wrapper takes is implementing that interface specific for the engine. I just released another one for GTGE. So currently I support jME, jME-Physics, Swing/AWT, and GTGE. I glanced at Xith last night actually but didnāt get around to doing the implementation.
For example, the source for my reference Swing implementation:
/**
* This is an example implementation of the GraphicalController for use
* with Swing. The objects specified are Components.
*
* @author Matthew D. Hicks
*/
public class SwingGraphicalController implements GraphicalController<Component> {
public void applySynchronizationMessage(SynchronizeMessage message, Component component) {
Synchronize2DMessage m = (Synchronize2DMessage)message;
component.setBounds((int)m.getPositionX(), (int)m.getPositionY(), 50, 50);
}
public SynchronizeMessage createSynchronizationMessage(Component component) {
Synchronize2DMessage message = new Synchronize2DMessage();
message.setPositionX(component.getX());
message.setPositionY(component.getY());
return message;
}
public float proximity(Component component, short playerId) {
return 1.0f;
}
public boolean validateMessage(SynchronizeMessage message, Component component) {
return true;
}
}
Then in your code you simply register the Component objects in the way you want to use them with their priority and synchronization information gets sent for you and applied. I havenāt added anything for dead-reckoning or anything yet, but intend to in a future version. The proximity method can be utilized to specify how close the object is to you. If the proximity is 1.0f the component gets synchronized at the standard rate, but as it approaches 0.0f the delay increases (meaning the object is further away and doesnāt need to be synchronized as frequenty). When the value is 0.0f no update is sent because it is considered to be outside of range of your player. The validateMessage gives the game the opportunity to validate the message to verify it before it is applied. This is useful for a server to be able to determine if a player is either too far out of sync to accept the update or is trying to cheat. Further, if it returns false it is not only not applied, but it also sends a message back to the sender telling them to update the position of that object to where it really should be.
There is still a lot I intend to do with this, but it does offer a lot already.
Interesting, but you know often game objects arenāt scenegraph objects, theyāre like :
public class Robot extends GameObject {
public BranchGroup graphics; // The graphics of the object
public Body body; // Used for physical simulation
...
}
In which case I suppose you just provide your own implementation of GraphicalSynchronizer ?
If youāre using a scenegraph they would be. If youāre not using a scenegraph, or want to do things differently you could easily provide your own implementation. In fact, if you wanted to synchronize additional information youād just have to extend Synchronize3DMessage, add the aspects specific to your game, register your new message class, then create, send, and receive that message in your graphical controller instead of the base message and youāre G2G.
My goal was to pull as much work away from implementing games as possible and I think the GraphicalController provides that. However, this is just one very small aspect of JGN. You can also do remote objects, synchronized objects, complex listeners, client/server specific functionality, peer2peer, etc.
I think itās a bad practice to extends Scenegraph objects for you game objects. Itās against componentization. Thereās no use to have an addChild() method in my Robot, and having a removeAllChildren() method is a mess.
Thatās fineā¦the graphical synchronization doesnāt require you to use the same objects it does. The scenegraph objects exist and you can register them with the graphical synchronization system and still have your own game objects that do their work. Or, you can create your own graphical controller and have it work any way you want. Itās all up to you.
Yes, yes of course, I didnāt want to say that there was a problem with JGNā¦ Just didnāt see why someguys are coding by extending āgraphical objectsā.