Multiplayer driving game.
Author
I''m writing a multiplayer driving game and currently i have it planned so that there are 33 cars, and 13 players. The players will send the server a byte of data that says their controls like gas and brake, then the server will have to return 3 floats for position, 3 floats for orientation, 3 floats for linear velocity, 3 floats for angular velocity, an integer for speed, and maybe i can mask of a 3 of the last bits in the integer to reprent what gear the car is in, since the car will not be goint 30 some thousand miles an hour.
Thats alot of data to be sending 33 times to 13 people. I''ve also noticed that most multiplayer driving games limit players to around 8 and each with 1 car. My game is goin to be like multiplayer GTA, so there are 13 players but 33 cars that each can choose from (2 can''t have the same though). And that is just for the cars. I''m goin to have to send states for trees and signs that get knocked down, and the characters them self.
Is this possible or should i limit the player count to around 8 and only give each a car, big dissapointment but if its what i have to do, its what i have to do.
Author
3+3+3+3+1 * 4 bytes = 52 bytes //car
3+3+1+1 * 4 bytes = 32 bytes //person
With a 100% static terrain 13 players + 33 cars thats, 416 bytes + 1716 bytes = 2132 bytes per person * 13 people = my server would have to send out 27716 bytes everytime it updated. If i update 20 times a second thats 554320 bytes every second. That seems way too big to me, but i have no idea what size packets other games send. Any comments?
3+3+1+1 * 4 bytes = 32 bytes //person
With a 100% static terrain 13 players + 33 cars thats, 416 bytes + 1716 bytes = 2132 bytes per person * 13 people = my server would have to send out 27716 bytes everytime it updated. If i update 20 times a second thats 554320 bytes every second. That seems way too big to me, but i have no idea what size packets other games send. Any comments?
I dont quite understand what you are saying, but if you are talking about sending which car the other player is using then is surely something that you shouldnt do ...
let me explain, players wont be changing cars while running, they pick one at the beggining of the race and stick to it ..., so you send all clients which car that player will use (and even customizations, like color, and whatever you want), and then just update all those things you said needed to update (which I dont have a clue if that would be too much).
I might be A LOT wrong, but do you need to send ALL the other player data to all the players?, I hope not ... what you can/should do tough, is send only the data of those the player has near ...
About states for trees and signs, I think you would do better sending events (you might want to send them delayed depending of the case) when something happens to trees and signs, since that would probably be a lot less info than sending the state of those all the time (you would assume the old state while you dont get a new one )
let me explain, players wont be changing cars while running, they pick one at the beggining of the race and stick to it ..., so you send all clients which car that player will use (and even customizations, like color, and whatever you want), and then just update all those things you said needed to update (which I dont have a clue if that would be too much).
I might be A LOT wrong, but do you need to send ALL the other player data to all the players?, I hope not ... what you can/should do tough, is send only the data of those the player has near ...
About states for trees and signs, I think you would do better sending events (you might want to send them delayed depending of the case) when something happens to trees and signs, since that would probably be a lot less info than sending the state of those all the time (you would assume the old state while you dont get a new one )
1 char for rotation. 360.0/256.0*X is plenty accurate.
2 chars for velocity. X + 255.0/Y is plenty accurate and gives you 0-256mph with a 1/256 accuracy.
The rest the client should be able to figure out. You don''t need to tell it the car is rotated to fit the gradient of the hill.
For position you could send raw X,Y, and Z coordinates. However you could also use partitioning which may save you a byte or two although it''s a wee bit more complicated.
A byte breaks down into 2 nibbles of four bits each. That gives you a 16x16 grid. The second byte would then break down the previous grid location into another 16x16 grid. And you just keep adding bytes until you get as accurate as you want to be. You won''t necessarily need the same amount of bytes at every location. For instance at 0,0 you''d only need to send one byte since you don''t need to approximate any further. For Z you can do the same. The first 4 bits define the first 16 locations, the next 4 bits break down the previous location into an additional 16 locations. Keep adding bytes until you get as accurate as you want to be.
The number of bytes sent for the Z location will also vary since you may be at position 8 on first grid making it unnecceary to approximate any further. This method also gives you control since you can set how accurate you want to be without being forced to send the same amount of bytes for any location even when 1 or 2 would suffice.
Ben
IcarusIndie.com
KalvinB - (to Jessika) do you accept Jesus as your lord and savior
Jessika - Sure I can accept all forms of payment.
2 chars for velocity. X + 255.0/Y is plenty accurate and gives you 0-256mph with a 1/256 accuracy.
The rest the client should be able to figure out. You don''t need to tell it the car is rotated to fit the gradient of the hill.
For position you could send raw X,Y, and Z coordinates. However you could also use partitioning which may save you a byte or two although it''s a wee bit more complicated.
A byte breaks down into 2 nibbles of four bits each. That gives you a 16x16 grid. The second byte would then break down the previous grid location into another 16x16 grid. And you just keep adding bytes until you get as accurate as you want to be. You won''t necessarily need the same amount of bytes at every location. For instance at 0,0 you''d only need to send one byte since you don''t need to approximate any further. For Z you can do the same. The first 4 bits define the first 16 locations, the next 4 bits break down the previous location into an additional 16 locations. Keep adding bytes until you get as accurate as you want to be.
The number of bytes sent for the Z location will also vary since you may be at position 8 on first grid making it unnecceary to approximate any further. This method also gives you control since you can set how accurate you want to be without being forced to send the same amount of bytes for any location even when 1 or 2 would suffice.
Ben
IcarusIndie.com
KalvinB - (to Jessika) do you accept Jesus as your lord and savior
Jessika - Sure I can accept all forms of payment.
From what i''ve heard you are not supposed to send information every frame =P Most of the stuff should be predictable like acceleration and deceleration, you just need to know the keystrokes etc. The other important thing is of course direction. And if your other clients have the same information they should be able to process it too. The server should just make sure everyone is where they are supposed to be (no cheating etc) and send the other players whats going on, not every last detail 20 times a second =X
Another good piece of advice would be to just send things that *change* to clients immediately, and only send full positional updates once every second or two in case someone is out of sync. For instance, if a car is accelerating at it''s maximum rate, clients can assume it will keep doing that until you say otherwise, and predict its movement themselves, without further network communications. You only need to send out an update if the player controlling the car stops accelerating, or starts braking, for example. Using this strategy for updates should also make your client side player prediction rather less complex to write.
This will save you a whole lot of bandwidth in a GTA style game, where cars either accelerate/turn at maximum speed, or don''t. If you''re implementing analogue controls, the saving won''t be so great, but similar methods still apply.
Most of the other comments that have been made seem helpful too, so consider implementing some of those suggestions in conjunction with this
This will save you a whole lot of bandwidth in a GTA style game, where cars either accelerate/turn at maximum speed, or don''t. If you''re implementing analogue controls, the saving won''t be so great, but similar methods still apply.
Most of the other comments that have been made seem helpful too, so consider implementing some of those suggestions in conjunction with this
Author
What you guys are saying all makes sence, if i was using a simple physics engine, with like a height map for car height. I''m using ode physics library, all of the collsion detection and physics takes place on the server. The clients simply render what they are told too, and send back keystrokes. The players can switch cars mid game. There is 33 cars each player can choose from, the are all sitting in a field. What is the max packet size i can send and how fast from the server to the client and too how many people. Idealy i want to send it to 13 people.
You need to use a header. That tells the recieving end how to interpret the body of the message.
Type 1 for instance would indicate a chat message.
Type 2 would indicate current position and heading
Type 3 would indicate the model of car a client is using.
You then only send whatever message type when needed.
You don''t need to keep sending the car type every time you send a message. You only need to send it when the car type changes.
You have to think of everything in bytes. Your message struct should be something like
int type
int length
char data[1024]
You then fill data one byte at a time based on the type and then set length to the number of bytes in the message. When you go to send it you send 8 (the size of the header) + message.length bytes.
Don''t define your messages with specific variables outside the basic header.
Ben
IcarusIndie.com
KalvinB - (to Jessika) do you accept Jesus as your lord and savior
Jessika - Sure I can accept all forms of payment.
Type 1 for instance would indicate a chat message.
Type 2 would indicate current position and heading
Type 3 would indicate the model of car a client is using.
You then only send whatever message type when needed.
You don''t need to keep sending the car type every time you send a message. You only need to send it when the car type changes.
You have to think of everything in bytes. Your message struct should be something like
int type
int length
char data[1024]
You then fill data one byte at a time based on the type and then set length to the number of bytes in the message. When you go to send it you send 8 (the size of the header) + message.length bytes.
Don''t define your messages with specific variables outside the basic header.
Ben
IcarusIndie.com
KalvinB - (to Jessika) do you accept Jesus as your lord and savior
Jessika - Sure I can accept all forms of payment.
As KalvinB example, just send what is needed.
by the way, if you wont be doing any prediction on the client, do you really have to send all this?:
by the way, if you wont be doing any prediction on the client, do you really have to send all this?:
quote:3 floats for position, 3 floats for orientation, 3 floats for linear velocity, 3 floats for angular velocity, an integer for speed, and maybe i can mask of a 3 of the last bits in the integer to reprent what gear the car is in, since the car will not be goint 30 some thousand miles an hour.(those velocities? ..., perhaps you want to influence the rendering somehow? ....).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
