It's a combination of (a) people straight up exploiting the fact that the server trusts that the data sent from the client is correct, (b) some truncation error that happens when the system is saved for replay may lead to a different final outcome when replayed (the systems may be highly chaotic), or (c) a bug that I haven't been able to reproduce yet.
(a) is something I struggle with coming up with a good solution. People can just enter the Javascript console and mess with the internals (change points, multipliers, etc.). When the data is sent to the server, the server cannot re-run the entire integration, it is too computationally expensive (almost 4,000,000 games played!). So what I do is do some basic checks on the server, loop over & reject systems that are clearly fake, ban IPs that are obviously trying to exploit the high score table, and call it a day since I cannot be monitoring the high-score table all the time. As I wrote in another comment, they are all fake internet points anyway, so I'm not too concerned. If anyone has a better idea, my email is [email protected] -- drop me a line.
(b) is a feature inherent to the N-body problem, so not much can be done on that front.
(c) I still haven't come across a system that I created on my testing environment (that I save with some extra debug information), that behaves differently when replayed.
I should add that the entirety of the code will be published on GitHub, like my other projects (http://github.com/stefano-meschiari/), so people should feel free to fork, make pull requests, etc.
If anyone likes what I do, I will be available soon for freelancing. I have a small portfolio of applications I built here:
http://www.stefanom.org/devel/
I am applying for funding to develop a more comprehensive educational application. Hopefully the success of the game will give my application some extra clout.
The simulation is always done with the same time resolution (time step). What the speed factor does is just change how many integration steps are taken between frames, so speed should indeed not affect the evolution.
Soneca, there are a few links on the sidebar. My hope is that people will look for answers among the many excellent resources that are already available online. I also hope to develop the game further to make the physics that drives the planetary dynamics a little more clear.
It is a simple leapfrog integrator (which is indeed symplectic). I found that, at least in a test implementation, higher order methods were too computationally expensive to run the simulation at a good frame rate.
I definitely took a shortcut there. I'm not a professional programmer, and any time I dedicate to this I tend to consider as "stealing" my attention from my actual job as an astrophysicist...
I'll do a bit of testing and see what I can come up with.
Admittedly, the point system could have been better designed. However, for this first attempt, I could not come up with a better alternative. "Exploiting" the point system within the game is not that easy, so the people that achieved the high-scores must have played tens, if not hundreds or more, of games before finding the right timing and initial condition.
I am the developer of the game (StefanoM). I'm glad people are enjoying the game, and I'm sorry for the downtime -- I did not expect it to become this popular.
If you have any improvements or suggestions (especially on the programming side!), please email me directly.
Update: As an astronomer (and not a professional programmer), being on HN makes me super proud. Thank you!