Re: [Algorithms] Network prediction algorithms specific to racing?

[Megan F. <sha...@gm...>]

At present, we have a fairly terrible scheme that amounts to no real
rectification or prediction AND a dead-space that allows out-of-sync
conditions to get around how jumpy it would be without it.  Not so
good.  I was pulled off my other tasks and re-assigned to make it not
suck / take it to polished instead of prototype, basically.

My suspicion is that dead reckoning (ie. like you say, simple
extrapolation from last known pos/vel) will be "ok", but that it will
tend to not produce the smooth arcs I'd like to see in a cart racer.
I'm also not convinced that a second or third degree prediction from
sampling the prior positions would be anywhere near usable if the
player ever deviated from smooth arc driving.  So, just thought I'd
see if there were any particular known-better-case solutions, given
that it's a well-trodden domain.

On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes
<jh...@st...> wrote:
> I guess there are two aspects of this: prediction and visual rectification.
>
> We've been doing a networked basketball game recently, where one team is
> entirely controlled remotely.  Even with fairly high latency, slow
> moving objects (like players) will look okay using a smooth
> rectification algorithm, but they're a little delayed from real-time.
> High velocity objects  (ie. bullets or ballistic objects) are pretty
> easy to sync as well, provided they are not controlled or intelligent.
> The main issues we've had thus far involve rectifying the ball physical
> state after a collision with a player, since that's often incorrect and
> delayed.  Luckily, most collisions in basketball games result in the
> ball being grabbed, so this isn't always an issue.  For reference, our
> simple rectification code is X = Lerp(X, X', f), where f could vary
> depending on the latency and current error.  Spline rectification would
> be nicer, and we might implement that, though it may be overkill for us.
>
> I haven't tried prediction beyond simple linear extrapolation based on
> the last single sample (position, velocity, orientation).  1st order
> prediction would likely close most of the gaps for generally smooth
> functions like position and orientation, but for velocity, I'm not sure
> it would help in our case, since the velocity is basically joystick
> angle for us and is generally discontinuous.
>
> Sorry I can't be more help with racing specifically.  Out of curiosity,
> what have you tried and how did it work?
>
> Thanks,
> JH
>
> Jason Hughes
> President
> Steel Penny Games, Inc.
> Austin, TX
>
>
> On 4/15/2010 3:34 PM, Megan Fox wrote:
>> I'm currently fiddling with dead reckoning for a racing game I'm
>> working on, but this seems like a specific enough domain that there
>> ought to be specific-to-racing prediction approaches.  We have a
>> fairly good idea of what the player is doing (trying to stay on the
>> track), and that would seem to give more data that isn't really being
>> exploited with standard approaches - but googling isn't turning up
>> much.
>>
>> Do such algorithms exist?  Or, in practice, are the same approaches
>> used in FPSes et al still the ones to use here?
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Megan Fox
http://www.shalinor.com/