I have an idea for a new form of TAS, where two TASers play a 2-player competitive game (say, a fighting game, or a racing game).
The idea is that the game would be mediated by some sort of web service. Each player would submit their input to the web service, one frame at a time. Once a player has submitted (and committed to) a certain input for frame T, the other player's input for time T-6 would be revealed.
You could take as long as you wanted to submit your input, and use whatever methods you wanted to come up with it. (For instance, you would probably want to guess what the other player will do, and run simulations as to how your strategy will work.) The only thing you can't do is change your input once you've committed to it.
The main reason for the delay in the above description (where you get the other player's input after a 7 frame delay) is that it speeds up the process. For example, if the two players can't manage to be TASing at the same time, and want the maximum information available, then each TASer can provide 14 frames of input per session. (Player A will commit to inputs from T-7 to T+6; then player B will commit to inputs from T to T+13; then player A will commit from T+7 to T+20, etc.) With the minimum possible delay, where you see the other player's input for frame T as soon as you commit to frame T, then each player can only provide 2 frames of input per session.
Does this sound like an interesting idea to anyone else?
This could be done much easier. You should write an external program that handles the connection between A and B.
Both of them loads up the same emulator with the same settings and the same rom. When they start the game, both of them has a limited time to make an input at every frame. At the end of the current frame, A sends his input to B via the external program (that hooks the buttons pressed in the emulator) and vice-versa. This method will work if the emulator and the game has no desyncs.
Of course you can elaborate this with comparing checksums and "game state" at various frames to ensure it's really syncs and an "end game state" to verify the winner of the game. Also note that this method enables TASers to use LUA scripts and nearly anything that possible within the limited time (even the use of the "restart" input on various consoles, not to mention savestates (just simply handle these with the external program)).
edit: here's an illustration. also a side note about the web service method: it's only neccessary if you want to restrict TAS features entirely, which is actually the opposite of what TASing really is.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
MUGG, Patashu, thanks for the references.
MESHUGGAH, I don't understand the big difference between your idea and mine... your suggestion seems to be a slight refinement.
You have a timeout, I didn't; that could be a configurable option when starting a match. You have some automation in the "external program"; that would be very nice, but isn't essential to my idea and is a lot more work, so I didn't mention it.
The biggest difference seems to be that your programs communicate peer-to-peer, and my idea was to go through a web service. This doesn't actually seem to be a very big difference to me. The peer-to-peer version will probably require one or both players to mess with their firewall, so that argues in favor of the web service.
Also, with the web service, it would be easier to add a feature where other people (with their emulators) could watch a match in progress.
And I totally don't understand this sentence about the web service: "it's only neccessary if you want to restrict TAS features entirely, which is actually the opposite of what TASing really is." How on earth does sending moves to the other player by way of a web service intermediary "restrict TAS features" as compared to sending them directly?
edit: I forgot the main reason for the web service: to prevent cheating. You rely on the players sending each other their input at the same time. I don't see how to keep one player from hacking their "external program" and consistently sending their move a tenth of a second after receiving the other player's move, with a bot that picks a response based on that move. (A cheating player behind a fast internet connection would look just like a non-cheating player behind a slow internet connection.)
As long as both players trust the web service, then they don't have to worry about this form of cheating.
Sorry if I misunderstood you cwitty, but I still don't know what's your conception.
If I'm correct, you want to make a "gaming on demand" type of service where the TASers only get the "media" (this means you have no access to the memory, can't do any LUA scripts and I don't even want to think about copyright issues).
The disadvantages of gaming on demand is hosting at least one server (money), making a lot of scripts for various emulators to get the most desired settings, restricting TAS features (short note: not everyone has high-speed internet, so it would be a pain to send and recieve HUGE packets at short intervals. that's why I recommend P2P+external program to send only the required inputs which results in VERY small packets).
At my method, the only disadvantage I can think of is that you can decode your enemies inputs/packets (but you can't alter it, since it won't sync), but it's really not a big deal. At first I thought it would be pleasible to show the enemies input display for frame to make the "gaming" a little bit "educationable", "learnable". Also another security hole would be that 2 gamer could cheat with "unexisting" ROMs, that could be avoided by making a script that replays on a 3rd computer that checks and verifies the results and actions etc.
The only thing I'm afraid of is: the gaming. Since the games are deterministic, if you win 1 time a game, you just have to send the very same input series/movie file, and you will always win (this is a huge issue especially when you try to abuse this with a friend to make fake matches or just simply running another instance of the emulator that instantly updates as your match so you have a very little time to test some "possible improvements"). This can't be avoided, only one way: introducing various "extra" features that at RANDOM intervals gives you the ability to make a frame skip (without action), stepping 1 frame back, removing 1 button from enemies input (for a frame), etc.
edit: spellings. and also a side note: gaming on demand would be the same as playing a game at 1 frame / sec. it's another thing than using emulator features that TASes demonstrates and uses to show those godlike movements and experience.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
If I'm correct, you want to make a "gaming on demand" type of service where the TASers only get the "media" (this means you have no access to the memory, can't do any LUA scripts and I don't even want to think about copyright issues).
No, that's not my idea at all. The server would never have an emulator or any ROMs; the two players would have those. The server would only know how to merge two streams of input to create a single TAS input file.
The disadvantages of gaming on demand is hosting at least one server (money), making a lot of scripts for various emulators to get the most desired settings, restricting TAS features (short note: not everyone has high-speed internet, so it would be a pain to send and recieve HUGE packets at short intervals. that's why I recommend P2P+external program to send only the required inputs which results in VERY small packets).
I would use Google App Engine for the server, which is free (unless you start getting huge numbers of requests/second). Emulator settings would be decided off-line by the two players before starting the match; the server wouldn't even need to know what the settings are. My first post talked about sending inputs to, and receiving inputs from, the server; I guess I didn't explicitly say, but I meant that only the inputs would be sent/received.
At my method, the only disadvantage I can think of is that you can decode your enemies inputs/packets (but you can't alter it, since it won't sync), but it's really not a big deal. At first I thought it would be pleasible to show the enemies input display for frame to make the "gaming" a little bit "educationable", "learnable". Also another security hole would be that 2 gamer could cheat with "unexisting" ROMs, that could be avoided by making a script that replays on a 3rd computer that checks and verifies the results and actions etc.
Well, you have to decode your enemy's input packets in order to get them into your emulator. The question is whether you can manage to get your enemy's input for a given frame before you decide on your input for that frame.
If two players agree to play a game with some sort of hacked ROM, that's not cheating, that's just playing with a ROM hack. (Who would they be cheating?) I was imagining that some of these matches would be submitted to tasvideos (as a new category), at which point the normal rules would apply: only the TAS input file is submitted, so the judges run the input on their own emulator and need their own copy of the ROM in order to see the game. And submitting a ROM hack game but claiming it wasn't a hack would be totally pointless, since the input wouldn't sync for the judges.
The only thing I'm afraid of is: the gaming. Since the games are deterministic, if you win 1 time a game, you just have to send the very same input series/movie file, and you will always win (this is a huge issue especially when you try to abuse this with a friend to make fake matches or just simply running another instance of the emulator that instantly updates as your match so you have a very little time to test some "possible improvements").
Well, you're only controlling the input from one controller. It seems unlikely that many games have a winning input sequence for one player that works regardless of what the other player does. I'm not sure what you mean by "fake matches" or what you're talking about with a second emulator instance.
edit: spellings. and also a side note: gaming on demand would be the same as playing a game at 1 frame / sec. it's another thing than using emulator features that TASes demonstrates and uses to show those godlike movements and experience.
I talked in huge detail about how my system would allow game-playing rates of up to 14 frames/day, even if the players couldn't be online at the same time. I agree that this would be a very different experience from playing at something like 1 frame/second, which I never suggested.
The question is whether you can manage to get your enemy's input for a given frame before you decide on your input for that frame.
- Timer starts from X seconds, press your inputs for the actual frame
- After the timer reaches zero, both players sends their input to the other
- Input displays, then go to the next frame
cwitty wrote:
If two players agree to play a game with some sort of hacked ROM, that's not cheating, that's just playing with a ROM hack. (Who would they be cheating?)
Making a hacked ROM with equal checksum (it's possible), so they can do hacked result of a game (it would be a problem if this project would be a "competitive scene" with championships).
cwitty wrote:
I'm not sure what you mean by "fake matches" or what you're talking about with a second emulator instance.
While playing a match, you could run another emulator in the background, where you put the exactly same inputs you play with your enemy. If you do everything correctly, the online game and your offline (2nd emulator in the background) will sync and you have the opportunity to try various actions before sending your real input to the match. For example, starting a LUA script that uses some basic heuristic algorithms to manage health preserves and maximize damage output.
cwitty wrote:
I talked in huge detail about how my system would allow game-playing rates of up to 14 frames/day, even if the players couldn't be online at the same time. I agree that this would be a very different experience from playing at something like 1 frame/second, which I never suggested.
Just to make sure: I love your idea and I would even play this thing, but 14 frames/day is REALLY slow. Of course it would be only the "real action" (intros, cutscenes and menu settings would be a bit faster, right?), it's still would be very long matches and they will mostly fail to end due to the lack of motivation after you realize you have no chance to beat the enemy since you made a minor mistake after sending 64 inputs through a week. Sorry if this sounded too harsh, but I think that some seconds is enough to a frame, mostly because you can't try possible outcomes nor "retry" the actual frame.
I would gladly help you if you would write down some guidelines regarding the gameplay and the motivation of playing this (online competitive scene, achievements, entertainment, variety). I'm also concerned about the number of players/TASers interested in this type of gameplay experience.
edit: you should do a poll on the forums after you come up with the rules and the system
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
The question is whether you can manage to get your enemy's input for a given frame before you decide on your input for that frame.
- Timer starts from X seconds, press your inputs for the actual frame
- After the timer reaches zero, both players sends their input to the other
- Input displays, then go to the next frame
You need to add a lot of complexity to that to make it work across the Internet even if neither player is cheating. Consider a scenario where the clock on player A's computer is 3 minutes fast, the clock on player B's computer is 2 minutes slow, and the round-trip packet time from player A to player B and back is 800 milliseconds. How can you even start the timer at the same time on each computer under these handicaps?
But if one player is cheating the problem goes from annoyingly difficult to impossible. Suppose that somehow both players have synchronized their computer clocks, and have agreed that they should send their next input packets to each other exactly at noon. In the first scenario, the packet transit time is 200ms, so each player sends a packet at noon and receives a packet at noon+200ms. In the second scenario, the actual packet transit time is 50ms, but player B claims that the time is 200ms. Then player A sends a packet at noon, player B gets it at noon+50ms; player B sends a packet at noon+150ms, and player A gets the packet at noon+200ms. Both scenarios look exactly the same to player A, but in the second scenario, player B gets 100 milliseconds for a bot to look at player A's input and decide how to respond.
cwitty wrote:
If two players agree to play a game with some sort of hacked ROM, that's not cheating, that's just playing with a ROM hack. (Who would they be cheating?)
Making a hacked ROM with equal checksum (it's possible), so they can do hacked result of a game (it would be a problem if this project would be a "competitive scene" with championships).
I'm still not understanding the issue. If this "championship" is some sort of tournament, where all that matters is who won and who lost, then the players can control the result of the game just by having one of them deliberately lose. If the game is being judged for some sort of "style points", where the judge actually has to see the run, then this would happen by having the players submit the input file for their match to the judge. If they used a hacked ROM, then the game wouldn't sync when the judge played it back. (I suppose there could be a problem if the players could somehow get the judge to use the hacked ROM? But that would have nothing to do with my system, since the ROMs never touch the server.)
cwitty wrote:
I'm not sure what you mean by "fake matches" or what you're talking about with a second emulator instance.
While playing a match, you could run another emulator in the background, where you put the exactly same inputs you play with your enemy. If you do everything correctly, the online game and your offline (2nd emulator in the background) will sync and you have the opportunity to try various actions before sending your real input to the match. For example, starting a LUA script that uses some basic heuristic algorithms to manage health preserves and maximize damage output.
I was certainly hoping people would do things like this. That's why I said "[You can] ... use whatever methods you wanted to come up with [your input]" in my original posting. (The only difference is that I wasn't going to try to control what the player could do with their emulator, so they could do this in their "main" emulator -- no need for a 2nd emulator in the background.)
cwitty wrote:
I talked in huge detail about how my system would allow game-playing rates of up to 14 frames/day, even if the players couldn't be online at the same time. I agree that this would be a very different experience from playing at something like 1 frame/second, which I never suggested.
Just to make sure: I love your idea and I would even play this thing, but 14 frames/day is REALLY slow. Of course it would be only the "real action" (intros, cutscenes and menu settings would be a bit faster, right?), it's still would be very long matches and they will mostly fail to end due to the lack of motivation after you realize you have no chance to beat the enemy since you made a minor mistake after sending 64 inputs through a week. Sorry if this sounded too harsh, but I think that some seconds is enough to a frame, mostly because you can't try possible outcomes nor "retry" the actual frame.
Well, 14 frames/day is only if the players aren't online at the same time... if they are, then the game can proceed as fast as they want. It would also be possible to allow for an optional timeout if the players wanted it. (But I'd also leave the option to proceed without a time limit. A player might go a week without sending any moves while they search out some new RAM addresses and write a cool new lua script, and that would be OK with the server.)
There would have to be some mechanism for skipping past cutscenes etc. Probably one player would play through the cutscene (controlling both controllers) and submit that input file as a suggestion; then if the other player accepted the suggestion then they would use that input file to be past the cutscene.
I would certainly hope that people WOULD try possible outcomes, which is why I don't like the idea of only allowing seconds per frame. (But like I said, a timeout could be optional, and could certainly be configured for seconds per frame if that's what the players wanted.)
I would gladly help you if you would write down some guidelines regarding the gameplay and the motivation of playing this (online competitive scene, achievements, entertainment, variety). I'm also concerned about the number of players/TASers interested in this type of gameplay experience.
edit: you should do a poll on the forums after you come up with the rules and the system
Well, the motivation would have to be something like "have fun by trying to beat your opponent in a TAS setting". (I hope that it would also result in movies that would be interesting to watch; but if you wanted to do a 2-player playaround or something, these would be the wrong tools.) As far as achievements, tournaments, etc.; those would be interesting, but I wouldn't be interested in trying to set something up.
"... after you come up with ... the system": do you mean an implementation? I would probably try to implement this if people said they were interested, but I'm not going to implement it first just to find out if people are interested -- too much work going to waste if it turns out nobody is interested at all.
This time I leave the quotes to make the post a bit shorter.
Regarding packets: You are right, it would be really complex to make it really fair for P2P. I think it would be really better to communicate with a server (as you mentioned earlier).
Tournament: I think that popular 2-player competitive games just like Mortal Kombat and Street Fighter series should be a great candidate among TASers to "play" (tas) them, what would eventually leads to creating a scene with mostly the member of tasvideos. I think that a tournament or at least a ranked scoreboard would motivate TASers to play more.
Coming up with game rules/system: I'm curious that how many people would play this "project". So it would be a good idea, if you would make a simple project document or a technical specifications regarding the gameplay, and make a poll here at tasvideos forums to get a slight information about the possible number of gamers. Even a simple example of 2 player playing a Mortal Kombat versus fight would do it, no need to write the final algorithms or complex schematics.
I actually never programmed serious network communication codes, but I think I could help you in the developing phase or even after that if anything good comes out of this whole thing.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Before you get too excited about competitive TASes, make certain that the optimal strategy doesn't devolve to implementing an MK Walker. If every attack has a window of vulnerability that can be exploited, then all you need to do is wait for your opponent to expose himself and then slam him -- conversely, doing anything else is just asking to be countered into oblivion. If you require each player to play far enough in advance that windows can't be exploited, then you're largely asking them to guess what their opponents will do, turning the entire thing into a big game of rock-paper-scissors. Not that there's no strategy in RPS, mind you.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
if it's a game like sf2 then you can't really do an MK Walker if both players are in frame advance
normals can be kara canceled, so if you try to react to an opponents jab you can get dped in response
there are couple frames on input delay so that by the time you see the opponent's jab start up and you try to throw in response, your throw ( a 1 frame move ) will be at least 3 frames behind the jab ( a 3-5 frame move )
I think it's a bigger issue that can't be avoided, that Player 1 has an advantage over Player 2 in every frame on most of the games (missing tvtropes link: I mean the order of conditional statements regarding the "list" of Players). Not to mention mirror matches.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
MESHUGGAH: I'm really not interested in running a tournament, although the tools would be available for anybody else to run tournaments if they wanted to. I guess I don't understand what you mean by a "simple project document"... that's what I tried to do with my original post in this thread.
Regarding game choice: Even if some games turn out not to be interesting when played in this fashion, hopefully others will. (And not just fighting games, either... how about Mario Kart?)
I guess I don't understand what you mean by a "simple project document"... that's what I tried to do with my original post in this thread.)
1. The (short) description of the idea/project (why/what/who/where/how/when)
2. The technical side of the project (how does the gameplay works (no need to write down codes), what type of communication, what are the requirements, recommended system requirements, etc)
3. Sample gameplay (with details, what should be the average length of a game-session, who am I play, hints, tips, etc)
4. Possible features (anything. or just a bunch of list of ideas)
I still recommend to write a project document with the sections I wrote and make a poll on the thread (I don't know that you have to make another thread to put out a poll).
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I like the external program idea syncing two emulators.
I think time limit should be handled like this though:
Each player starts with a total alloted amount of time, which is public always, like 5 minutes, while they're choosing their next input their time is running down until they finalize it, the other player doesn't see it until they both put in their input. After each frame advance a small amount of time is added to each players total time, like 15s.
This could keep matches going fast with fast updates, like when both players are waiting on next round, they would both submit their input very fast, could even have an input queing option ^^.
Could make time parameters variable but that's the basic idea, very similar to competitive chess timing rules.
I would love to play someone at SF II turbo with this as long average time to input a frame was under 20s
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
I dont do TAS, but like to watch it.
And I was thinking about a related idea (competitive tas).
My idea would be some sort of TAS wrestling.
TAS wrestling? What?
-We would choose a fighting game, lets imagine Super Street Fighter 2 Turbo from Snes.
-Each user that will join the project would choose different character (in the example SSF2T allow 13 users).
-We would them think about how championship would work.
-In the battles, each player would create separatedly the tas with his character against the enemy one, he will control both characters, in this TAS, his char need to win the battle.
-Then both players would send his TASES to judges that would vote on the best TAS.
-The best would TAS become the official match and the player that won the TAS wins this match.
A even better idea would be using some game that have some sort of championship option like ultimate mortal kombat 3. And making the players use the previous recording file that won and adding their inputs in the next battle and so creating just one file that has the entire tournalment.
Spider-Waffle wrote:
Each player starts with a total alloted amount of time, which is public always, like 5 minutes, while they're choosing their next input their time is running down until they finalize it, the other player doesn't see it until they both put in their input. After each frame advance a small amount of time is added to each players total time, like 15s.
Like in fast chess variants. In blitz chess people start with 15 to 60 minutes and in each turn they get extra 10 seconds.
I have an idea for a new form of TAS, where two TASers play a 2-player competitive game (say, a fighting game, or a racing game).
The idea is that the game would be mediated by some sort of web service. Each player would submit their input to the web service, one frame at a time. Once a player has submitted (and committed to) a certain input for frame T, the other player's input for time T-6 would be revealed.
You could take as long as you wanted to submit your input, and use whatever methods you wanted to come up with it. (For instance, you would probably want to guess what the other player will do, and run simulations as to how your strategy will work.) The only thing you can't do is change your input once you've committed to it.
The main reason for the delay in the above description (where you get the other player's input after a 7 frame delay) is that it speeds up the process. For example, if the two players can't manage to be TASing at the same time, and want the maximum information available, then each TASer can provide 14 frames of input per session. (Player A will commit to inputs from T-7 to T+6; then player B will commit to inputs from T to T+13; then player A will commit from T+7 to T+20, etc.) With the minimum possible delay, where you see the other player's input for frame T as soon as you commit to frame T, then each player can only provide 2 frames of input per session.
Does this sound like an interesting idea to anyone else?
Could anyone challenge me in this type of TAS? Anyone?
actually I think this would work really well using skype. Just have both players run the same movie and tell each other there inputs.
I'd be interested in trying a street fighter match that way.
I forgot the main reason for the web service: to prevent cheating. You rely on the players sending each other their input at the same time. I don't see how to keep one player from hacking their "external program" and consistently sending their move a tenth of a second after receiving the other player's move, with a bot that picks a response based on that move. (A cheating player behind a fast internet connection would look just like a non-cheating player behind a slow internet connection.)
A protocol that should eliminate the possibility for this kind of cheating:
Both players prepare their inputs, and compute a hash based on them
Players exchange hashes
After receiving the opponents hash, each player sends his actual inputs
After receiving the opponents inputs, compute their hash, and verify that it matches the hash that was sent.
By sending a hash, the opponent has committed himself, but not revealed his actual inputs. He can't change his inputs based on seeing yours, as that would produce a different hash. There is the possibility of brute-forcing the hash to recover the inputs, but by transmitting frames in groups of 6, that possibility is mostly eliminated, since the number of bits in the input would be about as large as the number of bits in the hash).
actually I think this would work really well using skype. Just have both players run the same movie and tell each other there inputs.
I'd be interested in trying a street fighter match that way.
did that ever happen? :P if you were to do such a match with SFIV, I’d be interested in watching it
actually I think this would work really well using skype. Just have both players run the same movie and tell each other there inputs.
I'd be interested in trying a street fighter match that way.
did that ever happen? :P if you were to do such a match with SFIV, I’d be interested in watching it
no one responded to me about it. It would be too much trouble to do it without an emulator.
I think having one person streaming the emulator, and the other person sending inputs frame by frame is all it would take. Wouldn't be quite tool assisted without savestates, but it would be interesting I think.
I think having one person streaming the emulator, and the other person sending inputs frame by frame is all it would take. Wouldn't be quite tool assisted without savestates, but it would be interesting I think.
Or you could use remote desktop software like Team Viewer and TAS with TAS Editor, so both persons can draw/erase Input and rewind/advance by mouse. This is probably going to look hilarious.
