(May the mods forgive me for opening yet another PC TAS topic. I'm new here.)
I decided to take a break from
solving Kwirk and try something different: I created a TAS "mod" for a Windows mini-game (Cryptic Sea's "No Quarter: V-Sides", and specifically the "Hitlers Must Die" preview it contains).
I've posted details and the TAS video itself
on my website, so I'm not going to repost the same content here. Apologies for the horrible web design.
Binaries aren't currently available because I have selfishly used a proprietary commercial hooking library. Perhaps I'll eventually rewrite it to remove that limitation.
Anyway, this isn't as much of an achievement as it is a basic example demonstrating that TASing some PC games is possible to do in a clean, deterministic, legal way that doesn't require enormous overhead due to emulation. Surely, there are a lot of 'if's with this model - the TAS extension would have to manage all resources that are allocated/destroyed by the game during the course of a replay, such as heap objects, handles, video surfaces, etc. - however, as this example shows, this may not even be necessary.
Another thing: there are a few popular game-oriented virtual machines such as Game Maker and Multimedia Fusion. Creating a generic TAS system for such a VM would allow TASing all games created with that system.
This approach at TASing PC games has several advantages over the more generic ideas of using hardware-level virtualization software, such as VMware or QEMU. The first and obvious advantage is speed - there is no virtualization overhead. Save-states are large and contain memory that's not directly related to the game (loaded OS files, filesystem cache, etc. - most often even free memory is dumped as the VM doesn't understand the OS' memory management). Replays themselves could be unnecessarily large, as they'd have to contain detailed input from all input devices. Timing is another problem - the VM software couldn't understand game input frames, so you wouldn't have discrete "frames", each with its own input state, but rather have a continuous time range and you would place input events across it, and try to guess which points in this time range would affect the game over its previous "logic" frame, which I would imagine would be extremely tedious unless it is somehow magically automated. And don't forget about input delay - it does take a while for input to get propagated from the hardware all the way down to the game logic code, passing through multiple layers of BIOS/kernel/game code.
So, I really think that my approach is The Way To Go. Obviously, there need to be some restrictions. My suggestions:
1) The parts of the TAS extension software directly related to TAS must be entirely open-source (it should be allowed to use closed-source but freely-available 3rd-party libraries, including compiler runtimes)
2) The TAS extension software must be buildable using freely-available tools
3) The TAS extension source code should have a high level of readability and maintainability (clean, commented code)
4) If reverse-engineering (decompilation, disassembly) was involved in the development of the TAS extension, it must be accompanied by a written permission from the game author/copyright holder
(Note: using a hex editor or looking at the import table is not commonly considered as reverse-engineering. IANAL.)
Thoughts?
