fraggle
Super Moderator
Posts: 6577
Registered: 07-00 |
fx02 contacted me by email a couple of days ago and mentioned what he's saying to me here. I've made it clear to him that I consider a closed source port would be (1) pointless and (2) a violation of the GPL, and something that I wouldn't agree to let my code be used for.
The problem of making verified demos like this is actually an interesting one, though, and I think it may actually be possible to make a workable scheme, though it might take a bit of work to pull off. I'll give a brief description of my idea.
Firstly, it seems like the biggest problem in terms of cheating is that of tool-assisted demos: for example, someone records the demo, but runs the game at half normal speed to give themselves an advantage, or uses a tool that allows them to record a demo in parts, replaying bits over and over again (I believe entryway once made a TAS demo where he played through the entirety of Doom II without being injured once).
It occurs to me that you can defeat this kind of cheating just by ensuring that the game must have been recorded within a particular timeframe. For example, if a demo is 3m24s long, and you can prove that it must have been recorded on a certain date within a specific 3m24s timeframe, then a tool-assisted cheat can't have been used.
Doom's game behavior is a deterministic state machine that easily goes out of sync if something is changed even slightly. We can make use of this: a pseudo-random number generator with a specific random seed can introduce a random element into the game: for example, adjusting the positions of all objects in the game by a fraction of a unit in a way that is imperceptible to the player but will cause the game to go out of sync if played back with the wrong seed.
Next you have a server on the Internet that responds to requests. When someone wants to record a verified demo, the Doom port sends a "start" message to the server, which replies with a random seed that it generates. This is used as the random seed for the game, which apart from the random element is otherwise recorded as normal. When the demo finishes, the Doom port sends an "end" message to the server, and includes the demo length and a cryptographic hash (eg. SHA1) of the demo contents. The server digitally signs the random seed, demo length and the hash and returns them back to the sender. These all get packaged up into a demo file.
A signed, verified demo file must have been recorded at that specific time, because:
- It can't have been recorded earlier and replayed (eg. through tool assist), because the game depends on the random seed that was returned by the server at that specific time. If it was recorded earlier, the game will go out of sync.
- It can't have been recorded at a reduced speed, because the server checks the demo length against the start and end times, and rejects the request if they don't match.
|
06-07-12 15:42 
