technical questions for a multiplayer online car game.
18 views
Skip to first unread message
nouknouk
Jan 8, 2009, 8:46:20 AM1/8/09
to PulpCore
Hi,
I'm planning to help someone to develop kind of little classic 2D car
game view a top view, something like the old but excellent game
Micromachines (screenshot here: http://www.gamefabrique.com/images/shots/micro-machines-2-3.png
)
The main idea is to allow players to play online with other human
players. Of course, it would be pulpcore powered :D
For that, I have a few technical questions, a bit off topic, but maybe
someone could give me some tips and/or main guidelines:
1/ Network stuff
I already have a basic network framework for turn based games (
http://multijoo.no-ip.org ). But for a car game the real time
constraints are bigger for interaction with other players.
- typically the use of UDP is recommended for such real time stuff.
But as most of internet connexions are NATed one (ADSL boxes, Wifi
AP, ...), it's inconceivable to ask the casual player to set up its
box to redirect an UDP port.
- On the other hand, I recently played with FPS games (urban terror)
behind a NAT, and it seems there are no requirement to redirect
anything.
=> Do you think they use a bi-protocol communication, like UDP for
client->server comms and TCP for server->client comms ?
- about latency and other network constraints' avoidance, we should
typically use dead reckoning technology.
=> Do you know if it already exists open-sourced (and leightweight)
java framework implementing such technology that I could reuse ?
2/ collision stuff.
I suppose the best way to manage nicely cars collisions with other
elements (trees, walls, other cars, ...) is to use per pixel collision
check. As the racetracks could be big, I cannot reasonably check
collision with each sprite of the track at each frame. I will have to
improve performances with something like B-tree.
=> I suppose the collision detection mechanism of pulpcore isn't
implementing such thing. Do you know any (open sourced) implementation
of such 'B-tree like' technology in Java ?
More generally: do you know if any open sourced game like ours (with
both 2D view and mulitplayer feature across network) from which we
could get inspiration already exists ?
Many thanks in advance.
I'm planning to help someone to develop kind of little classic 2D car
game view a top view, something like the old but excellent game
Micromachines (screenshot here: http://www.gamefabrique.com/images/shots/micro-machines-2-3.png
)
The main idea is to allow players to play online with other human
players. Of course, it would be pulpcore powered :D
For that, I have a few technical questions, a bit off topic, but maybe
someone could give me some tips and/or main guidelines:
1/ Network stuff
I already have a basic network framework for turn based games (
http://multijoo.no-ip.org ). But for a car game the real time
constraints are bigger for interaction with other players.
- typically the use of UDP is recommended for such real time stuff.
But as most of internet connexions are NATed one (ADSL boxes, Wifi
AP, ...), it's inconceivable to ask the casual player to set up its
box to redirect an UDP port.
- On the other hand, I recently played with FPS games (urban terror)
behind a NAT, and it seems there are no requirement to redirect
anything.
=> Do you think they use a bi-protocol communication, like UDP for
client->server comms and TCP for server->client comms ?
- about latency and other network constraints' avoidance, we should
typically use dead reckoning technology.
=> Do you know if it already exists open-sourced (and leightweight)
java framework implementing such technology that I could reuse ?
2/ collision stuff.
I suppose the best way to manage nicely cars collisions with other
elements (trees, walls, other cars, ...) is to use per pixel collision
check. As the racetracks could be big, I cannot reasonably check
collision with each sprite of the track at each frame. I will have to
improve performances with something like B-tree.
=> I suppose the collision detection mechanism of pulpcore isn't
implementing such thing. Do you know any (open sourced) implementation
of such 'B-tree like' technology in Java ?
More generally: do you know if any open sourced game like ours (with
both 2D view and mulitplayer feature across network) from which we
could get inspiration already exists ?
Many thanks in advance.
David Brackeen
Jan 8, 2009, 12:09:46 PM1/8/09
to pulp...@googlegroups.com
Personally I haven't done real-time networked games before, so I can't offer any advice. I thought Kevin Glass had a networking API, but I couldn't find it so maybe I was imagining things.
For collision detections on this type of game, the easiest solution would be simple spatial partitions. (AKA cells that are all the same dimension) A partition size might be 1/4th the screen size (or whatever works best in the situation). Then for each moving object you only check objects in its partition. As an object moves, it updates the partition it is in. Don't forget cases where an object is in multiple partitions.
If it were me, I'd probably do early prototyping with one or two moving cars and just brute-force check everything, and then add a better collision detection algorithm later.
Jonathan Chung
Jan 9, 2009, 1:38:59 AM1/9/09
to PulpCore
Kevin's implemented a spatial partitioning collision strategy in his
Phys2D library. You can extract that part out and refactor it, so that
it can be applied to any game system.
You might want to look into a non-pixel-based collision system since
those are expensive, computationally. Regardless, you'll want to do a
broad phase pass (which the spatial partitioning is) to prune out
collisions that have no chance of happening (static vs. static,
dynamic vs. something off-screen, etc.) before you make those
expensive calculations.
I'm curious to see how this car game pans out since I'll eventually
need to add support for real-time networked games.
- Jon
On Jan 8, 9:09 am, "David Brackeen" <brack...@gmail.com> wrote:
> Personally I haven't done real-time networked games before, so I can't offer
> any advice. I thought Kevin Glass had a networking API, but I couldn't find
> it so maybe I was imagining things.
> For collision detections on this type of game, the easiest solution would be
> simple spatial partitions. (AKA cells that are all the same dimension) A
> partition size might be 1/4th the screen size (or whatever works best in the
> situation). Then for each moving object you only check objects in its
> partition. As an object moves, it updates the partition it is in. Don't
> forget cases where an object is in multiple partitions.
> If it were me, I'd probably do early prototyping with one or two moving cars
> and just brute-force check everything, and then add a better collision
> detection algorithm later.
>
Phys2D library. You can extract that part out and refactor it, so that
it can be applied to any game system.
You might want to look into a non-pixel-based collision system since
those are expensive, computationally. Regardless, you'll want to do a
broad phase pass (which the spatial partitioning is) to prune out
collisions that have no chance of happening (static vs. static,
dynamic vs. something off-screen, etc.) before you make those
expensive calculations.
I'm curious to see how this car game pans out since I'll eventually
need to add support for real-time networked games.
- Jon
On Jan 8, 9:09 am, "David Brackeen" <brack...@gmail.com> wrote:
> Personally I haven't done real-time networked games before, so I can't offer
> any advice. I thought Kevin Glass had a networking API, but I couldn't find
> it so maybe I was imagining things.
> For collision detections on this type of game, the easiest solution would be
> simple spatial partitions. (AKA cells that are all the same dimension) A
> partition size might be 1/4th the screen size (or whatever works best in the
> situation). Then for each moving object you only check objects in its
> partition. As an object moves, it updates the partition it is in. Don't
> forget cases where an object is in multiple partitions.
> If it were me, I'd probably do early prototyping with one or two moving cars
> and just brute-force check everything, and then add a better collision
> detection algorithm later.
>
> On Thu, Jan 8, 2009 at 5:46 AM, nouknouk <alexandre.braga...@gmail.com>wrote:
>
>
>
> > Hi,
>
> > I'm planning to help someone to develop kind of little classic 2D car
> > game view a top view, something like the old but excellent game
> > Micromachines (screenshot here:
> >http://www.gamefabrique.com/images/shots/micro-machines-2-3.png
> > )
> > The main idea is to allow players to play online with other human
> > players. Of course, it would be pulpcore powered :D
>
> > For that, I have a few technical questions, a bit off topic, but maybe
> > someone could give me some tips and/or main guidelines:
>
> > 1/ Network stuff
>
> > I already have a basic network framework for turn based games (
> >http://multijoo.no-ip.org). But for a car game the real time
>
>
>
> > Hi,
>
> > I'm planning to help someone to develop kind of little classic 2D car
> > game view a top view, something like the old but excellent game
> > Micromachines (screenshot here:
> >http://www.gamefabrique.com/images/shots/micro-machines-2-3.png
> > )
> > The main idea is to allow players to play online with other human
> > players. Of course, it would be pulpcore powered :D
>
> > For that, I have a few technical questions, a bit off topic, but maybe
> > someone could give me some tips and/or main guidelines:
>
> > 1/ Network stuff
>
> > I already have a basic network framework for turn based games (
Eric Jordan
Jan 9, 2009, 9:28:49 AM1/9/09
to PulpCore
CommanderKeith at JavaGaming.org was working on something like this,
at least briefly, (I think it was a 2d space shooter of some sort) and
I'm pretty sure he had it set up to work over the network;
unfortunately the link I had to his post has died after a
restructuring of JGO's forums, so you may need to hunt around there a
bit to find it.
We've also discussed networked physics a bit at the Box2d forums, see
the thread starting at http://www.box2d.org/forum/viewtopic.php?f=3&t=143&st=0&sk=t&sd=a,
which has a bunch of links and discussion (though not specific to
Java).
If you're doing anything real time and networked, the main
difficulties are going to show up when you try to set up your
algorithm to respond properly to variable latency connections without
causing lag in the player control. Something like WoW may be able to
get away with waiting for a round trip to the server when you cast a
spell before you see anything happen, but even there the movement
stuff is simulated locally and the server plays catch-up so that you
don't feel that the system is massively unresponsive. Now imagine
that the players physically collided with each other and have to deal
with up to a half second of lag, and you understand the difficulty of
the problem...the modern physics-based FPSes have devised various ways
to deal with this, and sadly, none of them are very simple.
- Eric
at least briefly, (I think it was a 2d space shooter of some sort) and
I'm pretty sure he had it set up to work over the network;
unfortunately the link I had to his post has died after a
restructuring of JGO's forums, so you may need to hunt around there a
bit to find it.
We've also discussed networked physics a bit at the Box2d forums, see
the thread starting at http://www.box2d.org/forum/viewtopic.php?f=3&t=143&st=0&sk=t&sd=a,
which has a bunch of links and discussion (though not specific to
Java).
If you're doing anything real time and networked, the main
difficulties are going to show up when you try to set up your
algorithm to respond properly to variable latency connections without
causing lag in the player control. Something like WoW may be able to
get away with waiting for a round trip to the server when you cast a
spell before you see anything happen, but even there the movement
stuff is simulated locally and the server plays catch-up so that you
don't feel that the system is massively unresponsive. Now imagine
that the players physically collided with each other and have to deal
with up to a half second of lag, and you understand the difficulty of
the problem...the modern physics-based FPSes have devised various ways
to deal with this, and sadly, none of them are very simple.
- Eric
nouknouk
Jan 15, 2009, 8:57:08 PM1/15/09
to PulpCore
Hi,
first: thanks guys for your advices and links.
In the past days I did some basic prototypes to check what would be
the network requirements for such real time game.
My first results are far more encouraging than expected:
1/ a TCP flow seems to be sufficient enough. It seems I won't need to
use a UDP flow which is usually more complex to hanlde.
2/ the real time constraints are not as ... constraining as I
expected: it seems that even a basic scheme is sufficient. I mean here
a scheme where all player's inputs are sent to the server and the
client's display is updated only when the server's response comes
back.
Of course, such scheme wouldn't fit for a FPS game, but as far as I
tested, the 'real time constraint' for a basic 2D car game looks far
less demanding.
This looks like a really good point, as if this scheme is really
suitable, that means I won't have to worry about implementing latency
avoidance feature, or any other prediction mechanism.
My last concern is to validate the assumptions above.
For the moment, all my tests have been made with my clients connected
to my home 10Mbits DSL connexion and the server hosted on my dedicated
server (I dod some tests with a WiFi DSL router too). With such
configuration, I get an average ping of 55ms.
But maybe the ping is higher (too high ?) when clients are connected
from another (far away) countries.
Thus, as I know that people registered on pulpcore discussion group
live in several countries (US, Netherlands, ...), may I ask you to
spend 3 seconds to perform a little test for me:
Could you simply do a " ping multijoo.no-ip.org " and give me some
feedback about the results and your network configuration (country,
connexion type, bandwith, ...) ?
Many thanks in advance.
Best regards,
Nouk²
PS: after a few research, I finally found a video of the car game
close to my goal: The game was called "Nitro" and was running on AMIGA
computers and had an interresting 'night mode' (yeah ... 1990 ... good
old times ... ;-)
Here is the link: http://www.youtube.com/watch?v=d3K9lTmELiM&feature=related
(night mode at 2:52)
first: thanks guys for your advices and links.
In the past days I did some basic prototypes to check what would be
the network requirements for such real time game.
My first results are far more encouraging than expected:
1/ a TCP flow seems to be sufficient enough. It seems I won't need to
use a UDP flow which is usually more complex to hanlde.
2/ the real time constraints are not as ... constraining as I
expected: it seems that even a basic scheme is sufficient. I mean here
a scheme where all player's inputs are sent to the server and the
client's display is updated only when the server's response comes
back.
Of course, such scheme wouldn't fit for a FPS game, but as far as I
tested, the 'real time constraint' for a basic 2D car game looks far
less demanding.
This looks like a really good point, as if this scheme is really
suitable, that means I won't have to worry about implementing latency
avoidance feature, or any other prediction mechanism.
My last concern is to validate the assumptions above.
For the moment, all my tests have been made with my clients connected
to my home 10Mbits DSL connexion and the server hosted on my dedicated
server (I dod some tests with a WiFi DSL router too). With such
configuration, I get an average ping of 55ms.
But maybe the ping is higher (too high ?) when clients are connected
from another (far away) countries.
Thus, as I know that people registered on pulpcore discussion group
live in several countries (US, Netherlands, ...), may I ask you to
spend 3 seconds to perform a little test for me:
Could you simply do a " ping multijoo.no-ip.org " and give me some
feedback about the results and your network configuration (country,
connexion type, bandwith, ...) ?
Many thanks in advance.
Best regards,
Nouk²
PS: after a few research, I finally found a video of the car game
close to my goal: The game was called "Nitro" and was running on AMIGA
computers and had an interresting 'night mode' (yeah ... 1990 ... good
old times ... ;-)
Here is the link: http://www.youtube.com/watch?v=d3K9lTmELiM&feature=related
(night mode at 2:52)
Eric Jordan
Jan 15, 2009, 9:42:25 PM1/15/09
to PulpCore
From US, on a cable modem, 10Mbit connection (I think):
--- multijoo.no-ip.org ping statistics ---
44 packets transmitted, 44 packets received, 0% packet loss
round-trip min/avg/max/stddev = 90.892/127.272/311.885/61.146 ms
Usually the pings take ~90 ms, but occasionally for a few seconds they
spike to ~250 or so and then come back down.
--- multijoo.no-ip.org ping statistics ---
44 packets transmitted, 44 packets received, 0% packet loss
round-trip min/avg/max/stddev = 90.892/127.272/311.885/61.146 ms
Usually the pings take ~90 ms, but occasionally for a few seconds they
spike to ~250 or so and then come back down.
Troy Cox
Jan 15, 2009, 10:48:32 PM1/15/09
to pulp...@googlegroups.com
Oklahoma City, Oklahoma USA
Cable speed test results at SpeakEasy using Dallas Servers.
Download Speed: 20661 kbps (2582.6 KB/sec transfer rate)
Upload Speed: 3232 kbps (404 KB/sec transfer rate)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Troy Cox>ping multijoo.no-ip.org -t
Pinging multijoo.no-ip.org [87.98.136.174] with 32 bytes of data:
Reply from 87.98.136.174: bytes=32 time=150ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=136ms TTL=58
Reply from 87.98.136.174: bytes=32 time=127ms TTL=58
Reply from 87.98.136.174: bytes=32 time=163ms TTL=58
Reply from 87.98.136.174: bytes=32 time=191ms TTL=58
Reply from 87.98.136.174: bytes=32 time=156ms TTL=58
Reply from 87.98.136.174: bytes=32 time=162ms TTL=58
Reply from 87.98.136.174: bytes=32 time=163ms TTL=58
Reply from 87.98.136.174: bytes=32 time=190ms TTL=58
Reply from 87.98.136.174: bytes=32 time=192ms TTL=58
Reply from 87.98.136.174: bytes=32 time=127ms TTL=58
Reply from 87.98.136.174: bytes=32 time=162ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=161ms TTL=58
Reply from 87.98.136.174: bytes=32 time=142ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=190ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=196ms TTL=58
Ping statistics for 87.98.136.174:
Packets: Sent = 23, Received = 23, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 126ms, Maximum = 196ms, Average = 159ms
Control-Break
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=132ms TTL=58
Reply from 87.98.136.174: bytes=32 time=191ms TTL=58
Reply from 87.98.136.174: bytes=32 time=156ms TTL=58
Reply from 87.98.136.174: bytes=32 time=128ms TTL=58
Reply from 87.98.136.174: bytes=32 time=162ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=192ms TTL=58
Reply from 87.98.136.174: bytes=32 time=171ms TTL=58
Reply from 87.98.136.174: bytes=32 time=161ms TTL=58
Reply from 87.98.136.174: bytes=32 time=195ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=164ms TTL=58
Reply from 87.98.136.174: bytes=32 time=164ms TTL=58
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=128ms TTL=58
Reply from 87.98.136.174: bytes=32 time=165ms TTL=58
Reply from 87.98.136.174: bytes=32 time=192ms TTL=58
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=128ms TTL=58
Reply from 87.98.136.174: bytes=32 time=167ms TTL=58
Reply from 87.98.136.174: bytes=32 time=190ms TTL=58
Ping statistics for 87.98.136.174:
Packets: Sent = 45, Received = 45, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 126ms, Maximum = 196ms, Average = 158ms
Cable speed test results at SpeakEasy using Dallas Servers.
Download Speed: 20661 kbps (2582.6 KB/sec transfer rate)
Upload Speed: 3232 kbps (404 KB/sec transfer rate)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Troy Cox>ping multijoo.no-ip.org -t
Pinging multijoo.no-ip.org [87.98.136.174] with 32 bytes of data:
Reply from 87.98.136.174: bytes=32 time=150ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=136ms TTL=58
Reply from 87.98.136.174: bytes=32 time=127ms TTL=58
Reply from 87.98.136.174: bytes=32 time=163ms TTL=58
Reply from 87.98.136.174: bytes=32 time=191ms TTL=58
Reply from 87.98.136.174: bytes=32 time=156ms TTL=58
Reply from 87.98.136.174: bytes=32 time=162ms TTL=58
Reply from 87.98.136.174: bytes=32 time=163ms TTL=58
Reply from 87.98.136.174: bytes=32 time=190ms TTL=58
Reply from 87.98.136.174: bytes=32 time=192ms TTL=58
Reply from 87.98.136.174: bytes=32 time=127ms TTL=58
Reply from 87.98.136.174: bytes=32 time=162ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=161ms TTL=58
Reply from 87.98.136.174: bytes=32 time=142ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=190ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=196ms TTL=58
Ping statistics for 87.98.136.174:
Packets: Sent = 23, Received = 23, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 126ms, Maximum = 196ms, Average = 159ms
Control-Break
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=132ms TTL=58
Reply from 87.98.136.174: bytes=32 time=191ms TTL=58
Reply from 87.98.136.174: bytes=32 time=156ms TTL=58
Reply from 87.98.136.174: bytes=32 time=128ms TTL=58
Reply from 87.98.136.174: bytes=32 time=162ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=192ms TTL=58
Reply from 87.98.136.174: bytes=32 time=171ms TTL=58
Reply from 87.98.136.174: bytes=32 time=161ms TTL=58
Reply from 87.98.136.174: bytes=32 time=195ms TTL=58
Reply from 87.98.136.174: bytes=32 time=155ms TTL=58
Reply from 87.98.136.174: bytes=32 time=164ms TTL=58
Reply from 87.98.136.174: bytes=32 time=164ms TTL=58
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=128ms TTL=58
Reply from 87.98.136.174: bytes=32 time=165ms TTL=58
Reply from 87.98.136.174: bytes=32 time=192ms TTL=58
Reply from 87.98.136.174: bytes=32 time=126ms TTL=58
Reply from 87.98.136.174: bytes=32 time=128ms TTL=58
Reply from 87.98.136.174: bytes=32 time=167ms TTL=58
Reply from 87.98.136.174: bytes=32 time=190ms TTL=58
Ping statistics for 87.98.136.174:
Packets: Sent = 45, Received = 45, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 126ms, Maximum = 196ms, Average = 158ms
Jark
Jan 16, 2009, 8:04:17 AM1/16/09
to PulpCore
From the Netherlands, my adsl modem is trained in at :
Downstream Rate: 7598 kbps
Upstream Rate: 1023 kbps
And my ping is:
C:\Users\Jark>ping multijoo.no-ip.org -t
Reply from 87.98.136.174: bytes=32 time=16ms TTL=56
Reply from 87.98.136.174: bytes=32 time=13ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=49ms TTL=56
Reply from 87.98.136.174: bytes=32 time=15ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=22ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=25ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=13ms TTL=56
Reply from 87.98.136.174: bytes=32 time=13ms TTL=56
Ping statistics for 87.98.136.174:
Packets: Sent = 13, Received = 13, Lost = 0 (0% loss),
Downstream Rate: 7598 kbps
Upstream Rate: 1023 kbps
And my ping is:
C:\Users\Jark>ping multijoo.no-ip.org -t
Reply from 87.98.136.174: bytes=32 time=16ms TTL=56
Reply from 87.98.136.174: bytes=32 time=13ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=49ms TTL=56
Reply from 87.98.136.174: bytes=32 time=15ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=22ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=25ms TTL=56
Reply from 87.98.136.174: bytes=32 time=14ms TTL=56
Reply from 87.98.136.174: bytes=32 time=13ms TTL=56
Reply from 87.98.136.174: bytes=32 time=13ms TTL=56
Ping statistics for 87.98.136.174:
Packets: Sent = 13, Received = 13, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 49ms, Average = 18ms
David Brackeen
Jan 16, 2009, 10:51:09 AM1/16/09
to pulp...@googlegroups.com
From DSL in Los Angeles, CA (vs. google)
~% ping -c 8 google.com
PING google.com (209.85.171.100): 56 data bytes
64 bytes from 209.85.171.100: icmp_seq=0 ttl=241 time=41.507 ms
64 bytes from 209.85.171.100: icmp_seq=1 ttl=241 time=40.901 ms
64 bytes from 209.85.171.100: icmp_seq=2 ttl=241 time=42.044 ms
64 bytes from 209.85.171.100: icmp_seq=3 ttl=241 time=38.994 ms
64 bytes from 209.85.171.100: icmp_seq=4 ttl=241 time=40.918 ms
64 bytes from 209.85.171.100: icmp_seq=5 ttl=241 time=40.558 ms
64 bytes from 209.85.171.100: icmp_seq=6 ttl=241 time=38.746 ms
64 bytes from 209.85.171.100: icmp_seq=7 ttl=241 time=39.280 ms
--- google.com ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 38.746/40.368/42.044/1.142 ms
~% ping -c 8 multijoo.no-ip.org
PING multijoo.no-ip.org (87.98.136.174): 56 data bytes
64 bytes from 87.98.136.174: icmp_seq=0 ttl=53 time=156.413 ms
64 bytes from 87.98.136.174: icmp_seq=1 ttl=53 time=156.846 ms
64 bytes from 87.98.136.174: icmp_seq=2 ttl=53 time=156.053 ms
64 bytes from 87.98.136.174: icmp_seq=3 ttl=53 time=156.119 ms
64 bytes from 87.98.136.174: icmp_seq=4 ttl=53 time=156.546 ms
64 bytes from 87.98.136.174: icmp_seq=5 ttl=53 time=160.512 ms
64 bytes from 87.98.136.174: icmp_seq=6 ttl=53 time=156.026 ms
64 bytes from 87.98.136.174: icmp_seq=7 ttl=53 time=156.232 ms
--- multijoo.no-ip.org ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 156.026/156.843/160.512/1.411 ms
Andres Martinez Quijano
Jan 16, 2009, 10:53:07 AM1/16/09
to pulp...@googlegroups.com
From Argentina (cable, 1MB)
18 packets transmitted, 18 received, 0% packet loss, time 17069ms
rtt min/avg/max/mdev = 226.621/229.633/231.978/1.773 ms
Florent DUPONT
Jan 16, 2009, 2:13:22 PM1/16/09
to pulp...@googlegroups.com
From Nantes, France (ADSL, 20MB)
$ ping multijoo.no-ip.org64 bytes from 87.98.136.174: icmp_seq=0 ttl=55 time=50.227 ms
64 bytes from 87.98.136.174: icmp_seq=1 ttl=55 time=49.835 ms
64 bytes from 87.98.136.174: icmp_seq=2 ttl=55 time=51.263 ms
64 bytes from 87.98.136.174: icmp_seq=3 ttl=55 time=49.419 ms
64 bytes from 87.98.136.174: icmp_seq=4 ttl=55 time=50.414 ms
64 bytes from 87.98.136.174: icmp_seq=5 ttl=55 time=49.189 ms
64 bytes from 87.98.136.174: icmp_seq=6 ttl=55 time=52.966 ms
64 bytes from 87.98.136.174: icmp_seq=7 ttl=55 time=53.272 ms
64 bytes from 87.98.136.174: icmp_seq=8 ttl=55 time=51.676 ms
64 bytes from 87.98.136.174: icmp_seq=9 ttl=55 time=49.010 ms
64 bytes from 87.98.136.174: icmp_seq=10 ttl=55 time=48.700 ms
64 bytes from 87.98.136.174: icmp_seq=11 ttl=55 time=49.687 ms
64 bytes from 87.98.136.174: icmp_seq=12 ttl=55 time=48.878 ms
64 bytes from 87.98.136.174: icmp_seq=13 ttl=55 time=48.571 ms
64 bytes from 87.98.136.174: icmp_seq=14 ttl=55 time=51.362 ms
^C 15 packets transmitted, 15 packets received, 0% packet loss
round-trip min/avg/max/stddev = 48.571/50.298/53.272/1.455 ms
$ ping multijoo.no-ip.org64 bytes from 87.98.136.174: icmp_seq=0 ttl=55 time=50.227 ms
64 bytes from 87.98.136.174: icmp_seq=1 ttl=55 time=49.835 ms
64 bytes from 87.98.136.174: icmp_seq=2 ttl=55 time=51.263 ms
64 bytes from 87.98.136.174: icmp_seq=3 ttl=55 time=49.419 ms
64 bytes from 87.98.136.174: icmp_seq=4 ttl=55 time=50.414 ms
64 bytes from 87.98.136.174: icmp_seq=5 ttl=55 time=49.189 ms
64 bytes from 87.98.136.174: icmp_seq=6 ttl=55 time=52.966 ms
64 bytes from 87.98.136.174: icmp_seq=7 ttl=55 time=53.272 ms
64 bytes from 87.98.136.174: icmp_seq=8 ttl=55 time=51.676 ms
64 bytes from 87.98.136.174: icmp_seq=9 ttl=55 time=49.010 ms
64 bytes from 87.98.136.174: icmp_seq=10 ttl=55 time=48.700 ms
64 bytes from 87.98.136.174: icmp_seq=11 ttl=55 time=49.687 ms
64 bytes from 87.98.136.174: icmp_seq=12 ttl=55 time=48.878 ms
64 bytes from 87.98.136.174: icmp_seq=13 ttl=55 time=48.571 ms
64 bytes from 87.98.136.174: icmp_seq=14 ttl=55 time=51.362 ms
^C 15 packets transmitted, 15 packets received, 0% packet loss
round-trip min/avg/max/stddev = 48.571/50.298/53.272/1.455 ms
2009/1/16 Andres Martinez Quijano <tuls...@gmail.com>
nouknouk
Jan 19, 2009, 1:12:55 PM1/19/09
to PulpCore
Many thanks to everybody for your feedback. It just helped me a
lot :-)
I have to admit I expected far less latency than those presented above
(I thought it would reach at maximum 150ms ; compared to the 300ms
some people got).
As explained in myprevious post, my idea was to introduce a delay
between the moment of the player's input (when the players presses a
key to accelerate/decelerate or turn) and the moment where the action
is really taken in account.
In other words, the idea was to say "player p pressed key 'left' at
time t, but the car will really begin to turn only at time (t+x)
(value x being a constant value between 100ms - 300ms).
That way, if the value (x) is greater than the round trip time (RTT)
of the worst connection, everything can be deterministic (ie. for any
action of any player, the action is forwarded to all other players
before it has to be taken in account on the client side.
The good side of this idea is that there wouldn't need any prediction/
correction mechanism and no correction in remote player's moves would
happen.
The bad side of the same is that the car wouldn't be as responsive as
if everything was done in 'real time' (ie. a press on the 'left' key
would make the car turn immediatly). Indeed, this introduces a feeling
of 'inertia' of the car the player controls.
The goal of my tests was to find the value of (x) for which the
gameplay remains acceptable.
Unfortunately, it seems 300ms is far too much. The maximum should
better stand around 150-200ms.
Thus, I think I'll have to implement both techniques: delaying a
little bit the action (as explained above) and implementing a
prediction/correction algorithm for connections with a delay over (x)
values.
Here is the "state of the art" of my thought until now.
If you have any idea, advice, ..., don't hesitate :-)
Anyway, I'll try to put a sample applet somewhere asap.
Best regards,
Nouk²
lot :-)
I have to admit I expected far less latency than those presented above
(I thought it would reach at maximum 150ms ; compared to the 300ms
some people got).
As explained in myprevious post, my idea was to introduce a delay
between the moment of the player's input (when the players presses a
key to accelerate/decelerate or turn) and the moment where the action
is really taken in account.
In other words, the idea was to say "player p pressed key 'left' at
time t, but the car will really begin to turn only at time (t+x)
(value x being a constant value between 100ms - 300ms).
That way, if the value (x) is greater than the round trip time (RTT)
of the worst connection, everything can be deterministic (ie. for any
action of any player, the action is forwarded to all other players
before it has to be taken in account on the client side.
The good side of this idea is that there wouldn't need any prediction/
correction mechanism and no correction in remote player's moves would
happen.
The bad side of the same is that the car wouldn't be as responsive as
if everything was done in 'real time' (ie. a press on the 'left' key
would make the car turn immediatly). Indeed, this introduces a feeling
of 'inertia' of the car the player controls.
The goal of my tests was to find the value of (x) for which the
gameplay remains acceptable.
Unfortunately, it seems 300ms is far too much. The maximum should
better stand around 150-200ms.
Thus, I think I'll have to implement both techniques: delaying a
little bit the action (as explained above) and implementing a
prediction/correction algorithm for connections with a delay over (x)
values.
Here is the "state of the art" of my thought until now.
If you have any idea, advice, ..., don't hesitate :-)
Anyway, I'll try to put a sample applet somewhere asap.
Best regards,
Nouk²
Reply all
Reply to author
Forward
0 new messages