I’m working to make my RTS deterministic for the purposes of replays and multiplayer, which is much easier if it only uses fixed point arithmetic for any game-relevant calculations.
Looking at this article Blogs recent news | Game Developer, They decided to get their game to throw an error whenever it detected imprecision from use of a floating point operation during development, to catch any accidental uses of floats so that they can be easily corrected before release. They used this system for identifying those mistakes: Exceptional Floating Point | Random ASCII – tech blog of Bruce Dawson
But that is written in C++ and Unity only uses C#, as far as I know. I thought it might be possible to import it into Unity in a DLL, but that isn’t something I’ve had to do before. I looked up some tutorials on wrapping C++ classes in a DLL and tried several different ways but I can’t get it to work. I’m betting that someone who actually knows what their doing would find this trivial.
I’m hoping someone on this forum will say, “Oh that’s easy, just do this…”
Maybe converting it from C++ to C# would be easier, I don’t know.
I’m not sure there would be much benefit porting the C++ code to C# if your main code is in C# already.
The reason is you’d still need to marshal all the data over to the C++ side to have it do whatever evaluation you want.
That article mentions just doing checksums on certain key values… I imagine that might be useful. If you checksummed all the unit positions and rotations each frame then sent that checksum as part of the input stream, you’d know the instant anything desynchronized.
Still might just be easier to have each local machine make extensive log outputs so you know precisely which unit desynchronized and when, at least during development. You would know this by comparing logs after the desync was detected.
The article describes a multi-pronged strategy to debugging a deterministic system. Checksums are one of those “prongs”, but they occur later in the process: When running the game and encountering desync bugs that can be detected with a checksum.
Much earlier in the process it describes a way to avoid absent-mindedly using floating point maths in your code: “…(his entire series of articles on floating point numbers is excellent), it includes some simple classes to help control which floating point exceptions are enabled [10]. One of the floating point exceptions that you can enable is called the inexact exception and it fires if a floating point operation produces a result which requires rounding.”
This would be caught long before an actual playtest that resulted in a desync. It would produce a red flag when compiling that could be easily fixed right there and then rather than needing to find it with a playtest checksum, then find the source of the desync by studying the checksum or the logs leading up to the desync.
Pretty much all the other “prongs” in the multi-pronged strategy in that article I have a handle on how to go about doing. But enabling the inexact exception is what I’m not so clear on.
It seems to be dependent on the code in [10] that he is talking about in the article. [10] links to this article: https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/