Hey guys,
I finished my game so far so it's time to think about the implementation of the network code.
I know that there're some advanced RakNet-users around in these forums so I just post my ideas about my
network-concept and ask you if this is a good one.
About the game: The game is multiplayer miniature-golf game with up to 4 players. There're also
several other dynamic objects depending on the course. There currently is no limitaton of these
objects, but I think 100 will hardly be exceeded.
That was the main-concept of the game, so lets go on to the network part
I thought about to use one player's pc for server-stuff and the others are just clients.
The server should have the following tasks:
- does all the calculation of the physics on its own (NewtonGameDynamics)
- sends every client the new values like position, torque, velocity, etc...
- does the rendering for its own (Irrlicht)
The clients tasks:
- receives the current values for every dynamic object on the scene
- renders the scene for its own (Irrlicht)
So, now the question is "Will this concept work for my purposes?"
My idea with this split of tasks was I won't get any sync-problems. But was is with stuttering?
Feel free to post your opinion...if you need more infos you'll get them
thx in advance, masterhawk
Network concept with RakNet
-
- Posts: 299
- Joined: Mon Nov 27, 2006 6:52 pm
- Location: GERMANY
- Contact:
Physics are fun 'cuz if you have a good simulator, you can predict what will happen.
What I mean is on the client cpu, you should try and predict what'll happen, move stuff as if it had happened then on confirmation from cpu, update to real position if yours are wrong. Considering it's golf, that should never happen ;P
What I mean is on the client cpu, you should try and predict what'll happen, move stuff as if it had happened then on confirmation from cpu, update to real position if yours are wrong. Considering it's golf, that should never happen ;P
-
- Posts: 299
- Joined: Mon Nov 27, 2006 6:52 pm
- Location: GERMANY
- Contact:
first of all, thx for your reply.
I also thought about this method, but I guess that the values, calculated by every cpu, will be different. Currently the program is single threaded so the speed of the physics-calculation depends on the cpu. Even on a multithreaded system I would be suprised if the values were the same on each cpu at the same time. So I'd have to transmit the whole values again.
Your concept would be reduced to mine, then
I also thought about this method, but I guess that the values, calculated by every cpu, will be different. Currently the program is single threaded so the speed of the physics-calculation depends on the cpu. Even on a multithreaded system I would be suprised if the values were the same on each cpu at the same time. So I'd have to transmit the whole values again.
Your concept would be reduced to mine, then
No, it's called lockstep simulation
What it means is you decide what the rules are and make sure they are the same for all. Let's say calculate physics ever X ms, with no random. If one misses it's update, have it update as if he did on time but request comparative data to make sure it's the same as other. Any good physic engine will have a way to lockstep. Good luck
What it means is you decide what the rules are and make sure they are the same for all. Let's say calculate physics ever X ms, with no random. If one misses it's update, have it update as if he did on time but request comparative data to make sure it's the same as other. Any good physic engine will have a way to lockstep. Good luck
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
I agree with Dorth. For this application, I'd use a fixed size frame time[*] and let each client do the physics locally. You'll cut your bandwidth dramatically, and won't be nearly as vulnerable to latency or loss. You could even use (gasp!) TCP for your comms if you do it this way.
[*] E.g. 33ms ~= 30fps. If a client starts lagging badly behind that, then skip rendering frames.
[*] E.g. 33ms ~= 30fps. If a client starts lagging badly behind that, then skip rendering frames.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
-
- Posts: 299
- Joined: Mon Nov 27, 2006 6:52 pm
- Location: GERMANY
- Contact: