The PhysicsNetworking API I wrote has physics synchronization as well as positional synchronization. The latter could be easily ripped out into its own API if there's enough interest in having a jME-Networking API for games that do not utilize jME-Physics and want to network their games. How many people think this would be useful to them?
im split between 1&5 
Sorry buddy, it wouldn't let me create it so you could choose multiple answers. :-p
darkfrog
so yeah, I've already implemented most of the network coding that i think i am going to need for now. I'll most definatly need to come back to the api and forum since i doubt im never going to have to code a line of multiplayer again. But my game doesn't have use for JME physics, so im a bit worried what is going to happen in the future when i came to back to JGN and see that it joined with JME physics.
It will never be "joined" with jME-Physics. However, it does already have a extension API called PhysicsNetworking that is tied to jME-Physics, but that's it's own project. That's exactly the same as jME-Networking would be. Just an extending API. JGN will always remain completely indifferent to what graphical engine you're using. That way the people over at Xith can use it if they want, it can be used for something 2D, or anything.
darkfrog
As far as it is abstract enough to allow different networking solutions, I'm more than interested.
I'm planning to use Project Darkstar for networking communication for a game i'm developing
Though Darkstar has a lot of potentially for MMORPGs I don't see it as being useful in smaller scenarios. From my initial looks at it I also didn't like the API, but that could also be because after writing my own I'm very particular. :o
I have been considering doing some performance testing between Darkstar and JGN to see how they stack up. I think for large applications Darkstar will probably scale better, but I think it will be a beat-down when it comes to small standard networked games.
darkfrog
kman, after your comments I went back to look some more at SGS and consider how much effort it would take to write a simple test and I don't think I have the kind of time it takes to learn such an overly complex system. :-p I'm sure it's great for extremely complicated systems, but it looks like the people who wrote the J2EE specification have moved to the gaming world. :-p
I definitely think there's a need for a lot of the ideas of SGS, but I believe that it can be implemented in a much better way. Obviously I'm biased though, so take my comments for what they're worth. 
darkfrog
I don't mind which is the usage scenario. My interest is in a high-level implementation that can support different networking libraries (not out of the box, i don't want to increase your work load). if you provide a high level implementation using JGN, maybe i can write an adapter for Darkstar. Either way i'm more than interseted in a jme-networking solution.
and since you replied at the time i typed these( i got tired typing and dont want to keep pressing backspace }:-@) i agree for the complication but keep in mind that darkstar active development just started. Anyway keep it good, keep it simple enough, but let some space for extensions or incorporation of other libraries.
Absolutely, that is the primary goal of JGN is to be an extremely lightweight networking API that can be extended by other APIs (such as jME-Networking or the already existing PhysicsNetworking). I would ask if you'd be interested in helping write an adapter for Darkstar, but if you're too lazy to use the backspace key I think I already have my answer. :-p
Honestly I will probably write some very specific code for use in MMORPGs in the not too distant future for JGN, but as far as an implementation that relies on SGS I highly doubt that as I don't see a whole lot of advantage from that. If you know of some good reasons please tell though. 
I will take all of this feedback as good enough interest in jME-Networking and start working on it very soon.
Just a thought I'd like to run past everyone since I already have your ears…or eyes. :o Anyone that would want to use JGN would they be interested in sending messages that have other objects with them? Such as being able to have MyMessage that has a getData() that could return an ArrayList<MyObject> and all of that data be streamed across or should I stick with primitives, Strings, and arrays? Obviously for efficiency you would probably not want to stream complex objects across, but if there's enough interest it is pretty trivial to add that support before the next release of JGN.
Thoughts?
darkfrog
darkfrog i want you to know that i am lazy when i write text and comments }:-@ not code. so count me in for a darkstar adapter.
Since we are talking about a game networking api it would be good to support streaming of binary data (to include for instance update functionality).
I dont know if it is efficient to use xstream from xstream.codehaus.org to serialize objects or even use a scripting language such as beanshell for messaging.
Binary streaming can already occur in JGN, but I'm going to be reworking it a bit before the next release. No, it would not be efficient to use something that serializes to XML. I've already written a system before that essentially provides network serialization and deserialization but not nearly as heavy-weight as what is included in Java already since it serializes the class along with it. In this case you simply need the data to be pushed back into the object on the other side. The code I would be adding allows you to take any Java object and based on the getters and setters it will persist/depersist the object for you.
BeanShell is extremely slow, so I have no intention of using it in JGN if I can help it. My initial tests for messaging in JGN utilized BeanShell and it was so slow I abandoned it almost immediately. It's signficantly slower than reflection and I consider reflection extremely slow.
darkfrog
Dark, hope you are not using reflection but introspection
Both actually…but only if you don't have the JDT jar in your classpath. If JDT is available it dynamically generates source code, compiles the source code, and dynamically loads the generated classes at startup so no reflection has to occur during runtime.
You can also define your own "handlers" for each message instead of letting JGN generate them for you if you'd like to have greater control over how messages are translated into bytes for sending and receiving. The system is actually quite flexible.
darkfrog
Not the static Method [] methods, then invoking them at runtime — unless things have changed in the last few years, its not a quick way to go
I invoke them at startup and then create a mapping of methods that I need to invoke. It's pretty efficient when using reflection, but that's why I added support for JDT so it could hit classes directly instead of using reflection or some other hack.
It also has the ability to pre-compile the classes and then include them in a jar so JDT is not necessary and no compilation has to occur in the release, but you get direct class access speeds.
darkfrog
I have added functionality to JGN to support my creation of jME-Networking, see the following thread:
http://www.captiveimagination.com/forum/index.php?topic=67.0
I will hopefully have a separate JAR you’ll be able to download in the near future that can be combined with JGN to provide extremely simple and flexible networking for jME games. I would be happy to add that functionality to jME directly, but it would require a dependency to the JGN project and I’m not sure everyone would want that.
darkfrog
Preliminary release time for those of you who can’t wait to get on the jME-Networking bandwagon:
http://www.captiveimagination.com/forum/index.php?topic=68.0
You’ll need to be running the latest version of JGN from the repository in addition to jME-Networking from the repository to get there, but that should be all you need to add networking to your games.
Like stated in the linked forum posting I don’t currently have any test examples but will hopefully be adding some by the end of the week as well as probably re-working the PhysicsNetworking stuff to work with the new jME-Physics.
Enjoy.
darkfrog