RE: [Algorithms] multiplayer game: synchronize server / clients IDs

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

You could simply tag each client command with a "transaction ID".

"attack this NPC using currently selected spell" would turn into
"attack this NPC using currently selected spell using transaction
ID 012345678".
Then on the server, tag all objects resulting from this game command
with the transaction ID _and_ communicate this ID back to the client
when sending the CreateObj packet. Then the client can correlate the
received transaction ID with the local estimation.
There might be a challenge selecting the right fireball out of 20
for a single transaction ID. But then again, these are all fireballs
and selecting the nearest one should be fine, right?

Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de

Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
 =20

> -----Original Message-----
> From: gda...@li...=20
> [mailto:gda...@li...] On=20
> Behalf Of toms @ cyanide
> Sent: Thursday, April 13, 2006 10:33 AM
> To: gda...@li...
> Subject: Re: [Algorithms] multiplayer game: synchronize=20
> server / clients IDs
>=20
> thx all for the answers.
>=20
> I don't think this is absolutely related with TNL. I just spoke about=20
> TNL to let you know what I was using.
> Actually, TNL does not manage my actors' IDs, but I do myself.
> Anyway if I am mistaking just tell me and I'll stop here :)
>=20
> About all your answers, the fact is that I cannot send the ID of the=20
> client side created fireball because I send command like "attack this=20
> NPC using currently selected spell" instead of "create a=20
> fireball going=20
> this way". So when I send the command I don't yet know what I will=20
> create, nor how many (a spell can create up to 20 actors (chain=20
> lightning for example), nor when (if the hero is not in the range, he=20
> will have to move before casting the spell) and maybe never (if the=20
> target dies during hero displacement).
>=20
> I cannot let the fireball not be corrected by the server, because I=20
> cannot be absolutely sure server side fireball and client=20
> side fireball=20
> will be launched exactly in the same direction, then creating a big=20
> difference after 10 or 20m (my predict may effectively not be so=20
> accurate :) )
>=20
> The solution I may keep is never creating a fireball client=20
> side, and do=20
> not care about lags.
>=20
> The one I am still looking for to be 100% sure is: when creating a=20
> fireball client side, pool it in a queue of "actors waiting=20
> for network=20
> IDs".
> When I receive a "fireball creation order" (not exactly that,=20
> but this=20
> is the simpliest word to say it) from the server, I look into=20
> this pool=20
> and if I find a matching actor I associate it with the new=20
> one coming.=20
> But the pb is to be sure to not mistake the matching.
>=20
> thx all again :)
>=20
> Jay Stelly wrote:
>=20
> >If this is for client-side prediction (sounds like it), then=20
> why don't
> >you just send the client ID to the server with the "launch fireball"
> >command, then have the server send it back with the=20
> fireball's data?  I
> >don't know anything about your client/server architecture,=20
> but it should
> >be doable if you can customize the data stream per object and per
> >command.
> >
> >Another option we've used is to suppress the server-side=20
> stuff for the
> >originating client:
> >client creates fireball
> >server knows to send the fireball only to other clients (assuming the
> >originating client will predict it properly)
> >
> >That one depends on how accurate your prediction is.
> >
> >Jay
> >
> >
> > =20
> >
> >>-----Original Message-----
> >>From: gda...@li...=20
> >>[mailto:gda...@li...] On=20
> >>Behalf Of toms
> >>Sent: Wednesday, April 12, 2006 10:17 AM
> >>To: gda...@li...
> >>Subject: [Algorithms] multiplayer game: synchronize server /=20
> >>clients IDs
> >>
> >>Hi!
> >>I want to synchronize my actors IDs' over the network, on a=20
> >>client / server architecture, using TNL.
> >>When a server creates an actor, this actor is ghosted, and=20
> >>once created on client side, I have the ID which it was=20
> >>created with server side. No pb with that.
> >>The problem is that I can't understand how I can create this=20
> >>synchronization in the case a client first creates an actor.
> >>For example, lets says client A launches a fireball. It sends=20
> >>the command "attack this NPC, launching a fireball" to the=20
> >>server. A creates a fireball, not waiting for server's=20
> >>answer. When receiving the command, the server also creates a=20
> >>fireball. The fireball is now present on both sides. How will=20
> >>the server be able to tell A that this fireball must be=20
> >>assigned ID XXX, and is the same previously client side=20
> >>created fireball?
> >>I thought about many solutions, but none was good:
> >>- synchronizing IDs: this cannot be done, as I cannot be sure=20
> >>the creation order will be the same on both machines, even if=20
> >>I assign an ID zone for each client (during the creation of=20
> >>the fireball client side, the server may be creating an=20
> >>effect on this client)
> >>- pooling created actors, waiting for ID assignment: if I=20
> >>have 2 or 3 fireballs, how can I be sure I wil not mistake=20
> >>when I will assign the ID?
> >>- do not create actors client side: this will create lags=20
> >>during fireball launch order and fireball apparition.
> >>
> >>Any ideas?
> >>thx a lot
> >>toms
> >>   =20
> >>
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&
> dat=3D121642
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188
>=20