Force of Fire

Hey guys, as all of you that watch the forums know, I’m pretty new to the jME community, but I set a goal of writing a first-person shooter in jME using the new physics engine and I’m making some serious progress.  For your viewing pleasure see the following screenshots taken in game:



http://www.pyramex.com/ff/screenshot1.png

http://www.pyramex.com/ff/screenshot2.png

http://www.pyramex.com/ff/screenshot3.png

http://www.pyramex.com/ff/screenshot4.png



I still have several things left to do before the game is released:


  • Finish the HUD
  • Enable mouse-look (having some problems with looking up and down because of the tie to the physics object)
  • Sound
  • Multiplayer support
  • GUI support
  • Auto-Update features
  • Installation and Setup utility



    I will be posting another update when there is more to see and hopefully something to hear. :wink:



    Thanks,



    darkfrog

Hey, looks interesting!



Have you thought on maybe making it singleplayer? Keeping a physics world in sync over the network is a real pain in the butt :slight_smile:

Yeah, looks good!



I don't think that physics does make it harder to sync. I'm making a game with physics and multiplayer, too.

This does not mean it's easy to make an real time multiplayer game . . .  :expressionless:

Synchronizing the physics should just be a matter of the server telling the spatials' where they should be on the map and what forces should currently be applied to them, correct?



The reason I am not initially making this a single-player is because the AI component is something I have not taken the time to learn yet.  I definitely want to do that in the future, but this is my first game and I'm trying to keep it pretty simple (although multiplayer may be the most difficult aspect).



Irrisor, are you using a specific API for your multiplayer aspect or did you create some scheme of your own?  I would be very interested in collaborating with you on this as this is somewhat of a concern for me.  If you haven't been using a specific API then perhaps it would be beneficial for us to create one for the jME project?





BTW, I now have cool exploding sounds when the bazooka shots explode. :slight_smile:



darkfrog

I'm using my own library for the mutiplayer stuff. It's a general persistency-, multi-user- and syncronization-library which I do adopt for real-time games. It's nothing that could be used by other people at this stage of development, as it's pretty complex (and is probably exaggerated for games).

If you still want to have a look, PM me.

Would it be a good idea to just do all the physics on ODE on the server and then just send updates to the client telling the graphical objects to synchronize to it or is it more a situation that each character needs to send information of how it's interacting with the scene and then the server just relays that information to connected clients?



Thanks,



darkfrog

That's the problem I refered to – if you run all the physics on the server, I think there's a big risk everything will look very jerky and unresponsive for the client. And if you let the clients do the physics on their own, things will get hairy as you need to make up some sort of clever system to synchronize the clients with each other. Example given: player1 think he/she just collided with player2, and thus makes a collision response and everything, and then gets corrected by the server – that will look very weird :slight_smile:



(I think – I've never taken any of this outside the planning-stage myself :))



But it's definately possible – many games have managed to do this; Half-Life 2 and Battlefield 2 to name a few…

The question is HOW do they do this?  Are they doing physics on the server or leaving the clients to deal with physics and the server just synchronizes them…or is it something in-between?



The big problem with the server just taking information and passing it on to other clients is the potential for someone to write a hack on top of the game that can just pass arbitrary information about what they WANT to do instead of what the physics engine says they CAN do.



I've got a lot of experience writing Client-Server models, but never where synchronization is so important…this is becoming a big concern for me as I am trying to decide how to implement the multiplayer architecture.



Thanks,



darkfrog

from my own experiences im pretty sure HL2 does all the physics calculations client side, because you can change the amount of realism in the physics so it scales better to lower spec machines. ive also played it across a LAN, and the obects are in different positions for each user. once the objects go out of sight though i think they are re-synced and the positions updated so that next time you see them the are in the same position as the other players.



you could easily write a phd thesis on this, its so complicated!

Interesting idea…



I have been considering the idea of the server not having any physics whatsoever and client synchronization would be based on client data.  The typical flaw with this is that a rogue client can tell the server things that aren't true and get away with it if the server doesn't know how to catch these violations.  However, what I'm considering is a situation like:



This example has 4 clients

Client1> This box1 should be at this local translation and this local rotation

Server> Client2, Client3, Client4: Hey, where should box1 be?

** each client would tell where it thinks box1 should be **

** server then takes that information as sort of a vote and tells the clients that are out of sync where box1 should be **



This would happen when an object comes into a certain range.



When a collision occurs the client would simply send collision information to the server and it would pass that information out to the other clients.  Essentially the server would just act as a delegator of information without having any specific knowledge of the map they are on.  I would think this would increase bandwidth performance as well as reduce the possibility of the game being compromised.  For the actual first-person character physics information would be passed consistently telling what it was doing and location and rotation information that would be parsed by the server and the server could also verify with the other clients that a client isn't lying about where it should be.



Any thoughts on this concept?  Since I don't know exactly how most games work I'm just theorizing on best practice.



darkfrog

Hy, i just want to point to the network-forum at GameDev.net. You will find good information in the faq (which seems to be not available today?).



http://www.gamedev.net/community/forums/forum.asp?forum_id=15

Thanks, I'll definitely take a look at it.



darkfrog

Okay, after reading all that information and visiting LOTS of links I found a very useful document on how the Unreal Networking Architecture is designed:



http://unreal.epicgames.com/Network.htm



I am using this is a basis for developing a networking API.  This API (currently called ODENetworking) deals in UDP and should be very simply integrated into jME-Physics games by instantiating the ODENetworkingClient and adding the ODE Bodies from your dynamic physics objects.  This API will hopefully function as a simple means to communicate synchronization information for the authoritative server to the clients also running physics.  This should keep the game running smooth but effective.  I am intending to release this as an open-source project if I ever complete it. :slight_smile:



There will initially be a few things missing such as "relevent object" information…currently it will show all objects and send updates to the client based on their priority (which is defined in the map xml file that builds the ODE map and hopefully will serve the same function on the client for my game) in datagrams and just try to synchronize information as it changes.  Further, any collisions would be explicitly passed down to the server with a higher priority, the next would be character positions, followed by projectiles, and everything else after that.  Obviously this could be modified in the XML, but that is the current implementation plan for my tests.



When I have something that functions better I will post more information.  If anyone has any constructive criticism of my plan please feel free to say it. :slight_smile:



darkfrog