Changes between Initial Version and Version 1 of SimulationRequirements

Timestamp:

Oct 21, 2009, 6:07:27 PM (15 years ago)

Author:

Philip Taylor

Comment:

initial rough ideas

SimulationRequirements

@@ +1 @@
+== High-level simulation system requirements ==
+
+=== Security ===
+
+Players should be able to download maps and mods (which can contain simulation scripts) and run them without any risk of compromising their computer's security - the scripts should be sandboxed within the game engine.
+
+(This is independent of any concerns about cheating in multiplayer games.)
+
+Obviously anything like file IO APIs should be carefully controlled (and preferably should not be exposed to simulation scripts at all). Functions that expose engine functionality to scripts should validate all inputs, and should not trust the rest of the engine to be secure with unrestricted input.
+
+It should be impossible for a script to cause the game to crash in any way - the code needs to protect itself against malicious scripts. All crashes should be considered security issues and fixed, even if they seem like harmless null pointer dereferences. `debug_assert` is not adequate for preventing crashes, since users will just click 'continue' and expose themselves to whatever dangers it was trying to protect against.
+
+In extreme unrecoverable cases like resource exhaustion, the game should (safely) terminate.
+
+=== Cheat prevention ===
+
+???
+
+=== 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.
+
+Guaranteeing determinism in JS seems to be infeasible. E.g. 32-bit and 64-bit versions of !SpiderMonkey probably(?) have different ranges for integers, and a script could detect whether the interpreter switched from ints to doubles for large numbers. 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.