|Version 2 (modified by Philip, 4 years ago) (diff)|
High-level simulation system requirements
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.
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 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.