Hil all,
Here I am again asking about racing games development.
I'm developing a multiplayer race-combat game and have some questions over JGN and physics.
I'm still in early testing fase, but I'd like to know if this aproach is apropriate:
1 - Server running the physics game state in headless mode.
2 - Clients running a physics game state with all the cars loaded (each car is composed of 9 dynamic physics objects)
3 - JGN Syncronizing the state of each dynamic physics node
My goal is having as much as 8 cars simultaneouslly.
I'm afraid there's going to be too much net traffic, but it's the only way I thought I could sync everything, since each car has suspension and I don't want to have a simplistic model for cars, not in 2007.
I've been thinking in running physics only on the server, and syncing only graphics for the now 5 elements per car (chassis and 4 wheels), and command messages, like accelerate, brake, turn, etc. But I think this way the game will be choppy, yes it would, updating every 50 ms only or so. No way…
What would you do in such a cenario?
Best Regards everyone…
My suggestion would be to maintain local, non-gameplay physics, while all major parameters (position, orientation) are maintained by the server. In this way, you can have your clients look at its car move in a realistic way, but save the sync-ing of all the physics state which is what will kill your app.
Other approach can be to do incremental updates, and only send a key-frame in animation and physics. Then in each client, you could apply the correction in a smooth way with interpolation (if this is already done by JGN, then disregard this comment, although I don't think so… no offense to Darkfrog )
Last, if you are not very interested in absolute consistency, you cold do a P2P type of network and allow the net to decide the rest ;).
Good luck.
Many multi-player racing games go for a heavy server and graphical synchronization on the client. This creates a really terrible gaming experience if lag exists (which it always does). You could go the route of simply either having all of those pieces synchronize like you suggested, synchronize the whole car down from the client to the server and have the clients do some handling of processing that information across, or you could even disable complex physics for any cars other than the client's car so the synchronization data is much simpler to handle.
Another possibility would be to create a custom message similar to the PhysicsSynchronizationMessage in JGN, but extend it to process all attributes of the car at once. You could pass the following:
- Whole Car Location
- Whole Car Rotation
- Whole Car Linear Velocity
- Whole Car Rotational Velocity
- Steering Wheel Rotation
- Tire Rotational Velocity
- Suspension Values - compressed value
In actuality you'd just be adding the last three items to the PhysicsSynchronizationMessage that already exists. This would give you a perfect picture of the car in a single message. This way you never have to worry about one message arriving and another not. It should also significantly reduce the communication that has to occur between client and server.
That would be my recommended approach and probably the most efficient and even easiest across the board to implement.
As far as bandwidth if you have a strong enough server you could handle many more than just 8 players.
And just a note on duenez's suggestion of using P2P, I'm very much opposed to P2P unless absolutely necessary. It typically raises more problems than it solves. There's a reason there are very few games that utilize it. Do a search on the JGN forum for a more detailed explanation if you're interested.
Gotcha!
I think I'll do as you suggested: CustomPhysicsMessage and CustomPhysicsController… There are other problems because the 9 Dynamic objects are connected through JOINTs… With assync messages I have no way of syncing with graphics… Making only one sync message for the whole car I can pass the attributes I really need (a few more than you suggested, but not too many) and DISABLE the joints while processing the message. That's what I think is suggested by Irrisor for updating positions and rotations of connected physics objects.
I'll proceed and let everybody know if I find anything interesting.
Thanks.
Post a link when you've got something awesome to show off. 
darkfrog said:
And just a note on duenez's suggestion of using P2P, I'm very much opposed to P2P unless absolutely necessary. It typically raises more problems than it solves. There's a reason there are very few games that utilize it. Do a search on the JGN forum for a more detailed explanation if you're interested.
Well, I was really curious about this comment, since IMHO P2P is getting increasingly better for games, and actually was mentioned several times in a Networked Games class I just took. I went to have a look at the JGN forums but found only 3 posts relating to P2P... Could you please send me a link or post to further illuminate my foggy (not froggy ;)) ignorance?
…I know I posted an elaborate, exhaustive, and overly critical evaluation of P2P somewhere…it was probably in one of the threads here but I can't seem to find it. :o
Anyway, I'll give a brief overview of the problems here and you take me point-to-point (P2P hehe):
1.) Networking issues: The first hurdle you have to deal with that you don't have quite the headache with is the client. The client in a P2P scenario is acting like a server itself rather than being a client anymore. So by definition the client must now be able to receive connections. The most obvious problem here is firewalls, mean ISPs, etc. that will block any port they don't recognize. It's just a big pain in the neck you end up supporting by going that route and right here you just lost certain potential players that no matter what you do they'll never be able to play your game.
2.) Cheating: Yes, we all want to believe that our game is not a candidate for the evil cheaters, but if your game gains any following that is an inevitable thing you have to manage. In a P2P scenario you have to provide validation that a client isn't in some way sending information and altering information they are not supposed to. Yes, this can be managed, but your complexity just shot through the roof because you have to then have clients validating other clients (which increases the work the client has to do) and that is assuming that the client that is doing the validation can be trusted. What about a hack that during validation would say other players are cheating when they aren't? Or perhaps even modifying validation rules in some other way that favors them? Further, how do you determine who should validate who?
3.) Authority: Who's in charge? With a server if there's ever two clients that think two different things the server can make the final decision. In a scenario where both clients are lagged and they see two completely different things on their screen who says which one is correct? Does a third client make that decision? What if there is no third connection? What if that third connection is lagged? What if that third connection is hacked? Do you make a decision to go "halves" on two clients that see things differently? There's a good place to cheat right there. All this logic again increases the work the client has to do vastly more than what the server would have to do to get a better result.
After all is said and done the clients end up taking a much larger burden upon themselves and that ends up in many cases decreasing the game experience for the client rather than helping it. In concept P2P is "cool", but from a realistic perspective I really don't see its viability in the game development world. I'm definitely not above correction though. In reality I began with some really complex ideas of how to do P2P well, but after I started putting it all together I realized that even though I could develop an extremely powerful P2P system, it just wasn't worth the effort since in the end I was getting "as good" functionality to a client/server.
think of all that bandwidth going to waste …
Well Mr. Darkforg, I have to say you have very good points there, but nothing I have not seen before anyway…
Overall, you complain is that the complexity of the client (the game-logic) is higher, and I totally agree, but on the other hand, you really have no server per se. In a sense is like the fusion of the two, which while you could argue is not as maintainable, you have to agree that the overall complexity does not change much.
Now to specific answers: P2P answers…
- This is true, however, this is also true for UDP exchanges, and unless you are arguing that games should not use UDP, then this is a non-issue (at least not an exclusive argument against p2p).
- Cheating is probably the single biggest problem in p2p. While in the client/server model is also an issue, as you pointed out, the server is the one who performs conflict resolution. But also, the server needs to have cheating detection algorithms in it. Now, these cheating detection logic can be built in the clients, and the complexity of the problem has still remained the same. The only thing that needs to be addressed is not how to detect cheating, but how to maintain consistency on a large scale, right?
To achieve this, there are many approaches. One is to have signed communications between clients, whose signature depends on the client program itself (kind of like an md5 sum). In order for a client to get a valid key, it has to accept a authoring process connecting to a key-server (kind of in Kerberos). This server would issue keys to clients only when they accept the probing scan (hash), and require a new key periodically.
Now, you might want to argue that the complexity of this is far superior to the simple client/server model, but this is not necessarily true. For instance, in client/server, you need a centralized location to store the accounts, and need to implement most of the secure transactions that the key-server would have to perform anyway. This is still an active area of research, but there is hope and a lot of progress has been made.
- This is another big issue with p2p. However, like in the case of security and consistency there are already some good solutions to it. For example, assume you already have your key-server running, then you could perform some simple scoring scheme to assigning reliabilities to clients based on history. Also, local changes (like movement, configuration, etc.) can be mediated by moderate clients, while major changes (decisive interactions, death, etc) can only be cleared by a trusted client. This is reminiscent of the DNS model. The score can be computed as an average of the discrepancies with other clients.
Other techniques aim for a self regulated system. Of these I don't know much, so I won't attempt to describe them.
- Finally, the wasted bandwidth is not a problem, since it is a distributed waste, there is no single point of rupture, and certainly is way more scalable than client/server where you really cannot have all people in the same server, and you need several alternate universes (think WoW).
Perhaps my conclusion would be: Although I agree that in reality p2p gaming is still in its infancy, that is not a good reason to stop considering it at all, because then it would never mature. Also, there are techniques readily available to develop decent p2p games with perhaps only a marginal increase in complexity.
Good discussion, though
I still say the complexity is significantly increased in P2P versus Client/Server.
1.) Actually it's significantly more of a problem than UDP since with UDP you typically have a client/server scenario where the client initiates, but in a P2P a client would be initiating with another client. By the client first sending a message to the server that can provide a route back for NAT and other scenarios to know how to route information from a specific external address to a specific internal address. For example, if you have two NAT'd clients on P2P this becomes extremely problematic since neither can reach the other.
2.) That solution is based on the premise of a man-in-the-middle possibility, but what about hacked clients? Particularly in Java this is problematic since there is no way to truly keep people from decompiling your application and potentially changing it. The complexity is still significantly higher because the decision has to be made who validates who. This decision is already made for you in a Client/Server scenario. A client cannot validate themselves so either you must do a scenario where all clients validate every client (which can add a lot of CPU validation effort to every client) or you have to designate a client to validate another client. How do you decide that? How do you determine that their ruling is fair? If that person disconnects how do you re-assign someone?
3.) See #2. Either way this drastically increases the complication of P2P.
4.) Bandwidth issues are probably the least of your concerns in P2P I agree. 
Although I agree that in reality p2p gaming is still in its infancy, that is not a good reason to stop considering it at all, because then it would never mature. Also, there are techniques readily available to develop decent p2p games with perhaps only a marginal increase in complexity.
It's not at all because of the problem of P2P being in its infancy that I don't agree in it being used. It's more conceptually I think it's a bad idea that should not be pursued. I think the gains (again conceptually) can never exceed the problems that are incurred from usage.
This definitely was a good discussion… for the sake of not making of this an epic battle, I will declare you a winner…
Point 1 was really the deciding fact: You are right!, NATs can and will be a mess in p2p.
Regarding 2 and 3, AFAIK, authentication can guard you against hacked clients. There is research going on, and I expect good results (and elegant ones if you don't like current ones) to arise.
I always like being a winner.
Actually, as far as security goes I've done extensive research on this myself. You might say I'm an authority in that area. I've done a lot of security consulting in the past and got my CEH to that end. I'm more explicitly a programmer these days though.
Potential for hackability (yes, that's my word) is the primary reason I never considered going any further with P2P.
Suppose you have some giant universe, wouldnt it be nice for the clients to distribute the universe data amongst themselves freeing up the server bandwidth
The standard way to handle this, (in client/server) would be to have several servers, each one with one piece of the universe, and then, when you move among zones, you really move along servers as well… At least that is the way WoW does it.
these peiople that just stand around in games chatting - they are prime servers to distribute the world
I'm actually developing a layer on top of JGN to provide this sort of functionality for a distributed network of servers and auto-zoning and shared balancing.
theprism said:
Suppose you have some giant universe, wouldnt it be nice for the clients to distribute the universe data amongst themselves freeing up the server bandwidth
That's the really cool idea that makes everyone drool over the idea of P2P but once you get into the grunt work of implementing it is when most people turn away saying it's just not worth it.
In concept I think it would be awesome to have a P2P MMO game where there is no server, but I cannot find a practical way of making it happen. I personally believe it's a limitation of the concept and not limited understanding. I just don't think it can ever make it there which is unfortunate.
I was actually thinking that the chunk of data representing part of the world has a check sum. the client downloads the chunck from another client and then veryfies the integrity from the servers checksum…
For data downloads P2P isn't bad, but if you intend to implement it for a game it seems a little overkill to implement P2P for just file downloads if you're using Client/Server for everything else. However, one benefit would be in-game downloading shouldn't have much impact on the server's bandwidth if it's distributed like that.
Couldn't resist to chime in… I noticed WoW has a BitTorrent client running in a background thread for patches. IMO the best usage for p2p in networked games today. Also, they seem to be the only ones so far to use that model.
That's really interesting…I didn't know that. I guess the same concept could be utilized in a game developed with JGN. I wrote P2P support in JGN 1.x but never added it to JGN 2. If that's something someone is interested in using feel free to port the code to the new version and I'll add it to JGN.