I’ve made a very simple and primitive JavaScript canvas engine that is simply not dependent on time, as in it assumes that t = 1 in the formula v = u + at - v is the current velocity, u the initial velocity and a is acceleration due to gravity.

Now, the issue with this method is that if the value of gravity, or velocity is large enough that the object it should collide, it just goes right through it. Now, I have been told that if time was a parameter, we could just increase the frame rate and dilate the time to resolve this, but this would mean that the engine would no longer be deterministic - as in, the simulation would not work out the exact as it we assumed it to be, owing to hardware and software requirement like decimal point handling and precision.

How can we deal with this issue on this simple deterministic engine, and improve collision detection?

  • WolfLink@sh.itjust.works
    2·
    4 days ago

    A few ideas:

    1. Instead of doing only one “update” per frame, do multiple smaller updates per frame. This doesn’t completely solve the issue but it does decrease the threshold of how small an object can be before this becomes a problem.
    2. Compute a region between the before and after locations, and detect if the collision object intersects that region. Then if there is an intersection you have to compute where the object would have intersected it, which is going to be a bit more complicated, depending on the shape of the bounding regions you are using.
    3. Just ignore the problem. Many games have this bug, but design their game so it only becomes noticeable in rare edge cases.

    I’m not sure what you mean about decimal point handling - that’s always going on (unless you are trying to work with purely integer variable? Even then, there’s rounding involved whenever you need to divide…)

    I’m also not sure what you mean by the engine becoming “nondeterministic”.

    • LalSalaamComrade@lemmy.mlOP
      2·
      4 days ago

      Here’s what I’m trying to implement - a plinkoo game. Disclaimer: I’m not into, or promote gambling, just wanted to use my knowledge of Monte-Carlo simulation on a toy project to figure out the pre-computed starting points, because client-side physics engine can be spoofed.

      Now, this engine has to be “deterministic” at all cost, even at the cost of frame rates. Now, in my current scenario, gravity is fixed, however, the issue with larger gravity is that the object just phases through the obstacles.

      This is why I was looking for a better solution, at least something that isn’t CPU-bound, because as I create more and more object, it hogs the memory, although not a lot, but it would hurt mobile devices (I think I should probably destroy objects after it reaches the bucket).

      So far, I’ve considered using VanJS to avoid the ReactJS virtual DOM overhead.

      • WolfLink@sh.itjust.works
        1·
        4 days ago

        So here’s the thing that confuses me about your use of the word “deterministic”: even if you have balls phasing through collision objects, the game will still be deterministic in the sense that the same initial conditions for the ball will result in the same final location of the ball.

        Ways that it can become non-deterministic are usually either intentional randomness, race conditions from multithreading, or using a variable time delta for your update cycle, such that the time delta is dependent on the operating system, physical device, etc.

        As long as you aren’t doing any of those things, the game will still be “deterministic”.