Posted 31 October 2009 - 05:08 PM
Not a real bad example, but not good either. It does what it's supposed to do, but I wouldn't call it an engine, which is a word that has lost all meaning on the GMC. An engine really provides the user with extra functionality, usually in a user friendly way that can be implemented and plugged into existing game concepts almost universally.
This is not an engine, it's an example of the concept of saving and loading player actions, and an extremely basic and inefficient one that fails to take many things into account. If you named it like that, I'd say, great example that does what it says.
Anyway, the concept is pretty solid, but the execution fails. Quite a few games do it like this, but they're not using slow writing features every step. Quite frankly, in a large game where there's a hundred objects that need updating every step, you're probably better off using a low-level written fast application like Fraps to save an image of the screen instead of using a high level slow application like GM to save thousands of values every second.
Your example works cause there's a player that can write at most 4 values at any one step. If you have a hundred NPCs, inventories that change, bullets that fly around etc, you're writing lots of information every step using very slow file writing functions. In addition, as you're writing a whole line for a single value, you're creating megabytes of data for a few minutes of playing in larger games. Sending just action indexes would reduce your playback size by maybe 20 times.
A proper engine does not use execute_file (which is extremely dangerous as you can simply execute GML as the player). A proper engine does not write a line of GML for every value, but rather only writes binary data of the index numbers you use for specific events using binary writing and reading DLLs that are much faster, it saves seeds for random functions, and offers the option to not write data every step but rather buffers it into say a datastructure to be written at intervals or game end.
It's absolutely recommended to NOT use the code you wrote for any serious playback feature. The underlying concept works, but your execution does not. It's not an engine and putting HD infront of it makes no sense as you're not recording graphical data. It's also not a super small filesize, recording for 5 minutes in a larger game would be huge. It's like me saying "save images using just 1 kilobyte!' and make an example that saves a 1-pixel image. It's not realistic for larger projects.
It's a misleadingly named inefficient example that uses slow features to write and read 20x as much data (GML) as needed every step and then uses the dangerous execute_file to replay a fraction of what you'd see in a regular game situation.
Which is fine, cause it shows a concept, just don't make it out to be anything but that and warn people that it's NOT an engine, does NOT save 'super small files', has NOTHING to do with HD and that it must be heavily optimized and rewritten and that this just shows a small quick example of a replay technique. Hope I didn't discourage you or insult you, replay engines are really interesting, I hope you'll continue to improve this.