[ENet-discuss] Object unique ID's

Martin Sherburn spacedude at konggame.co.uk
Sun Mar 16 12:38:22 PDT 2008


Hi Ruud,

I think this is beyond the scope of what enet is for. But it's really 
not that hard to implement some ID tracking system yourself once you get 
your head around it.

As your are implementing a client/server system, the server should be in 
charge of creating objects in the game (e.g. cars) and telling all the 
clients about it. So here is what you can do:

1) Server creates car and assigns it a unique ID
2) Server tells clients about this new car that was created and sends 
the ID it assigned to it
3) All clients create a copy of the car and assign it the ID the server gave

So the basic rule is, only the server should generate IDs. The clients 
will always receive the ID from the server.

In the case where the client may want to spawn a new car by joining the 
game. Then the client should send a request to the server to create the 
car (without generating an ID for it). If the server accepts the 
request, it will create a car and generate and ID for it and tell all 
the clients about it including the one that sent the request in the 
first place.

Martin.

Ruud van Gaal wrote:
> Hi,
>
> I'm re-designing part of my multiplayer game to improve object updates.
> Before using ENet, I had a UDP connection scheme where every client would
> get sent a unique ID from the server. The server was for example ID 70, the
> first connected client got 71 etc. This way, on all connected computers you
> could see who was who and you could simply send updates for ID <x>.
>
> With ENet that changed a bit; every client that connects is just stored in
> the next free 'location', if I read the source correclty.
>
> Here's the problem: I'm updating several cars in a multiplayer game, where 1
> client may potentially supply more than 1 car. So I need a system where I
> can put a stamp on each car, so everyone knows which is which.
> The solution I came up with is a global network object ID generator; a
> simple:
>
> static int id;
> void GetUniqueID()
> {
>   return id++;
> }
>
> For every object, perhaps even client connections, but also object in-game
> that needs updates, I would store the ID. After that I can just send packets
> like:
> packet[0]=ID_CAR_UPDATE;
> packet[1]=car.GetNetworkID();
> packet[2]=velocity...
>
> And every client will be able to find the right car for which the update is
> for.
> I'd like to use a similar function for the client connections; since each
> client in the multiplayer game displays all cars, every client knows about
> all other clients and which car belongs to which client. A scheme where each
> client has a unique network ID, and more importantly, all their ID's are the
> same across the entire game (so if clientID on computer 1 is 0x100, the
> knowledge about computer 1 on computer 3 will also contain network ID 0x100,
> so you can easily debug the existing connections).
>
> Question then: is there such a functionality present within enet?
>
> As I write this, I get the idea that clients actually have to know very
> little about other clients, and just deals with the objects. Anyway, I want
> to implement an ID generating scheme in my network library (which uses ENet
> under the covers) and don't want to re-invent wheels.
>
> For those who are interested: currently my syncing system consists of having
> a client (owner) ID in each car object. Then, for updates, the client's
> network ID is used to trace (on other clients) what car is the update for.
> This leads to trouble when each computer has its own series of ID's; it's
> very hard to debug race conditions resulting in swapped connection ordering.
> I currently sometimes get the the wrong cars to be updated. I believe an ID
> system described as above would fix things; giving each object an ID across
> all of the multiplayer game (on all computers). Currently it's a bit of a
> mess. :)
>
> Thanks for any pointers or any other ideas on how to simply and effectively
> update objects across multiple computers.
>
> Cheers,
> Ruud
>   



More information about the ENet-discuss mailing list