Question: Deterministic simulation

[schell]

There are lots of 2d physics engines out there and a couple already have Haskell bindings (box2d, chipmunk). These are both battle tested and proven technologies. I don’t think shapes can compete with them in a standard “technology pull” project environment (one where the tech is picked based on the needs of the project). Asking a game developer to write their game in Haskell is a hard sell. So what can Haskell do that other languages cannot? Haskell can guarantee reproducible results through referential transparency. Shapes already does this to a certain extent - it’s pure, so one set of inputs should always give you the same output, but the implementation of some underlying floating point operations (1) are platform dependent! Simulations on different machines or different build targets may produce different results. Would it be worth it to use the techniques outlined by Joachim Breitner (@nomeata) in section 5.1 of this paper to ensure deterministic simulation under all circumstances?

Pro

• Gives shapes and Haskell a reason to be used above all other tech stacks.
• I think this space is bigger and more fun than it seems at first.

Con

• Lots of work
• Will be slower at runtime

Fun to think about, none the less.

(1) - transcendental functions like exp, sin, cos, log, etc.

[ublubu]

I'd have to agree on the point about not being able to compete with box2d and friends.

I think it'd be cool to have something like a reproducible physics/game-math engine to run multiple clients in lock-step across the network. (without continuously syncing the whole world-state) Maybe with some kind of backtracking or prediction to deal with latency between players.

I feel like I remember that floating-point has other inconsistencies as well (beyond sin/cos/etc). Maybe some kind of fixed-point is the way to go.

[ublubu]

Another comment: It's been difficult to figure out what direction to take shapes since I don't have a game (or other application) for it in mind.

[schell]

I think with the type class abstractions you have going we could easily do two versions - one with this repeatable deterministic outcome and one without. Then we could benchmark each and weigh the costs...