There is an option "Run relay" in setup, but I can choose only "don't run replay. What does it mean? I foun nothing about it in help file.
This is actually one of the reasons that I wish winsetup could be customized, because it's a somewhat broken, undocumented feature that pretty much nobody uses and it only confuses the end-user.
Press ALT+R during gameplay to start recording a replay, the press ALT+R again to stop recording and you'll be asked to supply a description and a file name. Having done this, you should be able to select your replay file in winsetup and start the game to run it.
Replays tend to get out of sync and break after a while though, which is also why it's not in the help file.
Thanks, it works well. Is there any command to start replay in middle of a game?
This sounds like a great testing feature, to have people test my game and then send me their "replay" files and I can watch how they played the game.
You can't start running a replay in the middle of the game, you have to quit and run Setup.
As GarageGothic says, this feature is unofficial because it has a bug where the replay gets out of sync, and I've never spent the time on it to fix it.
I know you're busy.. but you should work on that.. sometime. Anyway in the mean time we can use some screen recording tool or something..
I guess making it totally synch-ed is not as easy as it may sound, because game logic based on the number of game loops per second may well go differently on different systems or even on the same system the other time it runs; there is no guaranty that time intervals between calling repeatedly_execute, for instance, are exactly the same.
Edit: hmm, on the other hand the replay mechanism doesn't need to (actually must not) reproduce the making of logic decisions at all but just change the engine state sequentially, in which case the above may not be relevant here.
As I recall, the biggest problem was with blocking functions and dialogs, in which some of the engine is still running (enough to capture mouse position and clicking) but most of it is paused.
In theory the engine just needs to record its state whenever it's changed, so that it could be reproduced later on replay, something like this:
loop 0: move_character
turn_object_on
show_gui
loop 5: hide_gui
loop 9: stop_character
disable_walkable_area
loop X: etc
note: it's enough to save delta for loop number: loop 0 ... +5 ... +4 ... +etc
If the engine works in a single-threaded fashion this should be enough to define a deterministic behaviour of the game. Although maybe it has something to do with computation errors, such as with floating point operations or something similar which causes a game replay to run differently the other system you try it with, maybe.
Just my thoughts...
In fact, all that the replay feature does is record any user input (mouse moves, key presses) on each game frame. This works on the principal that the game logic is deterministic, so the only way to affect the game flow is if the user does something.
The replay feature does almost work, but there is a bug that can throw it out of sync in certain situations and I've never spent the time to track it down and fix it.
So does the engine redo logic decisions each time replay runs?
If so, what happens with functions that return volatile values, eg: DateTime.RawTime or Random (with maybe a different seed value) or some if_file_exists, etc... , ie. such that doesn't rely on the user input but on the current state of the system?
Presumably, that is part of the reason the feature's incomplete. ;)
EDIT - Anyway, even as-is the feature can be useful. Start a quick 1-second replay anywhere, and it seems you'll automatically be transported to that part of the game when replaying it. Great for testing, beats save-games.
Yeah, and having the ability to make visual walkthroughs would be just awesome, surely not a complete replacement for text-based solutions which have their own pros, but to watch a game from a different perspective of another player -- movie mode! :)
Random() is handled correctly because when you start recording the replay, the random number generator is re-seeded and that seed is stored in the replay file.
However, any other external inputs such as whether a file exists could lead to out of sync issues if the game used that information to make a logic decision.
Ah ok I see. I doubt one of these is actually a major reason why it gets out of sync anyway.
Major reason are dialogs... Don't think blocking stuff like "Display" is a biggie, but in dialogs, from previous attempts at recording, there are definitely problems.
Hmm, quite possible I can imagine; it may probably have something to do with the fact that in dialogs the engine is stopped (no game frames are running) but the user input is constantly polled to update its state.
Anyway, it's just a guess from my side...
By the way, games invoking plugin functions (both: returning-something and state-changing) may also cause troubles for replay unless these plugin functions are handled properly from within the plugin itself (API should then provide means to handle the situation, ie. is_in_replay_mode), and that's yet another hassle to deal with, unfortunately.