As matter of fact, overwriting the contents of one file with the contents of another is editing the file, even if it accomplished simply by using the DOS copy command, and even if the other file is included with the game.
I agree: If you add/remove/copy text lines in a file, you've edited the file, if you add/remove/copy files in a game, you've edited the game.
But what if you can cause file-corruption from within the game? I think that should be allowed. Maybe you could choose a game-save path that overwrites game files or something.
No matter where you go with this debate, you're always going to be treading in gray territory.
With a standard game console, things are very cut and dry. Those machines are designed to simply play games using the same hardware. As such, you are only provided with the tools to play games: power, reset, and a controller for input.
DOS was designed to run a varying range of programs on a varying range of hardware. As such, it has tools that allow a user to not only run programs but to modify the environment to support programs and different pieces of hardware.
So now the debate is what do we allow? For the most part, nearly every game will have to be looked at case-by-case. Let's run through a few possible scenarios with one game as an example.
Game A requires the DOS environment setup with certain memory settings, otherwise it refuses to load due to lack of memory. Being that there were a multitude of sound devices available at the time, it has support for 8 of the most popular models. The user is allowed to save/load a game from anywhere.
Scenario 1.) The game is loaded with the DOS environment variables required for normal play. During testing, it's found that by issuing a game save then resetting 3 frames into the save, it is possible to put garbage data into memory which can then be used to manipulate the best weapon at the start of the game and unlock characters required to immediately jump to the ending.
Scenario 2.) By choosing a certain sound device, the game becomes unstable and allows the user to pass through walls and obtain items seemingly out of thin-air. Apparently the sound device accesses areas of memory that are mapped for the game engine itself. Using this knowledge, the runner can manipulate his items by entering certain areas so the game loads a specific music file, writing the item in question directly to his inventory.
Scenario 3.) It is also found that a brute force method can be used to force the game to load without the correct DOS environment memory settings. Since the programmers never thought this could happen, and there are no in-game checks, the game barely plays like it was intended. Levels don't work as they should, walls can be passed through, the screen can be scrolled from one level to another and back again, enemies die seemingly from nothing. The ending is reached and the game completed in record time, being the only spot that plays like it normally would.
Yeah I know, these are some real oddball setups, but this is what we could run into with DOS games. Which one of these setups do we allow and which ones don't we allow?
How's this for another oddball scenario: Game A can be run only temporarily with certain DOS memory settings or it'll crash. However, in that time the user can bypass nearly half of the game (due to a bug in memory management) in a few seconds and has time to save/reset before the inevitable crash. Upon reloading with the correct DOS memory settings, the game plays like normal from the originally used save file.
Again, completely off the wall and it might not ever happen, but considering the huge library of games for DOS along with the never-ending list of crap programmers and even buggy hardware this *could* happen.
We could say that all games must be played in a "one session" style from start to finish, but that removes the ability to save-abuse. We could even say that all games can only run with certain hardware chosen from setup, but that stops us from using all of the tools provided with the game. We could say that the DOS environment can't be customized, which would solve some problems while creating others (endless situational rule clauses are one).
Like I said, huge gray area.
I largely agree with the "grey area" part, but there are two things I wish to add.
There's another, more important difference between consoles and PCs than the purpose they were designed for: games for consoles are usually delivered on a read-only medium.
The second point is that resetting during a save is not accurately emulated.
emulator: you hit "reset". Every write that's been issued by the program has already been passed to the filesystem on the host and will eventually be written to disk.
real PC: you hit "reset". Some data is lost in memory caches. Some more data is lost on the hard drive while it was waiting for the platters to rotate into position. Maybe a block was halfway written and is now permanently unreadable due to containing a wrong checksum.
As such, resetting a game while files are open for writing isn't emulated properly and shouldn't be used.
My opinion on the matter is that we shouldn't touch any file that's not explicitely marked as a configuration file, and even then only if it's either strictly needed (like for sound configuration) or produces a more interesting run (which is up to individual debate).
I think a lot of the gray area can be simplified by drawing equivalents to emulation as we already know it.
honorableJay wrote:
Scenario 1.) The game is loaded with the DOS environment variables required for normal play. During testing, it's found that by issuing a game save then resetting 3 frames into the save, it is possible to put garbage data into memory which can then be used to manipulate the best weapon at the start of the game and unlock characters required to immediately jump to the ending.
Scenario 2.) By choosing a certain sound device, the game becomes unstable and allows the user to pass through walls and obtain items seemingly out of thin-air. Apparently the sound device accesses areas of memory that are mapped for the game engine itself. Using this knowledge, the runner can manipulate his items by entering certain areas so the game loads a specific music file, writing the item in question directly to his inventory.
Scenario 3.) It is also found that a brute force method can be used to force the game to load without the correct DOS environment memory settings. Since the programmers never thought this could happen, and there are no in-game checks, the game barely plays like it was intended. Levels don't work as they should, walls can be passed through, the screen can be scrolled from one level to another and back again, enemies die seemingly from nothing. The ending is reached and the game completed in record time, being the only spot that plays like it normally would.
Scenario 1: Resetting an emulated file system in the middle of a write is probably not going to produce the same result as pulling the plug on an actual computer in the middle of a write. I would surmise that the former would be a bit more graceful in its approach.
Scenario 2: This is the equivalent of using a buggy sound plugin for an emulator. Think of the emulation of DOS as an emulator for the game itself. Modifying the operating system or its drivers is modifying a part of the emulator outside the game and shouldn't be permissible. Emulation strives for accuracy.
Scenario 3: Again, hacking the OS is like hacking the emulator playing the game and should not be allowed.
Also, modifying the file system behind the game is the same as using a hacked ROM. Configuring the software within the game, its loader apps, or for INI files that are intended to be edited is fine, though. That's like an options menu.
Now what if you put something in the INI that the game didn't anticipate and it causes havok? Well, back into the gray area we go. I didn't claim to solve all the potential issues, just to simplify them.
I see this one as a "uses a passcode to reach the final level". How many tas'es use that in here? None I think.
I'd say that people should use the closest approximate on what is closest to the intended gameplay.
1) Somewhat similiar trick is already used in the glitched CTrigger tas. It's up to you to make it work for others as well.
2) What I mentioned, People can use common sense to determine what is stable and 'intended' gameplay and what is not. Compare it to a real machine with proper equipment etc..
3) I'd put this in the same area as a superglitched tas. (link to the past, chrono, zelda2 etc..). But to this extent, I doubt that nobody really wants to watch it since at that point it loses the point of playing it at all. Chrono was cool since the time saved was huge and it already had existing runs. This was more like a proof-of-concept rather than a real tas. (That doesn't make it any less entertaining).
I'd say that these could be submitted as a little sidekick extras once a real run is out.
I think that each tas should start from a clean state.
Load the game and run it, no fiddling with other settings unless necessary for normal, intended gameplay (Making it work like it's playing it on a real 486 for example).
Again people can use common sense to determine what to setup and what not, maybe even upload the ini/cfg file that other runners can use the same setup for their improvements.
