Hello Darkfrog & Friends ... ! I wanna make it a multiplayer game too !

[kine]

Hello guys !! 
I have a few simples questions ... :

Is this API still being developped ?
Is it compatible with JME last version 1.0 + JME Physics 2 ?
Is there another equivalent networking API that use JME Physics ?

Where are the other develloppers ? I thought DarkFrog(c)y would have bring them here ...

Thanks in advance for your replies !

 

[darkfrog]

Well, the API hasn't needed to be touched for a while because it's relatively simple.  However, I just took a look at it again to verify there wouldn't be any problems using it and made some efficiency fixes on it and checked it back in.  You can get the most recent version from SVN or from here:

http://forum.captiveimagination.com/index.php/topic,97.msg809.html#msg809

This is the only API I've ever seen that offers physics networking for any physics engine.

From time to time JGN has other developers working on it...JGN is a pretty stable API and many people use it.  However, it probably will never have the following that an engine like jME has because most people never make it to the networking aspect of their game before realizing game development is hard.

[kine]

Being thinking of a network API, i tought the most efficient implementation was to have only one physic simulation for a networking game and to throw  spatial transformations to each game Instances. I guess that when every computer has receipt Physicsmessages from the ruler it might be the same, considering network refresh time << timeperframe.
It's ok !!

[kine]

Don't read my last message about only one physic simulation running on a server for network gaming. It's a ridiculous empirical physic way-of-think problem. None in information theory !

[darkfrog]

hehe...I did my best to use the most logical means for designing this API so hopefully you'll agree after you've spent some time playing with it.

[kine]

 

[kine]

Hello !

So I continued my game called Bolidz: a super cars race with rockets bullets hook jumps loopings etc ....

I plan to start multiplayer coding theses days so I have a few question ...


The method the most used for this kind of game since to be a client server mode, where a physical simulation containing all the cars is running on a server, whereas a physical simulation with the player only should run on each pc, to avoid dead reckoning. Cars of others players should be only simulated as static physic cars ( move refreshed by the server info) or something in each pc, to avoid dead reckoning when collision.

For that I planed to use a dedicated carPhysicsMessage contains all the joints wheels position velocity etc ...

Things seems to go well this way but my problem is the following : what happens when there is a collision ? : each player keep moving his car, but the shock is computed on the server; so at the very beginning of the shock, the server should compute the collision and send a carPhysicsMessage to the client but at the same time the player keeps turning his car so I can't send a carPhysicsMessage from the player client to the server because his simulation don't contains the opponent. That's my problem ....

If I use a static opponent ( moved manually from the server datas), the player simulator might well compute the shock, but there won't be friction contact due to rotation speed of the opponent things like that ... ?

So may I send instead each move parameter like turn left (amount of time pressed beetween a refresh) to the server so that the server is able to well compute the collision ?

I imagine I'm lost in a no ending problem, so my point of view might be wrong ... please correct me ! 

Kine

[darkfrog]

I wouldn't recommend this approach. However, I will state this is a very similar method to what TrackMania Nations does for its multiplayer functionality...which is a good example why you shouldn't do it.  By not managing all cars on all clients and rather just synchronizing static objects across you get some strange effects with lag or even polling differentiation that causes it to look bad.  For example, in TMN when you are racing other cars and you jump beside another car you see for a split second the other car move through the ground and back up again. They are doing something of a dead-reckoning, but not very well processed.  For a fast-paced game like racing you really need to do more than that (which is one of the problems that I have yet to see a racing game solve correctly).

To this end, I would suggest actually just using the physics networking directly.  Maintain physics objects on both client and server for all players and you'd simply register the client player from the client game and it would send authoritative messages updating changes. What this gives you is what I like to call "physics reckoning".  Similar to dead-reckoning how it moves you at the same speed in the same direction  as of the last update, this rather uses the forces that were last enacted on the object until it receives an update correcting it.  Collisions can be handled unless you want very precise collision management (like bounce off this object).  For a racing game I think the built-in physics would probably be sufficient.  I've actually be considering creating my own physics engine to solve some of the problems with networked physics (time based physics events, so you can insert a physics event in the past and it will update everything accordingly).

So you would essentially leave the game working like the one player game already does, but controlling and creation of non-local players would be managed externally, and after registering your vehicle you'd control it like you already do, and just send a CarPhysicsMessage to update location and physical forces.

[kine]

Hello !

        So after thinking to it a bit, I decide to make a distributed simulation (because I love this concept ) , where each player physics is simulated with the whole track on its machine. Don't even try to make me change my view    (btw a game should contains up to 16 cars at the same time, no less than 32 rockets, 200 bullets, added what I haven't thinked of now ... : oil, mines etc ... )
When two car get proach, both are computed on the computer with the less processor load, and with 3 cars the same etc ...
so this is a full distributed simulation.
I plan to send packets containing the whole physic player information (+speed etc ... ) , so the simulation can be continued on each pc, and full physic reckoning may be ok.

I may keep a server for transiting information, and maybe recreate one dynamically if the first doesn't respond anymore.
At the limit, On old PCs, with this kind of distribution, the physic simulation of the old PC player could easily be done on others more recent ones ... (I'll take a look at it later too....)

Because I have complex messages to send, I plan to use your chat class to send distribution informations and orders (It is the best solution, isn't it ? )   

That's it ! 
I'll keep you informed of my progresses ...

Kine

Kine

[darkfrog]

Sounds pretty good, but you need to use a server to maintain a copy of the physics simulation as well if you want to have any kind of cheat handling.

[kine]

Ok !!

Multiplayer is now quite ok: with 2 cars:
Physic Reckoning works fine...
Game is smooth even with 8 packets/second except wheels that are coded to go back to their original positions, more quick than the network refresh rate so when the opponent keep turning, wheels flickers ... guess I'll have to find an intermediate solution ...

When two cars are distants the opponent car physics are not computed and I gain 10 fps per car not computed ( as my physic simulation is a bit heavy now ( but I'll change the physic engine update rate from 300update/second to 60updates/second with tweaking))

The last networking thing to do is to implement a basic reckoning for far cars, and the solution I think now is to make a very basic reckoning  with only a box the scale of the car, with no gravity no collision, nothing,  with chassis's speeds and positions to compute the next car position approximation ... it isn't very precise, but it may be ok for far cars ...


I'll keep you informed !!! 

Kine

[darkfrog]

That's awesome.  I'd love to see a demo video when you get a chance to put one together.

Great work and I can't wait to play it.

[kine]

Thanks !   

But the game is serverless now, like a p2p one,  and I didn't solve the problem of lagging during excepted (in fact not happening) collision... Anyway the two implicated computers should be wrong at calculating real positions, nor the server... So I may have to find an intermediate solution, the same I should have taken with a server with two client laggy ... I imagine I could keep the information from the less laggy client, supposing he received the more informations ( if for example a third car arrives (oups)  and then ... )

  I'll code my (far) reckoning and leave this like this till I tweak the  physic engine then I'll see :-)


Thanks for JGN my friend   

PS: perhaps I may need your jgn2  P2P classes  in a near future (oups) ( at the minimum to test the two possibilities and decide  )

[darkfrog]

Take a look at the old 1.1 code-base:

http://svn.javagn.org/core/tags/1.1/src/com/captiveimagination/jgn/p2p/