I’ve released my client/server networking library, Ninja, under the BSD license:
http://groups.google.com/group/ninjanetworking
Would love to hear what you think about it! Code reviews and constructive criticism are most certainly welcomed! 
Feel free to post comments on the code here, or PM me and I can send you a link that will allow you to annotate the source right on the Google Code website.
Nice work Nate! I’ve only briefly looked at it, but it looks like you’re making good progress.
Any games using it yet?
If I were you, I’d implicitly register the 1D and 2D array types of any class that is registered, to remove the burden (and confusion) from the developer.
Thanks. No released games using it yet. It has 3 or 4 users so far, but its only been out a month or so and been BSD only a few days. I have plans to use it in many game, with one in progress. It is neat to play a game on the desktop using Slick against the same game on Android!
I hesitate to do it automatically because the ordinal for registered classes is sent across the wire each time the data for an instance of the class is transferred. If 0 <= ordinal <= 253 then I can transfer the value using just one byte. For 254 <= ordinal <= 65536 it takes 3 bytes. So if every class registered took 3 spots for class, class[], and class[][] it would start using 3 bytes to send ordinals after 84 classes registered. Not a huge deal, I know, but is it really that bad to register it? This is the exception you get the first time you try to send an unregistered array:
[quote]IllegalArgumentException: Class is not registered: short[]
[/quote]
I went to extra trouble to make this exception message nice and pretty.
Getting an Exception the first time you give something a try is kinda annoying.
You can also change the protocol a bit, and assume nobody is every going to use more than 4D arrays, and use 2 bits in your header.
00 => 1D
01 => 2D
10 => 3D
11 => 4D
That would give you 6 bits (64 indices) for your classes. That’s about enough for 99% of applications. You can ofcourse use the ‘wide’ 3 bytes protocol if people really have up to 64K classes around.
Hi,
I’ve been using Ninja for a game I’m working on, and I need to see the javadocs, but the link [http://groups.google.com/group/ninjanetworking] is broken. Did you delete the group?
Yep, gone, sorry. Someone contested the name “Ninja” so I figured it was easier to just rename it. Here is the last JAR and source for Ninja, javadocs included:
http://n4te.com/temp/ninja-final.zip
Hope this holds you over until the new projects are ready!
The-project-formerly-known-as-Ninja is being broken into two projects:
Kryo
http://code.google.com/p/kryo/
Does the serialization. This way the serialization bit can be used without the networking bit, or with a different networking lib. I did some benchmarks and it holds up well against other similar libs (such as Google’s protobuf):
http://code.google.com/p/kryo/wiki/BenchmarksAndComparisons
I am just finishing up Kryo and starting on refactoring the networking piece.
KryoNet
http://code.google.com/p/kryonet/
This is the networking portion. Obviously, it uses Kryo for the serialization. Will be an almost identical API to the-project-formerly-known-as-Ninja.
“Kryo” isn’t the best name, but the good names are taken. I was spending way too much time just trying to name it, so Kryo it is! At least it is short…
The HTTP communication portion of the-project-formerly-known-as-Ninja is getting moved to a “client” project the Legion project:
http://code.google.com/p/legion/
Legion lets you send/receive objects to/from a servlet just as easily as Ninja/KryoNet. This means it is easy to write turn-based games and desktop or mobile applications that communicate with a webserver. Any webserver will work, but a servlet container lets you use Kryo on the server. Legion supports Google App Engine and will come with some common functionality (user registration, login, sessions, arbitrary data storage).
I’m also working on another project called Skorpios for OpenGL on both desktop and Android with a single codebase:
http://code.google.com/p/skorpios/
The code for this was mostly ready a couple weeks ago, but I just recently came up with the name (wanted Scorpion but Skorpios isn’t too bad) and have been busy with other things. The code will be up soon!
Thanks.
Just to make sure, is ninja.jar in ninja-final equivalent to ninja-0.7?
Good luck with the new projects.
[Too bad about the name, kinda got attached to Ninja… ;)]
Thanks. Yeah, Ninja was a good name. Too good I guess.
Uhm, I’m not exactly sure if the ninja.jar there is the same as 0.7. There may be some small differences. I forgot to tag the release in SVN.
Mind if I ask what you are working on? I’d love to see the project in action!
Kind of glad you changed the name. If you google for ninja networking you get www.ninjanetworking.com as one of the top hits. It seems to do roughly the same thing and has a similar logo. Was a bit confusing when you tried to google your library.
Heh. Yeah, those were the guys. See, I chose the name “Ninja” and thought I was fine. There is a number crunching library for Java with that name, but otherwise I’m good. When I went to register on Google Code, “ninja” was taken by a non-Java SourceForge project. I registered “ninjanetworking” without checking it sufficiently. Oops!
Oh well, changing the name got me thinking it was better to break it into two projects, so I think in the end things will be a lot better.
Good to hear that you’ve created the pages for Skorpios!
Ashley Gwinnell, sorry it has been taking so long! I should have some Skorpios code checked in soon.
Checked in the code for Kryo just now!
http://code.google.com/p/kryo/source/browse/#svn/trunk/src/com/esotericsoftware/kryo
It started as the serialization portion of Ninja but has undergone some heavy refactoring. Besides a cleaner API and the ability to use it standalone (without the networking portion) the biggest changes are that it doesn’t use static methods and that serialization is thread safe. This makes the library useful in servlets, as well as just about any environment.