[ENet-discuss] Object unique ID's
Ruud van Gaal
ruud at racer.nl
Sun Mar 16 12:22:35 PDT 2008
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
> -----Oorspronkelijk bericht-----
> Van: enet-discuss-bounces at cubik.org
> [mailto:enet-discuss-bounces at cubik.org] Namens
> enet-discuss-request at cubik.org
> Verzonden: Saturday, March 15, 2008 01:18
> Aan: enet-discuss at cubik.org
> Onderwerp: ENet-discuss Digest, Vol 58, Issue 6
>
> Send ENet-discuss mailing list submissions to
> enet-discuss at cubik.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cubik.org/mailman/listinfo/enet-discuss
> or, via email, send a message with subject or body 'help' to
> enet-discuss-request at cubik.org
>
> You can reach the person managing the list at
> enet-discuss-owner at cubik.org
>
> When replying, please edit your Subject line so it is more
> specific than "Re: Contents of ENet-discuss digest..."
>
>
> Today's Topics:
>
> 1. eNet DLL or OCX? (steve at stamm.com)
> 2. Re: eNet DLL or OCX? (ismael)
> 3. Re: eNet DLL or OCX? (Lee Salzman)
> 4. fps networking (Jacky J)
> 5. Re: fps networking (Lee Salzman)
> 6. Re: fps networking (Martin Sherburn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 14 Mar 2008 19:32:49 +0000 (GMT)
> From: steve at stamm.com
> Subject: [ENet-discuss] eNet DLL or OCX?
> To: enet-discuss at cubik.org
> Message-ID: <1461085307.1081205523169456.JavaMail.mail at webmail02>
> Content-Type: text/plain; charset="iso-8859-1"
>
> An HTML attachment was scrubbed...
> URL:
> http://lists.cubik.org/pipermail/enet-discuss/attachments/2008
> 0314/f1b88b71/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Fri, 14 Mar 2008 21:02:08 +0100
> From: ismael <ismael.bamba at laposte.net>
> Subject: Re: [ENet-discuss] eNet DLL or OCX?
> To: steve at stamm.com, Discussion of the ENet library
> <enet-discuss at cubik.org>
> Message-ID: <47DAD9C0.1090003 at laposte.net>
> Content-Type: text/plain; charset="utf-8"
>
> steve at stamm.com wrote:
> >
> > Does anyone know if someone has created a Windows DLL or an
> OCX using
> > eNet?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Steve
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
> Hello Steve,
> I did a Windows port.
> You should be able to fond it in the archive.Otherwse let me
> know if you ca't find i'll try to shake my mind and find it somewhere.
>
> Best regards.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.cubik.org/pipermail/enet-discuss/attachments/2008
> 0314/e9780b0e/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Thu, 13 Mar 2008 22:09:18 -0700
> From: Lee Salzman <lsalzman1 at cox.net>
> Subject: Re: [ENet-discuss] eNet DLL or OCX?
> To: Discussion of the ENet library <enet-discuss at cubik.org>
> Message-ID: <47DA087E.4040909 at cox.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> There shouldn't be any need for a Windows "port". The
> included enet.dsp file should let you build it in Microsoft
> Visual Studio, and the unix build system also works just fine
> via MinGW/MSYS. There is also a note on how to build a DLL
> with the VS project file in the install section of the docs.
>
> Lee
>
> ismael wrote:
> > steve at stamm.com wrote:
> >>
> >> Does anyone know if someone has created a Windows DLL or
> an OCX using
> >> eNet?
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Steve
> >>
> >>
> --------------------------------------------------------------
> ----------
> >>
> >> _______________________________________________
> >> ENet-discuss mailing list
> >> ENet-discuss at cubik.org
> >> http://lists.cubik.org/mailman/listinfo/enet-discuss
> >>
> > Hello Steve,
> > I did a Windows port.
> > You should be able to fond it in the archive.Otherwse let
> me know if
> > you ca't find i'll try to shake my mind and find it somewhere.
> >
> > Best regards.
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 14 Mar 2008 15:18:06 -0600
> From: Jacky J <flamuss at gmail.com>
> Subject: [ENet-discuss] fps networking
> To: enet-discuss at cubik.org
> Message-ID: <47DAEB8E.7020005 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I'm having a hard time getting my head around some concepts used in
> first person shooter style games, namely sending user input. I
> understand pretty much everything else: client side
> prediction, object
> replication, etc.
>
> So here are my questions and thoughts:
>
> 1. The client continuously sends its input to the server. This is a
> packet that might have a bit field for each button or key.
> For example
> WASD might take 4 bits, and another few for jump or fire.
> So how often do i send these packets? Is it on a timer or do
> i send it
> as much as the clients presses those buttons?
>
> 2. My biggest concern: What if the client is bogged down to 5 fps,
> meaning in the best case, the server is receiving those
> inputs every 200
> ms. Surely the server needs to update the client based on
> the client's
> own framerate, because if you're moving the player 1 unit per
> input, the
> player will move a lot slower if it's updating less per unit time.
>
> My initial thought was to send some sort of lastsendtime to scale the
> player's input, but then it seems like you could cheat and just send
> really large values to make it seem like you're running at a low fps.
>
> What all should i be sending to the server, and what actions
> should the
> server be taking based on those inputs?
>
> I have a simple techdemo/game setup using enet called godmode.
> Everything is pretty much set up except for sending client inputs
> correctly.
>
> http://code.google.com/p/godmode/
>
> Thanks
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 14 Mar 2008 00:29:11 -0700
> From: Lee Salzman <lsalzman1 at cox.net>
> Subject: Re: [ENet-discuss] fps networking
> To: Discussion of the ENet library <enet-discuss at cubik.org>
> Message-ID: <47DA2947.7060201 at cox.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> FPS is a spectrum of things you can do, more than a set way.
> The ways,
> however, are far different from, say, a MMORPG where latency is just
> usually accepted by players: in a twitch FPS game, latency must be
> destroyed at all costs - latency is totally evil, no exceptions. But
> even within the spectrum of FPS networking, each way comes
> with its own
> trade-off. They more or less boil down to the following:
>
> Trade-off #1: fixed rate physics, or variable rate physics.
> You need to
> select a rate at which to run the physics simulation, i.e. 50 Hz, 100
> Hz, etc. Now if the rendering FPS is higher than the physics rate,
> then you will need to interpolate between two physics steps
> to have the
> game not look all jerky, since if the game is rendering at 100 FPS
> and physics is only simulated at 50 Hz, your view point is
> only changing
> 50 times a second, so half of those 100 FPS are going to
> waste. If you
> use variable rate, you still choose a minimum rate at which
> to run the
> physics, but if the FPS happens to be higher, then you run
> physics at a
> higher rate. For example, say, you settle on 50 Hz, meaning
> each physics
> step is 20 milliseconds. If one frame of rendering took up, say, 102
> milliseconds, then you would do 5 physics steps, and if doing
> fixed rate
> physics, you would bank those 2 leftover milliseconds for "credit" on
> the next frame. If you are doing variable rate physics, you just go
> ahead and do an extra time step using those leftover 2 milliseconds
> immediately. Fixed rate is probably better if you can just
> afford to run
> the physics at a high rate these days, and variable rate
> kinda requires
> the client to be authoritative on physics simulation.
>
> Trade-off #2: co-simulation, totally client-side physics, or
> lock-step
> simulation.
>
> - In a lock-step simulation, you would just send player input
> reliably
> to the server, the server would simulate physics, and tell the player
> where everything is at. This is a great evil that should
> never EVER be
> used in an FPS game because everything requires a silly
> round-trip that
> destroys twitch gameplay on even modest pings. I only mention
> it because
> you should NEVER use it. ;)
>
> - Totally client-side physics. Each client just runs its own physics,
> and broadcasts its position at a fixed rate to all other
> clients (either
> P2P or by sending it through the server which just broadcasts
> it - the
> server is just a dumb simple broadcaster in this case), i.e. you send
> out your position to other clients say 20 times a second as
> unreliable
> data. You don't really care if the position gets lost at all, since
> another one is coming behind it right away. On the receiving
> end, each
> client needs to smooth out the positions it is receiving from other
> clients, since it is much less the rendering FPS. You can do this by
> either buffering one or two steps worth of positions, and
> interpolating
> between them - i.e. you wait till you've gotten at least two position
> updates from a client, then over some time period (say 50
> milliseconds
> if updates are happening at 20 Hz), you interpolate the
> position between
> them. Another approach is to just send necessary physics
> simulation data
> (like player velocity), and keep simulating the client
> locally starting
> from the last position/velocity update you got. These two
> things can be
> combined, for instance just always simulate the player
> locally from the
> last time you got an update, however when an update comes in,
> record the
> different in between the update and the current position (the
> "snap"),
> and instead of applying the snap immediately, smooth it out over the
> next 50 milliseconds or so. Keep in mind clients are
> authoritative, so
> you need to take care of cheating by non-technical means (i.e. player
> moderator system).
>
> - Co-simulation. The server and client each run their own
> corresponding
> loosely coupled simulations. The client runs on the ASSUMPTION its
> simulation is always right i.e. when I shoot, the client
> assumes I hit
> what I actually did, or if I try to move, the client just
> moves locally.
> For EACH client time step the client is sending all the input (i.e.
> player movement directions and mouse look) to the server, so
> the server
> can exactly recreate each time step. This should be done via delta
> compression of an unreliable packet stream to avoid the cost
> of reliable
> packets. First choose a fixed rate, i.e. 20 Hz. Now every
> time step is
> numbered, so they form an ever-continuing sequence. So when
> you send a
> time step to the server, the server knows the sequence number of the
> last time step it got. It sends this sequence number back as
> a periodic
> ack (unreliable, of course, but best piggy-backed on other
> server->client updates) so the client knows the last sequence
> number the
> server received (or at least some sequence number less than
> that in case
> the ack gets lost in transit). Every time the client sends an
> update to
> the server, it sends all time steps starting at the last
> sequence number
> the server verified receiving (via that ack the server sent to the
> client), up to the most current time step. So the client must buffer
> all time steps it is sending to the server, until it has verified the
> server has received them, and is basically just sending this
> buffer at a
> fixed rate (again i.e. 20 Hz) to the server, removing stuff from the
> front of the buffer as it gets verification the server
> actually got it.
> If this buffer grows unreasonably large (i.e. some threshold
> like a few
> KB or more where sending it 20 times a second until the
> server gets it
> becomes stupidity), you can just "bail out" at the cost of a possible
> round-trip timeout stall by sending the client->server update as a
> reliable packet, and just clearing the buffer (since you know
> the update
> will get there). You just don't want to use the bail out
> option on every
> packet, since you want to avoid the latency of reliable
> traffic at all
> costs. Smart encoding of a time step with a simple run-length
> scheme and
> you can get the average size of a time step in transit down to only a
> few bits since you may only have one of 8 compass directions,
> 2D mouse
> coords, and maybe some boolean modifiers like jump/crouch,
> and certain
> aspects like the direction don't change very fast. Various
> events like
> shooting , picking up items, etc. should be properly
> sequenced into this
> same stream as well (but encoded via some exceptional means/special
> prefix since they are uncommon). You just put these in a server-side
> queue for each player, which the server dequeues and runs for each
> player at each of its time steps. If it doesn't have any time
> step info
> for a client at a particular server time-step, you can either
> keep the
> client moving in whichever direction he was going, or just have him
> stand there - whatever seems most reasonable, but you give
> the client a
> "credit" for that time step, so that when more time steps
> come in over
> the net, you apply them immediately so long as the client has credits.
>
> Now the tricky part. The server then runs its simulation at whatever
> fixed rate you decided along with the client. The server must
> then send
> out server->client updates on positions/velocities of other
> clients in
> the world. You can do this by jumping through hoops to do the whole
> delta compression of each other client's input stream to get
> it from the
> server->client, but this just becomes stupidly complex and hoggish of
> bandwidth (call that Trade-off #3). You are better off just
> sending out
> the updates from server->client much as you would in the "totally
> client-side" case, i.e. just a simple unreliable update
> containing the
> positions/velocities of everything, again at some fixed rate
> like 20 Hz.
> If the update gets lost in transit, you don't care since
> another one is
> coming soon. However, you want to tag each of these server->client
> updates with a sequence number. So when the client gets an update, it
> knows the sequence number of the last one it got. The client just
> locally moves the physics ahead using its own fixed rate simulation
> (that hopefully works in the same way as the server's, unless
> the client
> is cheating by modifying it). Now when the client interacts with an
> object, i.e. aims at it and shoots it, it can tell the server
> ("Okay, I
> shot player Bob, who was at the position stated in
> server->client update
> #42, from 60 milliseconds had elapsed since that updated, so
> I had moved
> Bob ahead locally 3 time steps from that position.") The server must
> buffer the results of each time step of its simulation up to a
> reasonable amount of time (say 1 second). So when the server receives
> your shot request, it looks in its buffer for physics update
> #42 (or if
> this is a time step > 1 second old, just takes the oldest from the
> buffer instead), find Bob's position in this buffered physics update,
> predicts him ahead 60 milliseconds/3 time steps in the SAME EXACT WAY
> the client would have had it got no more updates during those 60
> milliseconds, and then applies your shot to Bob at that
> position. If you
> are quantizing/truncating numbers to send them from server->client in
> the updates, you must simulate this on the server when pulling Bob's
> position out of the update as well. This way aiming/shooting is
> completely WYSIWYG, no disgusting
> having-to-lead-your-shots-ahead type
> of gameplay like in various Quakes.
>
> Now there can be some small round-off differences from processor to
> processor, so the simulation between the client and server may drift
> over time. So every so often the client must either send
> what position
> it is at, or the server sends what position it has the client
> at to the
> client. In either case, you check if they differ by a substantial
> amount, and if so the server sends all the raw/unquantized
> physics info
> needed to the client for them to sync back up (causing an
> ugly snap, of
> which the only sane way to hide is interpolation). If you can
> manage to
> implement the physics entirely without floating point such that there
> will never be any drift and hence no snaps, go for that instead (but
> seems largely impossible in this day and age with more
> complicated physics).
>
> Hopefully this all adequately confuses you. :)
>
> Lee
>
> Jacky J wrote:
> > I'm having a hard time getting my head around some concepts used in
> > first person shooter style games, namely sending user input. I
> > understand pretty much everything else: client side
> prediction, object
> > replication, etc.
> >
> > So here are my questions and thoughts:
> >
> > 1. The client continuously sends its input to the server.
> This is a
> > packet that might have a bit field for each button or key.
> For example
> > WASD might take 4 bits, and another few for jump or fire.
> > So how often do i send these packets? Is it on a timer or
> do i send it
> > as much as the clients presses those buttons?
> >
> > 2. My biggest concern: What if the client is bogged down to 5 fps,
> > meaning in the best case, the server is receiving those
> inputs every 200
> > ms. Surely the server needs to update the client based on
> the client's
> > own framerate, because if you're moving the player 1 unit
> per input, the
> > player will move a lot slower if it's updating less per unit time.
> >
> > My initial thought was to send some sort of lastsendtime to
> scale the
> > player's input, but then it seems like you could cheat and
> just send
> > really large values to make it seem like you're running at
> a low fps.
> >
> > What all should i be sending to the server, and what
> actions should the
> > server be taking based on those inputs?
> >
> > I have a simple techdemo/game setup using enet called godmode.
> > Everything is pretty much set up except for sending client inputs
> > correctly.
> >
> > http://code.google.com/p/godmode/
> >
> > Thanks
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 14 Mar 2008 22:57:53 +0000
> From: Martin Sherburn <spacedude at konggame.co.uk>
> Subject: Re: [ENet-discuss] fps networking
> To: Discussion of the ENet library <enet-discuss at cubik.org>
> Message-ID: <47DB02F1.8040007 at konggame.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 1. You can put it on a timer with a default value of say 20
> or 30 times
> a second. Then you can try varying it to see what gives best results.
> You may want to set the rate depending on the connection,
> e.g. low rate
> for 56 kbps modem users and high rate for LAN games. So you can leave
> this up to the client to adjust.
>
> 2. The server should just assume the input has not changed until it
> receives a new update from the client. If there are some connection
> problems between the client and the server and no input is transmited
> for 1 second (lag spike) and the player was running forward,
> the server
> will just assume the client continued to run forwards during that one
> second. You may want to handle jump and fire differently,
> these can be
> transmitted as one-shot events. I.e. you send 1 reliable packet each
> time the player presses a jump or fire key, rather than continously
> sending whether or not the player is jumping or shooting. So you have
> two ways of transmitting input: 1) continuous stream 2)
> one-shot events.
> You need to decide which input is suitable for each action.
> Events where
> the user quickly taps a key can be lost when sent as a
> continuous stream
> because the key tap may last less time than the time between
> two pack sends.
>
> Hope that helps,
>
> Martin.
>
> Jacky J wrote:
> > I'm having a hard time getting my head around some concepts used in
> > first person shooter style games, namely sending user input. I
> > understand pretty much everything else: client side
> prediction, object
> > replication, etc.
> >
> > So here are my questions and thoughts:
> >
> > 1. The client continuously sends its input to the server.
> This is a
> > packet that might have a bit field for each button or key.
> For example
> > WASD might take 4 bits, and another few for jump or fire.
> > So how often do i send these packets? Is it on a timer or
> do i send it
> > as much as the clients presses those buttons?
> >
> > 2. My biggest concern: What if the client is bogged down to 5 fps,
> > meaning in the best case, the server is receiving those
> inputs every 200
> > ms. Surely the server needs to update the client based on
> the client's
> > own framerate, because if you're moving the player 1 unit
> per input, the
> > player will move a lot slower if it's updating less per unit time.
> >
> > My initial thought was to send some sort of lastsendtime to
> scale the
> > player's input, but then it seems like you could cheat and
> just send
> > really large values to make it seem like you're running at
> a low fps.
> >
> > What all should i be sending to the server, and what
> actions should the
> > server be taking based on those inputs?
> >
> > I have a simple techdemo/game setup using enet called godmode.
> > Everything is pretty much set up except for sending client inputs
> > correctly.
> >
> > http://code.google.com/p/godmode/
> >
> > Thanks
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
>
>
>
> ------------------------------
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
> End of ENet-discuss Digest, Vol 58, Issue 6
> *******************************************
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.21.7/1330 - Release
> Date: 15/03/2008 14:36
>
>
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1330 - Release Date: 15/03/2008
14:36
More information about the ENet-discuss
mailing list