Also the orginal poster mentioned a physics engine. Trying synchornizing a distrubitued physical simulation without a centralized authrotive server, is a much more difficult task, as who has authority?

Mostly it will come down to intelligent caching and capturing and proprogating only the minimal needed events to keep the collison system in sync.

-ddn

Thanks for all of the feedback guys! At this point just to get it done I''ll do the collision detection for the terrain client side. Later the server will do checks to make sure it is in fact valid (hopefully before public release..)

Again, thanks for the feedback!


-Nate S.

I find it rather odd that you''d be willing to spend $69,000 in addition to royalties at a rate of 4-6% plus $25,000 in support for such a robust network model, yet be incapable of designing an appropriate collision detection model for your game.

In any case, I would recommended you take a look at the havok or havok 2 engine for physics simulation, they are both of very high quality. Call up quazal (514)-395-4646 and they should be able to help you out with making a decision that will integrate well with quazal.

Cheers.

Physics in a MMO with server side? To put the answer simply, no.
Why?
Well MMO worlds are huge with a lot of players and to have the kind of data through put from the server to the client to produce good feedback your bandwidth costs will be sky high. You will also need massive numbers of servers to maintain decent ping times. Think about it for a second. A PC multiplayer game with physics needs relativly small numbers of players and very good ping and also quite a high data bandwidth to maintain something believeable. Are you prepared to have the servers scaled up by the number of extra players?

Basically forget the idea of having server side physics.
For a client, even then you may be asking too much since it is easy for 80-100 people to get together in one close area this owuld normally take a lot of physics processing, especially if you have physics in your world objects as well.
Your best bet is use a physics simulation or yourself with other world objects, such as chains. It won''t matter if one client view of the chain is different with another client view because it is a MMO game.

Lastly I would suggest you take a second look at using Quazal. They are too expensive for what they provide. Sort yourself out with a Replicanet license from www.replicanet.com
They are much more affordable and you get the source code!

@Raymondo - We''re creating a shareware game, thus Quazal is free as long as we don''t make money. Also, the only money we''ve put into this project is for buying a few servers.

The only reason I wouldn''t look at www.replicanet.com is because they are do not provide a license for shareware projects such as mine. If they change their license system I''m sure they would get more developers interested =P


-Nate S.

Odd because when I looked a week ago Replicanet has a free license?
(Checked: Yup, free ReplicaNet license for non-commercial use.)

Quote directly from their website >
"..Use of ReplicaNet Freeware is restricted to personal use and non-commercial applications only. Projects that are for shareware, public shows and exhibitions, use in schools and classrooms or educational courses is considered to be commercial use.."

Take a look at the game Second Life. It uses the Havok physics engine. I''m pretty sure they run it on the backend as well as the client. Otherwise they would never know the true positions of the dynamic elements as they start interacting.

Anyways, it can be done, and proably done well, given todays machines, technology, and bandwidth.

Good Luck

-ddn

There are not 2000 ways of doing this. When creating an "MMOG", you want things to be reliable and secure. If collision detection was to be done on the client side, it would be very easy to "hack" around and go through walls and/or entities.

Its simple, the server runs the game. The server runs the True game, the clients only display an approximation of the close environment. The server has to know everything thats going on. Now, some "MMORPG" games can simplify this process a bit. Collision against terrain is fairly fast, most of your 3D "MMORPG" games don''t have environments nearly as complicated and dynamic as an FPS game. They will have terrain, often tile based geometry or buildings loaded directly as models, which can be easily eliminated as a whole, when it comes to potential colliders. Some of these games might also rely on hacks like considering that when an object doesn''t move, it doesn''t need to be checked for collision detection.

Now, many of you might not understand this. "How can the server send the collision detection info to the clients fast enough?!? Don''t you know what lag is !?!?!". This is not an issue, because the clients perform what is called client prediction. The client simply run collision detection for the objects that are close to them, they predict what will happen. The server sends updates from time to time, which sometimes correct what the client had wrongly predicted. In some rare cases, where there is alot of lag, this will result in prediction errors, but its impossible to do without it. If the clients ran collision detection, everyone would see the events differently and the game would be badly synchronized due to the lag and packet loss.

The server *cannot* rely on the clients to do its job. Collision detection isn''t that much expensive calculations... Quake 3 runs collision detection against 3D worlds on the server side and you can run a dedicated Quake 3 server with several players in the game on a 486 (yes, believe me, you can).

---

Looking for a serious game project?
www.xgameproject.com

quote:

---

Original post by Max_Payne
There are not 2000 ways of doing this. When creating an "MMOG", you want things to be reliable and secure. If collision detection was to be done on the client side, it would be very easy to "hack" around and go through walls and/or entities.

---

Everquest does collision on the client side.