PROJECT APPROVED: ODENetworking

[Jeff]

ODENetworking API implements the JavaGameNetworking API to provide an easy way for games utilizing the OdeJava Physics API to provide server synchronization for gaming clients.

[kevglass]

I'd love this to be done simply because its really really hard and I'd rather not have to do it myself in the future. However, given the conversation over on the networking forum I'd like to see some more details before think this project is just unfeasible and will end up as a zombie just floating on the server.

If there is a novel strategy behind it - I can't wait!

Kev

[sunsett]

Well, here I am again.  This is phase two of the networking project I've been dedicating a lot of time to recently.  You can take a look at the code already completed at https://odenetworking.dev.java.net/.  This is an extension of the JavaGameNetworking API that is already completed.  I have got this very close to completion, in fact, it may very well not need any more modification, I just haven't had the time to do all the test cases to verify all the functionality.

Take a look at CVS to see the code as it is and you'll see this is more than just a pipe dream.

Thanks,

Matt Hicks

Games published by our own members! Check 'em out!

[tom]

+1

[kevglass]

I don't seem to be able to get CVS access - maybe since this project isn't approved yet?

Could you just outline what the method for ODE physics synchronisation is?

1) Are you spitting UDP back and forth and mangling the results either side to keep them looking "roughly" the same?
2) Are you lock stepping the whole thing so you can't move the simulation forward until data and input has been recieved?
3) Are you forming some sort of hybrid simulation synchronisation that accounts for the players actions by pushing them into the future?

What sort of games would your networking sync method be applicable to?

Still a great idea, so I guess +1 anyway.

Kev

[sunsett]

Kev,

Great questions, I'm not sure why you're not able to gain CVS access (I haven't had any problems - well, I guess that's obvious or I wouldn't have been able to upload it) but I'm happy to give some explanation as well as the source code if you'd like me to post it somewhere?

In response to your questions:

1) Essentially yes, I am spitting UDP messages back and forth and I have several message types that can be sent back and forth: SynchronizationMessage, PhysicsMessage, JoinRequestMessage, JoinResponseMessage, StatusRequestMessage, StatusResponseMessage, ChatMessage, and DisconnectMessage.

The main mentionables in this are SynchronizationMessage and PhysicsMessage.  The SynchronizationMessage synchronizes a physics object's location, position, and rotation, and the PhysicsMessage synchronizes the physics state that the object is currently in (like what forces are currently acting on it, and in what directions, etc.).  The other messages are relatively self-explanatory.

2) No, this is not a locking system, this is why the server runs a copy of the ODE physics world as well so that things can operate real-time and synchronization events are passed up to the clients from the server to keep them synchronized, but the clients can continue to execute without those messages they just further become out of sync.

3) This is the part I'm still trying to work out actually.  I am trying to find some time to do the testing for high pings and handling the situation without their universe being choppy around them and what they're actually seeing is the past, not the present, but this may be something I need someone with more knowledge about this than I do help with.  Such is the benefit of having this project approved.

The purpose of this API is to be able to be able to be utilized in ANY games that utilize OdeJava's physics wrapper.  I am trying to avoid making this specifically geared towards any style of game and focusing on best-practices of providing a standard physics synchronization system.

Matt Hicks

[darkprophet]

Any reason for this project not being another module under the JavaNetworking API?

In any case, +1

[kevglass]

Yeah, sounds like its more a test bed for ideas, which is good. Always scary to be sitting in those waters tho. If 1) is essentially what you're doing you're going to hit lots of fun tring to run this across a network with any latency at all. (see that post in Java Networking). - http://192.18.37.44/forums/index.php?topic=10004.0

However, dead exciting stuff! I look forward to seeing the results.

Any reason for this project not being another module under the JavaNetworking API?

I agree with DP here, sounds like this project is a really good example of JavaNetworking API and might fit really nicely as a module. However, I guess it drags in lots of dependencies since its ODE dependent so makes it easier if its a seperate project.

Kev

[sunsett]

Well, I think of JavaGameNetworking API like JOGL or LWJGL and ODENetworking like Xith or jME.  They each have their own specific goals in mind.  JavaGameNetworking may change the internal approach to the way it works but ODENetworking doesn't have to care about that so long as the abstract API remains consistent.  Further, I didn't want to tie the baggage of ODE to JavaGameNetworking because there are several circumstances I can foresee where people will not be using a physics engine at all or be using something completed different.  I wanted to keep JavaGameNetworking completely agnostic to the existence of ODENetworking.  Now, I also wanted to leave the possibility for ODENetworking in the future if the need arises to no longer use JavaGameNetworking as well....I don't see this as likely since JGN is so awesome, but possible none the less.

Thanks Kev for the link, I actually started reading that before but never finished....thanks for bringing my attention back to it.

Matt Hicks

[sunsett]

After considering this further, I think I'm pretty close to having this right.  I think all I need is a synchronization method at the beginning to synchronize the clients local time to the servers local time to get their offset.  This way synchronization messages can be passed around with a timestamp and the system can say "Hey, this happened at this time" so that the screen remains accurate even if the player is lagged consistently.

The system is designed with the goal to set object priorities so certain objects send updates more frequently than others.  The PhysicsMessages and SynchronizationMessages are continually being passed up to the clients based on their priorities as frequently as really is possible and then the clients send PhysicsMessages and SynchronizationMessages for the character and any other objects in the game the client has "ownership" of (example being a shot fired).

The only problem I have to deal with is lag....missed messages aren't a big deal because the system is not dependent on it receiving any specific messages, it will just be out of sync until it gets another update.  This is the benefit of a server that is running the game as well because it can consistently remain synchronized and just pass up states to the clients.

Matt Hicks

Games published by our own members! Check 'em out!

[arne]

About the CVS problem: Users can't see your project until it got approved, so they also aren't not able to see the cvs and load from it. Only the project owner and I believe Jeff and other Modereators of java.net are able to acces it.

I think this project will be a big enhancement for ODEJava. And I also think it is ok to have it as a different project (simply think about the xith-tk, it's also not integrated in xith).

So:
+1
from me, too.

PS: I hope I can soon use this!!

[darkprophet]

Having different modules in CVS doesn't mean that JavaNetworking will be reliant on the other one. Nor does it mean that the user has to check all the modules from CVS, nor does it mean they have to checkout ODE's baggage to use JavaNetworking. They can still have seperate goals, be written independantly, and even (sf has this) only certain users will be allowed write state to certain modules through the CVSRoot directory...

I still dont see a reason for it to have a seperate CVS folder, at the same time, do not count this as a No vote...infact, its a +1!

DP

[sunsett]

Thanks Arne, as soon as this thing has been approved I will be looking for people's input about how it works with their projects and how it can be improved.

Matt Hicks

[arne]

Having different modules in CVS doesn't mean that JavaNetworking will be reliant on the other one. Nor does it mean that the user has to check all the modules from CVS, nor does it mean they have to checkout ODE's baggage to use JavaNetworking. They can still have seperate goals, be written independantly, and even (sf has this) only certain users will be allowed write state to certain modules through the CVSRoot directory...

I still dont see a reason for it to have a seperate CVS folder, at the same time, do not count this as a No vote...infact, its a +1!

DP

Having two different modules has the following main aspect: People that are members in e.g. ODENetworking  don't have to be members in JavaGameNetworking, but you'll also have to request a role in both projects, if you wan't to participate in both.  I think this should be the main part, of what the discussion (if there is one) should be about.
From my POV ODENetworking seems to be a project that uses JavaGameNetworking, like any other project not from sunsett could do. And you sure wouldn't add any project that has to do with your own in a subfolder of yours, would you?

Arne

[sunsett]

Well, it looks like I've got all the votes I need so I expect all of you guys to contribute to this project since I know at least a few of you have a vested interest or have spent time discussing networking theory in other channels.  :-p

I look forward to your thoughts and opinions.

Thanks,

Matt Hicks

[Jeff]

Yup this is a go.