You can check it out from CVS or download the jars. I would have a problem providing any screenshots as it's a very abstract networking api meant to be built on by other projects (such as my other project that is currently being developed: https://odenetworking.dev.java.net/). In general it's an abstraction away from having to deal with the UDP messaging and reception as well as a best practice for how to do game networking as many people come to writing games without much if any knowledge of how game networking should be dealt with. This may not be a large issue with small projects, but I'm currently writing this for a FPS that needs real-time updates for physics to occur to synchronize as well as providing a means to keep rogue clients from hacking the game.

PS - the odenetworking API is getting quite close to completion if anyone would like to take a look at the current version in SVN: svn://pyramex.com:3691/odenetworking/trunk I would like to get approval for this project as well since it is really a more featureful implementation of this project but geared specifically towards the OdeJava project. This is also a great example of the purpose of the JavaGameNetworking API.

The biggest difference between this project and jenet is that JGN is all about game networking. Further, the major feature of JGN is the JGNServer that allows it to listen for UDP messages and generates events for those messages that it receives. This is much easier method of abstracting from the actual work involved in networking as well as making it very easy to extend to provide specific implementations for games. Jenet is fine for doing network communications, but I believe it focuses too much on the process of networking and does not provide enough of an abstraction layer. As I've been looking into it I see some advantages to it as well and if I see enough benefit I may modify JGN to be a wrapper around jenet in the future.

I actually wrote this because of the problems I saw in the architectural design of JNAG. JNAG (at least from what I've seen) utilizes TCP Sockets and some other inefficient methods of networking for gaming. I'm sure that's fine for most games, but the goal of my project was to provide the fastest possible means to send and receive messages from clients and server for games like first-person shooters that require everyone be synchronized in milleseconds not seconds. That is the goal of this project and I hope it has in some small way realized this already, but definitely in the future I believe it has the potential to do so.

That's because it's not approved yet. All pending projects get first into games-inbox and then get moved to the correct position, when they are approved. It's the same reason, why we can#t acces the cvs yet.

Edit: ohh I should read the posts above more carefully...mmh strange, didn't Jeff say in the post before, he'll mark it approved?

I appreciate you taking the time to respond, that helps me understand this process a bit better.

I only have one other java.net project and it wasn't a Game project so this is quite a bit different. I don't know if you or anyone else would care, but its javarelational.dev.java.net (or http://www.javarelational.com).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org