Another update. I've gotten a lot of good feedback about Roll-A-Rama and it seems to be running pretty stable. I'm going to spend some time this weekend hopefully making it an enjoyable game. I also went back to the CarTest example and figured out the problems and it works quite well now. It's pretty neat to be able to ram into each other. I am still having some problems on efficiently sending and receiving messages. The server can get pretty backed up when there are multiple clients (I see this in the CarTest because there is the chassis and four wheels that I'm sending physics messages to the server for) and lots of physics objects being updated. I'm still working on streamlining this so messages can send faster…I need just as much out of it as I can for FPS games and it's just not there yet.
Anyway, I'm ready to release the API, but at the moment I'm not really sure where to put it. I'm considering just creating a SourceForge account for it since I've been so disapointed with Java.net lately (featurewise and reliabilitywise). If anyone has any suggestions of where I should host the project please feel free to let me know.
Also, I'm considering splitting these two APIs (JavaGameNetworking and PhysicsNetworking) even further and would like some opinions:
- Basic Networking API (I'll come up with a better name, but most of the stuff from the current JGN project could fit into this category as most of it is not explicitly game-related)
- Game Networking API - stuff explicit to game networking (i.e. Updater, player information, state information, etc.)
- jME Networking API - I realized that I've already got all the basic functionality for this API already built into the PhysicsNetworking API since it updates Spatial location and rotation. Of course I might want to add more than that to the API, but the foundation could easily be split out
- Physics Networking API - an abstract API that has no graphical or physics dependency. This would allow changing to a different graphical API and/or different physics API much easier
- jME-Physics Networking API - This would build on top of the PhysicsNetworking API and the jME-Networking API to deliver explicit support for jME-Physics
That's a whole lot of APIs, but I can see the benefit of each one and although I would probably keep them under just a couple project headings, would like to find out of others agree to their benefit?
darkfrog
Would be happy to help out, but time is constrained so much for me at the moment, am working 16 hours a day on getting the first release out.
I will be touching on server stuff within the next few weeks - fortunately the alpha is likely to go back to jan with a pre alpha before xmas.
If you get stuck on something - post away, ill try and help
Okay guys, temporarily I’ve gone ahead and released the jME-Physics Networking API at http://javagamenetworking.dev.java.net. In order to use the API you’ll need jME, jME-Physics, and the JGN API.
Comments and criticism are welcome.
PS - I also added a few new features to JGN as well (such as PerishableMessage that will be ignored if it is determined to have expired).
Happy networking,
darkfrog
One more thing, who here has any interest in using JGN and/or PhysicsNetworking in a JRE earlier than 1.5? Currently the API is 1.5 compliant, but that could be changed if people want backwards compatibility. The code is simply more elegent if I keep it 1.5 compliant and unless someone specifically wants it I'll just leave it 1.5.
darkfrog
Check out list of outstanding bugs on java.sun.com - one is to do with multicast, it may effect you.
As mentioned, some services are being enabled to make multicast work c=accross the net, is worth a look as is the most efficient way to broadcast
You should be able to set timeouts with the tcp/ip - 30 seconds is outragous if that is the case, that user should be disconnected if they lag like that imho.
The nio non blocking architecture means that even if a client has horrendous lag, it wont block ever one else
Well, the current architecture does not use Multicast, so when I have a chance to consider it further I'll probably look into that. Thanks for the heads up.
darkfrog
Yes please, we at MW3D would love to get our hands on a version that
runs under JDK 1.4.2.
Also this feature is very important for other people using the api.
Thanks.
Yeah, I just needed to hear someone say it…I had a pipe-dream of being able to use 1.5 in an API…I know, it's silly. :-p
I should have it 1.4 compliant this week.
On a side note, I've spent a lot of time re-working Roll-A-Rama and it's actually fun now, but I'm not done adding features to it. Hopefully that will also be done this week.
darkfrog
Okay, okay, okay it's updated for 1.4 compliance and checked in…it hurts to make my code ugly. :-p
darkfrog
tgiant - why dont you switch to 1.5. Cant see what holds you back
Unfortunately, the reasons for maintaining 1.4 compliance is not because of your own needs, but because of the people using your API, tool, or application. It would be great if we could just expect everyone to be using the most recent version of the JRE, but unfortunately that is not so.
darkfrog
Thats nasty…
I will look to extract my NIO server framework stuff, but i know there is 1.5 stuff in it…