Changes between Version 2 and Version 3 of SimulationRequirements

Timestamp:

Nov 15, 2009, 12:19:48 PM (14 years ago)

Author:

Philip Taylor

Comment:

--

SimulationRequirements

@@ -19 +19 @@
 === Determinism ===
 
-By "determinism", we mean that given a certain simulation state, and a certain sequence of inputs, and a certain set of scripts and data files, the subsequent simulation states are precisely determined. (That is, the simulation should not be affected by external inputs, timings, hardware, OS, compiler settings, etc). That's necessary for the multiplayer system to work.
+By "determinism", we mean that given a certain simulation state, and a certain sequence of inputs, and a certain set of scripts and data files, the subsequent simulation states are precisely determined. That is, the simulation must not be affected by external inputs, timings, hardware, OS, compiler settings, etc. That's necessary for the multiplayer system to work, otherwise players will have out-of-sync views of the world and their views will diverge.
 
-Guaranteeing determinism in JS seems to be very hard to do perfectly, e.g. scripts could trigger out-of-memory errors that vary between instances of SpiderMonkey. It would also require much stricter isolation between simulation and GUI, making any interactions more complex.
+''Guaranteeing'' determinism in JS seems to be very hard to do perfectly, e.g. scripts could trigger out-of-memory errors that vary between instances of !SpiderMonkey. It would also require much stricter isolation between simulation and GUI, making any interactions more complex.
 
 The goal should instead be to ensure non-malicious scripts will be deterministic, by minimising the opportunities for non-determinism. `Math.random` should be replaced with a network-synchronised RNG. Trigonometric functions should be carefully examined, and modified or removed, if they are not consistent between platforms. Any engine functions exposed to scripts must take care of determinism themselves.
 
-Floating-point computations in C++ are considered unacceptable here (different compiler optimisations will subtly change the computations); all values passed to and from scripts should be integers and fixed-point numbers.
+Floating-point computations in C++ are considered unacceptable here (different compiler optimisations will subtly change their behaviour); all values passed to and from scripts should be integers and fixed-point numbers, and all intermediate computations exposed to simulation code should be integers and fixed-point. (Scripts themselves can use JS's floating-point Number type.)
+
+Error situations (can't open data file, can't allocate new JS object, etc) may cause non-deterministic behaviour, but the error must be logged so we can debug out-of-sync errors.