New to Multiplayer Programming
Author
Hi, I wasn't programming for a while but an idea came to my mind and I am willing to do something soldat-like(at least in the manner of networking soldat gives a good idea)
Anyway I dont want to go on programming without a plan in my head and I dont know how to manage networking.I guess I am going to write a "console server" and treat the local client as another client.Clients will move their player and send new locations to server and server will send the new location to all of the clients.
But there are few questions I have to ask about bullets;
1)Should clients move the bullets? If not should clients move their OWN bullets?Or should they just send "created" message to server and wait the new locations.
2)I am going to use UDP,what if "created" message wont be delivered? and how high is the chance of this(I never programmed this kind of game with udp)
3)How would I make the bullets "special" to players.Because I want to know who killed whom.Should there be an ID variable in bullet class.
4)Should bullets have ID for theirselves too? Because clients wont make "checks" and if a bullet hits the wall server will send the delete message to clients but how can this process be more precise?
Thank you, I hope these questions dont sound silly =)
The way of thinking is that:
* You rather want to send/receive events than states between server/client, and
* Each object in the world should have its own unique ID, and
* Server always makes the critical decisions!
Example, firing a bullet:
1) Client-side: User clicks on mousebutton to fire a bullet
2) Client-side: Mouse event handler recons a new event (button clicked), client creates its own bullet object, fires away, and sends the event 'pistol fired' to the server.
3) Server-side: (~200ms later) Server receives 'pistol fired' event, creates its own bullet object (with position, direction, velocity..) and fires away.
Based on the 200ms transfer delay, server compensates by updating its own bullet position to +200ms in time, i.e where the clients bullet would be at this time (don't forget to do collision detection here as well).
6) Client-side & Server-side: Server and client simultaneously updates the bullet position each timestep. Client-side does not perform collision detection, but rather redraws the bullet at every new position. Server-side performs collision detection but does no drawing.
7) Server-side: Upon server detecting a collision with another object in the world, server calculates damage on impact object, etc, and sends all this information (damage, which target was hit, etc) to the client via an 'impact!' event, and finally removes its own bullet object
8) Client-side: (~200 ms later) Client receives 'impact!' event and immediately removes its own bullet object. Based on the data in the impact object (what was hit, damage inflicted..) the client shows some pretty explosions, splatter or death-sequence-stuff for the object that was hit.
200ms means the connection is kind of "slow", but you get the idea.
Edit: This got a bit pseudo-codish, please correct me if I'm wrong.
Edit2:
About UDP.. Not only is there a risk of data not arriving at all, data may also arrive out-of-order or arrive multiple times (duplicate). If this is a not a problem for the kind of data your sending, then UDP sounds like a good choice. However if you need one or more of these issues solved, you will have to use another protocol. RUDP is a light-weight protocol which, if I remember correctly, solves all issues except 'out-of-order' (quote needed). If you need something that takes care of all three, have a look at TCP/IP.
* You rather want to send/receive events than states between server/client, and
* Each object in the world should have its own unique ID, and
* Server always makes the critical decisions!
Example, firing a bullet:
1) Client-side: User clicks on mousebutton to fire a bullet
2) Client-side: Mouse event handler recons a new event (button clicked), client creates its own bullet object, fires away, and sends the event 'pistol fired' to the server.
3) Server-side: (~200ms later) Server receives 'pistol fired' event, creates its own bullet object (with position, direction, velocity..) and fires away.
Based on the 200ms transfer delay, server compensates by updating its own bullet position to +200ms in time, i.e where the clients bullet would be at this time (don't forget to do collision detection here as well).
6) Client-side & Server-side: Server and client simultaneously updates the bullet position each timestep. Client-side does not perform collision detection, but rather redraws the bullet at every new position. Server-side performs collision detection but does no drawing.
7) Server-side: Upon server detecting a collision with another object in the world, server calculates damage on impact object, etc, and sends all this information (damage, which target was hit, etc) to the client via an 'impact!' event, and finally removes its own bullet object
8) Client-side: (~200 ms later) Client receives 'impact!' event and immediately removes its own bullet object. Based on the data in the impact object (what was hit, damage inflicted..) the client shows some pretty explosions, splatter or death-sequence-stuff for the object that was hit.
200ms means the connection is kind of "slow", but you get the idea.
Edit: This got a bit pseudo-codish, please correct me if I'm wrong.
Edit2:
About UDP.. Not only is there a risk of data not arriving at all, data may also arrive out-of-order or arrive multiple times (duplicate). If this is a not a problem for the kind of data your sending, then UDP sounds like a good choice. However if you need one or more of these issues solved, you will have to use another protocol. RUDP is a light-weight protocol which, if I remember correctly, solves all issues except 'out-of-order' (quote needed). If you need something that takes care of all three, have a look at TCP/IP.
Author
Thank you for your answer,
I thought a little bit and I decided how to keep the track of the items,players etc. (with some kind of database which is actually a vector)
But how can I be sure that two items dont have the same ID? should I use a large random number ?
I mean who gives the ID's at all.Does Client create a bullet with a specific ID or should server be responsible for giving ID's and sending them back to clients?
If client gives ID's than 2 client can fire at the same time(because of the little lag) and they can give the same ID which is bad.
I thought a little bit and I decided how to keep the track of the items,players etc. (with some kind of database which is actually a vector)
But how can I be sure that two items dont have the same ID? should I use a large random number ?
I mean who gives the ID's at all.Does Client create a bullet with a specific ID or should server be responsible for giving ID's and sending them back to clients?
If client gives ID's than 2 client can fire at the same time(because of the little lag) and they can give the same ID which is bad.
In my opinion, the server should be responsible for managing the objects in the world, including bullets. The client objects are just replicas or visualisations of what's going on in the server world.
However, stuff like particle effects, animations, etc. that exist in the clients graphical world, which doesn't have a counterpart on the server, will also need their own unique IDs. The way to do it is to let the server and client manage their own separate objects (separate ID series), but keep a reference to the server object ID for any client object that "represents" a server object.
In the case with the bullet: After a bullet is fired the client doesn't need to know the server ID of the bullet. What is more interesting is the server ID of the object which is hit (delivered by the impact event). Given the server ID for the object that is hit, the respective client object can be found by a lookup search.
About unique IDs: One solution is to using the objects' vector indices as IDs. Large number or a simple string hashtable is also an option. If server manages its own objects you don't have to worry about duplicate server object IDs among clients.
However, stuff like particle effects, animations, etc. that exist in the clients graphical world, which doesn't have a counterpart on the server, will also need their own unique IDs. The way to do it is to let the server and client manage their own separate objects (separate ID series), but keep a reference to the server object ID for any client object that "represents" a server object.
In the case with the bullet: After a bullet is fired the client doesn't need to know the server ID of the bullet. What is more interesting is the server ID of the object which is hit (delivered by the impact event). Given the server ID for the object that is hit, the respective client object can be found by a lookup search.
About unique IDs: One solution is to using the objects' vector indices as IDs. Large number or a simple string hashtable is also an option. If server manages its own objects you don't have to worry about duplicate server object IDs among clients.
I wouldn't recommend the model described by trasseltass. If you want to keep your networking simple you should let go of the idea of an authoritative server. If you want to do it right your should implement proper prediction/interpolation as described in this and this document.
As far as bullets goes - there's no need to create bullet objects and track velocities for hitscan weapons, only slow projectiles like rockets and the like.
As far as bullets goes - there's no need to create bullet objects and track velocities for hitscan weapons, only slow projectiles like rockets and the like.
Quote:Original post by fenghus
I wouldn't recommend the model described by trasseltass. If you want to keep your networking simple you should let go of the idea of an authoritative server. If you want to do it right your should implement proper prediction/interpolation as described in this and this document.
As far as bullets goes - there's no need to create bullet objects and track velocities for hitscan weapons, only slow projectiles like rockets and the like.
True, it is more suited for slow projectiles. I haven't played "Soldat" so I took a shot, imagined bullets were slowed down. ;) Nice links btw.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
