I have some questions:
- If have a game but got on to some deviecs by offical. Gameplay maybe not change or have something changed (ex: MK1/MK2/MK3 on fews devices). Then how to identified TAS for it? Faster is better? But if gameplay was changed can help beat game fast more than, then is it fair?. If not compare with same game but on other devices then with a game can make alot TAS but don't have many difference
- With a game allow use cheat code for make game have hard more than in options (ex: PSX Bloody Road 2), then is it allow for make TAS ?
- With a fighting game, without playaround, 100% combos tag have difference with beat game fast any cost? because many game can make 100% combos but not sure it can help beat game faster. I don't think it have entertaiment enough, because it'll alway repeat many times.
So, you mean: if a fighting game is on many different consoles, for example the original Mortal Kombat that is on SNES, Genesis, Arcade, etc... how do you define the best port which to use for TASing?
It is often a game-specific decision. If there is enough difference between ports, I'd say both games count as their own category. If there isn't much difference, like SNES and Genesis Mortal Kombat, then it is difficult to estimate which is better. If other port has some new glitch or a little mechanics change that allows a faster completion, I'd say that the faster port should be preferred.
Using an in-game password or a cheat code to unlock a special difficulty is allowed, at least in some cases.
A speed TAS of a fighting game need not worry about entertainment at all. All that matters is that is is fast.
Yo yo, I'm back with some questions:
- with some games can open special/hidden characters in options, then is it allow make TAS?
- with some games can gain power/damage in options, then is it allow make TAS?
- with some games can open special/hidden characters by gamesaves, then is it allow make TAS? (I saw Richter in Castlevania: Symphony of the Night but not sure other games).
Yes.
Yes.
Yes.
Everytime the run will be different than the normal version, it is completely fine if you use different characters or secret weapons you obtain after beating a game, etc.
In most cases, it must be a game that creates a SRAM file after you complete the game, or so. You record a movie that creates that SRAM file (can be unoptimized), then start a new movie where the game works as after you completed it, it knows it from the SRAM file.
I don't even know which games allow such "post completion" mode and don't use SRAM, but require to do regular savestates. But if there is such a game, you well need to make a verification movie to the needed point, save a state at certain frame and start a new movie from that savestate. Then the judge replays the first movie to that frame and makes a savestate too. If it's hash is the same as for your saverstate, then your target movie is valid.
It happened that a SRAM or a savestate may be hacked in order to cheat, so we need to verify the states you make "post completion" runs from.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
but I didn't understand if make submissions, where file save/SRAM for all ppl check/watch/encode
btw, make new movie not reset data game at all ? I didn't know this
In most cases, it must be a game that creates a SRAM file after you complete the game, or so. You record a movie that creates that SRAM file (can be unoptimized), then start a new movie where the game works as after you completed it, it knows it from the SRAM file.
I don't even know which games allow such "post completion" mode and don't use SRAM, but require to do regular savestates. But if there is such a game, you well need to make a verification movie to the needed point, save a state at certain frame and start a new movie from that savestate. Then the judge replays the first movie to that frame and makes a savestate too. If it's hash is the same as for your saverstate, then your target movie is valid.
I'm not really fully understand.
With my poor brain can understand, if I want unlock any secrets by beat game, I need beat game for them, then start record movie at beginning for make TAS. Is it right? But how about the movie run after I have shutdown emulator?
another question. My nick xxNKxx possible change to N?K? ^^
I'm not really fully understand.
With my poor brain can understand, if I want unlock any secrets by beat game, I need beat game for them, then start record movie at beginning for make TAS. Is it right? But how about the movie run after I have shutdown emulator?
Don't you resume your work the other day? You start a run, save a state, close emulator. Open it again, turn on read+write and load your state. You are back into your movie.
As for SRAM file that has the completion state, it doesn't get removed when you close the emulator, so it reads that file as many times as you start the other mode.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Yes, or they watch the verification movie. However some emulators store SRAM into movies already too.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
