Re: How do you write tests if you aren't sure what the result should be?

Hi Avi,

yes, I think the solution described in that article will solve this 
problem and is a good way to do it.

But the other option should be ok, too.

I use something very simple like this:

x += velocity.x * deltaMs;

where
  deltaMs is the number of milliseconds since the last frame and
  velocity.x is the velocity in x direction for one millisecond.

The framerate is implicitly defined by deltaMs. So this call
physics.update( 1000 / 30 );
will test results as if the game would run with 30 frames per second. 
When that test works, the simulation will work for higher framerates, too.

For simple simulations with a reasonable framerate like most games this 
is ok, I think. For smaller framerates it will at some point look jaggy 
of course, but that has to happen.

Best,
Stefan


Am 16.02.2013 20:47, schrieb Avi Kessner:
> In the case of a flying penguin it doesn't work.
> The basic formula for the penguin flying through the air is  x += dt + v
> If this is calculated 30 times per second you basically get x += dt +
> 30v,   but if you calculate it  32 times per second, you get  x +=
> (dt*0.937) + 32v
>
> And in reality, you get a range of say 28-34 fps with it changing every frame.
> That's why I thought it was a sort of heisenberg problem.  I can
> either fix the time it takes, or I can fix the distance it goes, but I
> can't have both be variable.    Using the idea that "The renderer
> produces time and the simulation consumes it in discrete dt sized
> chunks." seems like it will solve the problem, because I can then
> right tests for different amounts of times produced and consumed and
> make sure they are equal.
>
> brought to you by the letters A, V, and I
> and the number 47
>
>
> On Sat, Feb 16, 2013 at 9:27 PM, sh <[email protected]> wrote:
>> Avi,
>>
>> the first option should work. When your test is ok for 30 fps, you can
>> safely assume that it will work for higher framerates.
>>
>> Best,
>> Stefan
>>
>> Am 16.02.2013 20:07, schrieb Avi Kessner:
>>> The first option won't work, because a 30 to 60 fps has to be assumed.
>>>
>>> That second option might be what is needed however.  However, not the
>>> fixed time step but rather the  "
>>>
>>> Free the physics" section.  "So what we want is the best of both
>>> worlds: a fixed delta time value for the simulation plus the ability
>>> to render at different framerates. These two things seem completely at
>>> odds, and they are – unless we can find a way to decouple the
>>> simulation and rendering framerates."
>>>
>>>
>>> brought to you by the letters A, V, and I
>>> and the number 47
>>>
>>>
>>> On Sat, Feb 16, 2013 at 7:58 PM, sh <[email protected]> wrote:
>>>> I don't think this is very heisenbergish... :)
>>>>
>>>> The first option is to assume a sensible minimum framerate (perhaps 30
>>>> FPS) and make that a specification for your game. (With 10 FPS it
>>>> probably won't be fun anyway.)
>>>> Then make the framerate a variable in your tests: physics.update(
>>>> variableTimestepInMilliseconds );
>>>> This makes the code testable for a given framerate. Of course higher
>>>> framerates will deliver a small variation in the calculations, but that
>>>> shouldn't mess up the behaviour of the engine.
>>>>
>>>> The second option is a fixed timestep for your physics calculations as
>>>> is described here: http://gafferongames.com/game-physics/fix-your-timestep/
>>>>
>>>> Best,
>>>> Stefan
>>>>
>>>>
>>>>
>>>>
>>>> Am 16.02.2013 17:49, schrieb Avi Kessner:
>>>>> Yes, the code is the same.
>>>>>
>>>>> See
>>>>> http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html  from
>>>>> http://news.ycombinator.com/item?id=4934855
>>>>>      for another example, where how accurate your timer or framerate is can
>>>>> affect the results of the tests.
>>>>>
>>>>> In the gravity example, if I run the equation as if the user has 10 frames
>>>>> per second, I will get different results than if they run at 60 frames per
>>>>> second.
>>>>> Granted this is partially a problem with the code, but it should still be
>>>>> testable.
>>>>>
>>>>> Perhaps this is the Heisenberg of unit testing?
>>>>>
>>>>>
>>>>>
>>>>> brought to you by the letters A, V, and I
>>>>> and the number 47
>>>>>
>>>>>
>>>>> On Fri, Feb 15, 2013 at 10:40 PM, George Dinwiddie
>>>>> <[email protected]>wrote:
>>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
> brought to you by the letters A, V, and I
> and the number 47
>
>
> On Sat, Feb 16, 2013 at 9:27 PM, sh <[email protected]> wrote:
>> Avi,
>>
>> the first option should work. When your test is ok for 30 fps, you can
>> safely assume that it will work for higher framerates.
>>
>> Best,
>> Stefan
>>
>> Am 16.02.2013 20:07, schrieb Avi Kessner:
>>> The first option won't work, because a 30 to 60 fps has to be assumed.
>>>
>>> That second option might be what is needed however.  However, not the
>>> fixed time step but rather the  "
>>>
>>> Free the physics" section.  "So what we want is the best of both
>>> worlds: a fixed delta time value for the simulation plus the ability
>>> to render at different framerates. These two things seem completely at
>>> odds, and they are – unless we can find a way to decouple the
>>> simulation and rendering framerates."
>>>
>>>
>>> brought to you by the letters A, V, and I
>>> and the number 47
>>>
>>>
>>> On Sat, Feb 16, 2013 at 7:58 PM, sh <[email protected]> wrote:
>>>> I don't think this is very heisenbergish... :)
>>>>
>>>> The first option is to assume a sensible minimum framerate (perhaps 30
>>>> FPS) and make that a specification for your game. (With 10 FPS it
>>>> probably won't be fun anyway.)
>>>> Then make the framerate a variable in your tests: physics.update(
>>>> variableTimestepInMilliseconds );
>>>> This makes the code testable for a given framerate. Of course higher
>>>> framerates will deliver a small variation in the calculations, but that
>>>> shouldn't mess up the behaviour of the engine.
>>>>
>>>> The second option is a fixed timestep for your physics calculations as
>>>> is described here: http://gafferongames.com/game-physics/fix-your-timestep/
>>>>
>>>> Best,
>>>> Stefan
>>>>
>>>>
>>>>
>>>>
>>>> Am 16.02.2013 17:49, schrieb Avi Kessner:
>>>>> Yes, the code is the same.
>>>>>
>>>>> See
>>>>> http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html  from
>>>>> http://news.ycombinator.com/item?id=4934855
>>>>>      for another example, where how accurate your timer or framerate is can
>>>>> affect the results of the tests.
>>>>>
>>>>> In the gravity example, if I run the equation as if the user has 10 frames
>>>>> per second, I will get different results than if they run at 60 frames per
>>>>> second.
>>>>> Granted this is partially a problem with the code, but it should still be
>>>>> testable.
>>>>>
>>>>> Perhaps this is the Heisenberg of unit testing?
>>>>>
>>>>>
>>>>>
>>>>> brought to you by the letters A, V, and I
>>>>> and the number 47
>>>>>
>>>>>
>>>>> On Fri, Feb 15, 2013 at 10:40 PM, George Dinwiddie
>>>>> <[email protected]>wrote:
>>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/