You can read up about the company at www.cerebrumsoftware.com, and read up on the game at http://www.cerebrumsoftware.com/honeypatrol/index.html
If you''re itnerested as joining as an MP coder, or just a regular coder, send out an email to the group at ceresoft@cerebrumsoftware.com
Thanks!
ByteMe95::~ByteMe95()
Cerebrum Software
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Multiplayer HELP!! Can't figure it out
Author
Hello everyone. Me and my team are in serious need of some Multiplayer help.
Here''s the deal:
We''re creating a basic 2d game with multilpayer functionality mostly for experience purposes. Well, the game is very functional right now and I''ve been TRYING to do the multiplayer aspect for a while but i just cant get it to work right, and by that i mean I can''t get events synched correctly on both sides.
Basically, ni this game tehre are targets, and 2 players can play together online to hit the targets, and attempt to get the highest scores.
Right now, I got the multiplayer connection setup down straight, I can and do send messages back and forth, but i still cant get it synched. I mean, this problem is obvious and ''m sure everyone doing MP has encoutnered it the first time they''ve done it. I just cant get over LAG. If player A shoots at time t, player B wont see that shot till time t+lag, and so it''ll be off and will probably miss an enemy on one screen and hit it on another.
We''re using DX for the whole project basically.
Any help would be appreciated.
If you''re even interested in joining the team, please feel free to contact us, we''re always looking for new coders
You can read up about the company at www.cerebrumsoftware.com, and read up on the game at http://www.cerebrumsoftware.com/honeypatrol/index.html
If you''re itnerested as joining as an MP coder, or just a regular coder, send out an email to the group at ceresoft@cerebrumsoftware.com
Thanks!
ByteMe95::~ByteMe95()
Cerebrum Software
You can read up about the company at www.cerebrumsoftware.com, and read up on the game at http://www.cerebrumsoftware.com/honeypatrol/index.html
If you''re itnerested as joining as an MP coder, or just a regular coder, send out an email to the group at ceresoft@cerebrumsoftware.com
Thanks!
ByteMe95::~ByteMe95()
Cerebrum Software
Perhaps you''re trying to send too much information about the game state between the players?
It might just be flooding the connection and thus producing lag?
I''m not sure what data you''re sending exactly...
Also you can use "Cubic Splines" (I think thats what they''re called) to adjust for lag... or some other similar algorithim - basically you just do some calculating on both ends to adjust for the time it took to get the message from the other connection.
- This is all theory of course, I''ve never programmed it before
It might just be flooding the connection and thus producing lag?
I''m not sure what data you''re sending exactly...
Also you can use "Cubic Splines" (I think thats what they''re called) to adjust for lag... or some other similar algorithim - basically you just do some calculating on both ends to adjust for the time it took to get the message from the other connection.
- This is all theory of course, I''ve never programmed it before
Author
No, it''s definately not how much data I''m sending.
I hardly send a lot. And even if i were to send out 1 byte, there would still be lag time to get from user A to user B, there''s always lag time.
So if user A shoot a bullet at say 3:00 and just say for arguments sake user B recieves the shot message at 3:01, then the bullet on A''s screen will have already advanced by bullet_velocity*lagtime when B just got the message and shoots out a bullet from A''s location. so everything is off
I tried calculating the lag time but that was just annoying and even when i almost did it right it wasn''t good enough because i would just offset the bullet when B got the message by lag_time*velocity, so the bullet would seem to appear quite a few pixels away from user A, which is no good.
Cubic splines wouldn''t help here either i dont think because the bullets always move in a straight line. The biggest problem i have is synchronization.
ByteMe95::~ByteMe95()
Cerebrum Software
I hardly send a lot. And even if i were to send out 1 byte, there would still be lag time to get from user A to user B, there''s always lag time.
So if user A shoot a bullet at say 3:00 and just say for arguments sake user B recieves the shot message at 3:01, then the bullet on A''s screen will have already advanced by bullet_velocity*lagtime when B just got the message and shoots out a bullet from A''s location. so everything is off
I tried calculating the lag time but that was just annoying and even when i almost did it right it wasn''t good enough because i would just offset the bullet when B got the message by lag_time*velocity, so the bullet would seem to appear quite a few pixels away from user A, which is no good.
Cubic splines wouldn''t help here either i dont think because the bullets always move in a straight line. The biggest problem i have is synchronization.
ByteMe95::~ByteMe95()
Cerebrum Software
Not sure if this will help, but I''ll give it a go anyways:
-Have you tried ''time-stamping''?? In essence, you would first have to query the ''time'' of the server at connection, and then adjust the client ''clock'' to reflect that time. Then, this is how I would imagine the ''event'' of firing a bullet would go.
Shooter = Client who is firing
Server = Server (obviously)
Client = all other clients who didn''t fire
1. Shooter fires. Sends this (along w/ time) to Server. His computer ''simulates'' how the bullet should travel until Server has gotten back to him.
2. Server recieves ''fire notification.'' Server validates this (checks to see that he really CAN fire), then sends the shot, location of shot, and time of shot to all clients (including shooter).
3. Each client recieves this, and creates bullet.
4. Place bullet on it''s ''expected'' location based on how long along the time-stamp happened.
-Shooter recieves notification from Server, and checks to see where the bullet is, in relationship to where it SHOULD be (remember, server has final decision). Adjusts as necessary.
5. Client(s)/Shooter, send back location of bullet (with timestamp).. to the Server
6. Server validates locations (tells clients to move the bullet to here, etc. if it is off course)
7. Repeat steps 4-6 until bullet hits something (or fades/goes outside of world, etc)
8. Upon this, Server is the one to decide when it hit something. It sends this notification to all of the Clients, and they represent it to the user (explosion, etc.)
This system is called Client Prediction. Its a fairly in-depth topic and can really make-or-break a multi-player game (at least until the internet becomes more reliable)
Reducing LAG will help aleviate some synchronization issues, but this is a problem you inevetiably are going to have to face sooner or later.
I hope this has helped in some way?!
-mihkael
P.S. This is assuming you are using a Client/Server relationship.
-Have you tried ''time-stamping''?? In essence, you would first have to query the ''time'' of the server at connection, and then adjust the client ''clock'' to reflect that time. Then, this is how I would imagine the ''event'' of firing a bullet would go.
Shooter = Client who is firing
Server = Server (obviously)
Client = all other clients who didn''t fire
1. Shooter fires. Sends this (along w/ time) to Server. His computer ''simulates'' how the bullet should travel until Server has gotten back to him.
2. Server recieves ''fire notification.'' Server validates this (checks to see that he really CAN fire), then sends the shot, location of shot, and time of shot to all clients (including shooter).
3. Each client recieves this, and creates bullet.
4. Place bullet on it''s ''expected'' location based on how long along the time-stamp happened.
-Shooter recieves notification from Server, and checks to see where the bullet is, in relationship to where it SHOULD be (remember, server has final decision). Adjusts as necessary.
5. Client(s)/Shooter, send back location of bullet (with timestamp).. to the Server
6. Server validates locations (tells clients to move the bullet to here, etc. if it is off course)
7. Repeat steps 4-6 until bullet hits something (or fades/goes outside of world, etc)
8. Upon this, Server is the one to decide when it hit something. It sends this notification to all of the Clients, and they represent it to the user (explosion, etc.)
This system is called Client Prediction. Its a fairly in-depth topic and can really make-or-break a multi-player game (at least until the internet becomes more reliable)
Reducing LAG will help aleviate some synchronization issues, but this is a problem you inevetiably are going to have to face sooner or later.
I hope this has helped in some way?!
-mihkael
P.S. This is assuming you are using a Client/Server relationship.
Author
hehe
thanks for the help, i appreciate it, but unfortunately i''m using the client/client setup since this game only allows 2 players.
what about offsetting the bullet by the measured lag time(if measurable, maybe smoe pings and stuff or try synching a common clock), so whatever the lag is u offset the bullet location by that much time?
I mean, i know it''s possible, but it is normal? Does anyone use this method in any mp games at all? I have no idea, this is my first MP coding experience
ByteMe95::~ByteMe95()
Cerebrum Software
thanks for the help, i appreciate it, but unfortunately i''m using the client/client setup since this game only allows 2 players.
what about offsetting the bullet by the measured lag time(if measurable, maybe smoe pings and stuff or try synching a common clock), so whatever the lag is u offset the bullet location by that much time?
I mean, i know it''s possible, but it is normal? Does anyone use this method in any mp games at all? I have no idea, this is my first MP coding experience
ByteMe95::~ByteMe95()
Cerebrum Software
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
