Player (206)
Joined: 5/29/2004
Posts: 5712
Heh, I bet if you were allowed to specify the start time of the game, people would try to find whatever time gave the best randomness, no matter how far away from the present it was.
put yourself in my rocketpack if that poochie is one outrageous dude
Joined: 5/3/2004
Posts: 1203
Well, how you determine randomness isn't really important. If your RNG is predictable, it allows a human to plan things out farther in advance, but if it's not, there's still no getting around the benefit of being able to try out hundreds (millions with a bot) of combinations of input to get better results. By definition, if you want a game to be untassable, it has to have no randomness and require no unusual amount of skill to control the in game actions. The only things that come to mind are a exceptionally strong game engines. Certainly Hydra, for example, can't be tassed (barring some bizarre and esoteric bug), though NES Chess Master and even something like Crafty (on a fast enough time control) is.
upthorn
He/Him
Emulator Coder, Active player (392)
Joined: 3/24/2006
Posts: 1802
Look, you're all going about it all wrong. There's a very simple solution for someone who wants to make an un-TASable game. Make it a board game, or a card game.
How fleeting are all human passions compared with the massive continuity of ducks.
Player (206)
Joined: 5/29/2004
Posts: 5712
That doesn't always work.
put yourself in my rocketpack if that poochie is one outrageous dude
Joined: 8/27/2006
Posts: 883
Monopoly has been tased.
Editor, Reviewer, Experienced player (980)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
Jweb Guru>So barring "cheating" by including the exact time and date in the movie file, or forcing the user to otherwise set the clock back before playing it (neither of which I consider to be in the spirit of a TAS at all), ... Both of these solutions have been used for Game Boy games with a system clock (i think). It works because system clocks are very easy to emulate. You would want something else, say a game with built in radioactive isotope and geiger counter. (Lets ignore how many laws this would break for the moment.) Radioactive decay is random and the starting state is not enough to know the rest. Un-emulatable, and thus un-tasable.
Player (206)
Joined: 2/18/2005
Posts: 1451
Super Metroid Redesign is a very good example of a evil anti TAS game. :-) In the fastest possible any% route, if you don't know the exact location of a very important and invisible trigger that would affect the progress massively, you will get stuck after a half hour later and won't have a clue why. This is especially shocking because this little mistake a half hour back in the run will make all the work after it useless and you'll need to restart from there again.
See my perfect 100% movie-walkthroughs of the best RPG games on http://www.freewebs.com/saturnsmovies/index.htm Current TAS project (with new videos): Super Metroid Redesign, any% speedrun
Joined: 8/27/2006
Posts: 883
But then again it's not TAS proof, but it's just harder to tas.
Player (88)
Joined: 1/15/2006
Posts: 333
Location: Bangkok, Thailand
Bag of Magic Food wrote:
Heh, I bet if you were allowed to specify the start time of the game, people would try to find whatever time gave the best randomness, no matter how far away from the present it was.
This could have some pretty interesting effects. I can imagine a programmer thinking to himself "no one will be playing this game in 150 years... I don't need to handle that special case in the PRNG."
print reduce(lambda x,p:p/2*x/p+2*10**1000,range(6643,1,-2))
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
A computer chess game would be rather awkward to TAS. On one hand you would want to make the computer player as strong as possible, but that would make it take exorbitant amounts of time (at least in old consoles with their slow CPUs) which would make it really boring to watch. On the other hand, if you set the computer's thinking time to something small, it will not play very strongly, making beating it rather trivial. Assuming optimum conditions: A top-of-the-line modern PC and one of the best computer chess programs in existence (such as Fritz or Shredder), it would actually be quite hard to beat it. The TASer would have to be a really strong chess player to just do that, regardless of having infinite "undos" at his disposal.
Joined: 9/5/2006
Posts: 61
Ew, some of the Gameboy runs mess with the system clock? I don't like it because it means that even the exact sequence of button presses from the TAS would probably not work from a clean cartridge, but I guess the alternative--not having any GBA runs on the site--is a bit ridiculous. But if you allow things like the system clock to be manipulated by the movie, then obviously there's no "TAS-proof" game, since there will always be a way to create a "fastest possible movie." I suppose if a game was something strange like a fixed-rate sidescroller that ignored all input and involved no deaths, there would be no way to create a FASTER movie than a human could, but that would arguably also not be a game, and a TAS could still be made.
primorial#soup wrote:
This could have some pretty interesting effects. I can imagine a programmer thinking to himself "no one will be playing this game in 150 years... I don't need to handle that special case in the PRNG."
I can't, since the PRNG will produce a recognizable range of numbers and they don't exactly get more crazy as the years progress. Programmers DO, of course, tend to ignore the possibility of extremely unlikely things. So given that we already kind of ignore issues that would make TASing impossible, I think everyone should just focus on what would make it difficult or unentertaining. I think weird input devices like the DS's microphone or an internet connection would probably make it so frustratingly difficult to optimize a game, and make it so prone to desynching, that people might not even try.
Player (206)
Joined: 5/29/2004
Posts: 5712
I'm sure you could find interesting ways to spoof the input.
Jweb Guru wrote:
Ew, some of the Gameboy runs mess with the system clock? I don't like it because it means that even the exact sequence of button presses from the TAS would probably not work from a clean cartridge, but I guess the alternative--not having any GBA runs on the site--is a bit ridiculous.
I don't know if it's "messing" with the system clock when Pokemon 2 asks you to input the time when you first turn it on anyway. I think the problem was the emulator reading from the system clock at all when it should have started clean and just kept track of the time based on the number of frames passed, but maybe that's hard to do.
put yourself in my rocketpack if that poochie is one outrageous dude
Joined: 8/1/2006
Posts: 428
Jweb Guru wrote:
primorial#soup wrote:
This could have some pretty interesting effects. I can imagine a programmer thinking to himself "no one will be playing this game in 150 years... I don't need to handle that special case in the PRNG."
I can't, since the PRNG will produce a recognizable range of numbers and they don't exactly get more crazy as the years progress. Programmers DO, of course, tend to ignore the possibility of extremely unlikely things.
Well, if the system time is set to one second before it overflows...
Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host
Joined: 9/5/2006
Posts: 61
JSmith wrote:
Jweb Guru wrote:
primorial#soup wrote:
This could have some pretty interesting effects. I can imagine a programmer thinking to himself "no one will be playing this game in 150 years... I don't need to handle that special case in the PRNG."
I can't, since the PRNG will produce a recognizable range of numbers and they don't exactly get more crazy as the years progress. Programmers DO, of course, tend to ignore the possibility of extremely unlikely things.
Well, if the system time is set to one second before it overflows...
Irrelevant really, since the time isn't usually sampled except for the initial seed. And even if it were, a good pseudorandom function wouldn't be affected that much. System clock situation sound confusing so I won't go there.
Joined: 8/1/2006
Posts: 428
Jweb Guru wrote:
Irrelevant really, since the time isn't usually sampled except for the initial seed. And even if it were, a good pseudorandom function wouldn't be affected that much. System clock situation sound confusing so I won't go there.
That depends on what else is time-dependent, or what is stored in memory adjacent to the clock. e.g. if the overflow increments the level counter, one can skip Level 1 completely.
Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host
Post subject: Re: Making a TAS-proof game
Former player
Joined: 6/4/2006
Posts: 97
Location: Everywhere including nowhere
Before I go into my schpeel, I'm going to lay down some assumptions. 1. Let us assume that the game must be a video game, as real life board games and sports are obviously impossible to TAS. 2. Let us assume the following definition of a TAS-proof game: "A game for which it is true that no TAS of the game that could ever possibly be made would fulfill the requirements of entertainment and accuracy for acceptance on tasvideos.org." Let us also assume that such a game must not be mangled in such a way as to detract from normal gameplay. 3. Let us assume that money is no object, because your programmers are going to be working overtime hell for the next few months. 4. Let us assume that every system can be emulated with TASing tools, including PC, and thus one's choice of console cannot be used as a method of making the game TAS-proof. To further tie our hands behind our backs, let's say that we're not going to use annoyances like excessive unskippable cutscenes, lots of long waits in the level design, the character having to stop to do almost any action, and so on. Under these conditions, a TAS-proof game could be produced. There are some basic ways TASers gain time. There are also some basic ways to prevent them from working. The first step is to prevent sequence breaking. This is easy. Just figure out what items, what triggers, etc. the player should minimally have by the time he should be going through X door. If he doesn't have all of them, X door is locked. Make sure there's a door between every two rooms. Simple as that. However, that might not be enough. For example, lets say our game has a room in it that has only one entrance, which leads into a pit. When you first go in, you'll find the Sword of Über Manliness, but cannot get any further because the edges of the pit are unscalable. However, once you get the Boots of Scalability, you must come back to the room to climb those cliffs and get to the top which reveals the Gas Mask of Winningness. The player needs the Gas Mask of Winningness to survive the final boss's initial Nacho Cheese Breath attack which would otherwise cause instant death, but what if a TASer can find a way to scale those cliffs without the Boots? Easy. If he tries to collect the Gas Mask without the Boots, trigger a cutscene in which the Gas Mask dances away into the shadows saying something like "You can't catch me without the boots that enable you to climb up walls" or something like that. And remember: you should assume that the player can do anything. Always. Now, tighten up your code. And I don't mean make it glitchless; that's impossible. But there are some basic ideals you can adhere to to at least prevent the huge timesavers. - No assumptions. Ever. This should be self-explanatory. - Don't make variables bigger than they need to be, and I mean really really tight. If there's no way for the character's speed to go over ten (in whatever units you're storing it as) you don't need any more than four bits, plus one more for direction; use the other three for something else. It may lead to obfuscated code, but keep in mind, you're aiming to make TAS-proof code. TAS-proof will more often than not equal obfuscated. - Don't make pseudo-random AIs. Enemies should not jump out of the player's way on cue. Bosses should go for the throat and nothing less. If that makes them predictable, fine; it should still impede a TASer's progress. - Find a way to make an RNG that is based only remotely on player entropy. For example, the frame at which you collect the Seed of Infernal Bliss could be stored in memory and used as a variable in the RNG from that point forward. The number of times a certain boss used a certain attack, the number of steps a generic monster took before it was slaughtered, the number of sprites onscreen at frame 1337 of level 6... make luck-manipulation hell incarnate for the TASer. These cover the majority of cases; beyond that extensive beta-testing is needed, as always. This should work. Obviously no one would ever bother doing it, but it should work.[/b]
...?
Post subject: Re: Making a TAS-proof game
Player (95)
Joined: 6/25/2005
Posts: 122
curtmack wrote:
Enemies should not jump out of the player's way on cue. Bosses should go for the throat and nothing less.
Oh, and make them smart enough to walk around, say, oh, bottomless pits. Even short bouts of 100% pure aggression can lead to Golden Axe Syndrome.
Chamale
He/Him
Player (182)
Joined: 10/20/2006
Posts: 1355
Location: Canada
Ironically, I chose to TAS a game that is fairly similar to Curtmack's description. There are no sequence breaks, except one. You have to run a long way through a set route, with not many alternate routes. Level 5 is an exception, where it is possible to abuse temporary invincibility to go through a door. The boss is easy to beat, so this level is beaten in under 1 minute. But otherwise, no sequence breaks. There is no RNG whatsoever, some bosses must be beaten thanks to an item drop, and the item drop timing can't be modified. I still tried, but the movie will probably be rejected for bad game choice. There is one abusable thing: When you run into a sleeping Velociraptor (all raptors in the game are asleep at first), they go into an animation. During said animation, they can't damage you so you go right through them. When they run up behind you, they try to attack, but they stop when attacking so you can escape them. But otherwise, I picked a bad game.
Joined: 5/3/2004
Posts: 1203
But even your game with no sequence breaks and perfect programming would be tassable. There would be earliest moments at which you could perform certain actions, and no normal player could reasonably perform every action at its earliest moment. Ways to get around this:
  • Implement something akin to the SMB 21-frame rule, so that the player has several seconds within which to perform an action such that the next part of the sequence will always start at the same time no matter when that action is performed within that several second period. (Retarded, by the way.)
  • Nethack.
I mean, realistically, no, you can't make a TAS-proof game that isn't one of the obvious exceptions we've already discussed.
Post subject: Re: Making a TAS-proof game
Joined: 5/3/2004
Posts: 1203
curtmack wrote:
- Don't make pseudo-random AIs. Enemies should not jump out of the player's way on cue. Bosses should go for the throat and nothing less. If that makes them predictable, fine; it should still impede a TASer's progress.
What about getting really close to monsters to hit them more often and stuff like that. There's no way you can take away a tasser's advantage of being able to try to do really dangerous stuff over and over again, unless you remove action from the game entirely.
- Find a way to make an RNG that is based only remotely on player entropy. For example, the frame at which you collect the Seed of Infernal Bliss could be stored in memory and used as a variable in the RNG from that point forward. The number of times a certain boss used a certain attack, the number of steps a generic monster took before it was slaughtered, the number of sprites onscreen at frame 1337 of level 6... make luck-manipulation hell incarnate for the TASer.
This assumption is also incorrect. It doesn't matter how random and unpredictable the RNG is, luck manipulation will never be hell. BisqBot will own a human player every single time. The only way to get around this is to remove randomness from the game entirely.
Joined: 10/3/2004
Posts: 138
laughing_gas wrote:
Or if it detects frame advance or slowdown the game automatically freezes your character so he can't move.
That's impossible. Since the frame advance and slowdown is done on the emulator's end, the software won't know it even happened.
LSK
Joined: 4/17/2006
Posts: 159
I had an interesting idea - a game that could only be beaten using TAS tools and memory viewing. However, it wouldn't be very fun...
Reviewer, Active player (288)
Joined: 12/14/2006
Posts: 717
I think there are some hacks floating around that are like that.
Former player
Joined: 6/4/2006
Posts: 97
Location: Everywhere including nowhere
Air is a bit like that, although you could theoretically beat it in real life... And I guess yeah, my idea isn't fully TASproof, but you get the basic idea: find everything that makes a game good to TAS and crush it.
...?
Joined: 9/5/2006
Posts: 61
If you just want to make a TAS pointless, autoscroller. Honestly the only reason the Gradius run works is because of the powerups, get rid of those and the bosses and you have one of the dullest TASes imaginable.