Developer time is not free, of course, so every bug that exists in a game has to be weighed:
* How long will it take to fix? This could be a very long time indeed depending on what causes the bug.
* How bad are the consequences of the bug occurring?
* How likely is the bug to be triggered?
Bugs that are likely to happen and bugs that have bad effects tend to get priority. If "your" bug is unlikely to occur or is relatively benign then you'll probably just get ignored, especially for singleplayer games where exploiting the bug can't harm other peoples' enjoyment of the game.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I suspect the big problem you'll run into is that after 20+ years, most programmers are not going to remember much at all of how their old programs work. Hell, I have enough trouble remembering the stuff I wrote 5 years ago. What they do remember will probably be the tricky problems they had to solve, and the elegant hacks; it might be useful to know that stuff, but statistically speaking, you have pretty low odds of it revealing the potential for useful glitches; there's just too much code in your average game.
Now, if you could get your hands on the old source code, that'd be a different story!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The cueball is skidding/sliding on its first pass; contact with the target ball slows the cueball down enough that it's able to grip the table surface and let its spin actually move it. The sliding removes negligible energy from the ball (just some heat loss due to friction, but the ball is quite smooth), so it still has most of its spin when it starts making the return trip.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
They should definitely be solvable without using a computer, calculator, or other "tool assistance". If such were allowed, then there would practically have to be some rules stated at the beginning to guide the players; otherwise there's too many possible interpretations for the clues. E.g. is an image of static a QR code? An array of binary data? A jumbled image? Just a hint to turn on the radio?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
As a matter of practice, I think it's reasonable to say that two objects are touching when you can only get their center of masses closer to each other by causing one or both of them to deform under the force you're applying.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
My family has a tradition of presenting puzzles to each other at Christmas. Typically the way this works is:
* There's a set of small gifts (often candy), with either no labels, or labels that don't have intrinsic meaning (e.g. just numbers)
* There's some extra material -- a sheet of paper with some text on it, for example.
The family has to figure out, first, what the text (or other provided material) means, and second, how to use that information to determine who gets which gift. The goal isn't to get the family to do mindless busywork, in other words; part of the puzzle is figuring out the rules.
For example, one year my sister provided a numbered set of sequences of numbers, which mapped to keys on a piano. These then created simple tunes which we could associate with different family members. I got the SMB1 main theme; go figure.
I'd like to do one this year, and what I was thinking was that I could provide a set of images and diagrams that individually made little sense, but if you could figure one of them out, it would provide a clue to help decode another; once you understood each image you could use them to "decrypt" other images/diagrams that were on the actual gifts.
Thus far all I have, though, is:
1) An image of some text, but taken at an extreme angle. Thus to have the image make sense, you have to tilt the paper it's printed on and look at it at the same extreme angle.
2) A substitution cipher in ternary (i.e. 000 = 'a', 222 = 'z'). But instead of using numbers, each character is represented by a sequence of three lines (low/middle/high), with the entire text looking like the output of an oscilloscope.
3) A text where the strokes for the individual characters have been broken out into multiple sub-images, which have to be overlaid on top of each other to reconstruct the original message. E.g. if the text were "apple" then the top stroke of the 'a', the upright of one 'p' and the curve of the second, half the 'l', and a bit of the 'e would go in one image, and the other image would have the other components.
(So, for example, if you looked at the first image at an angle, it might say "overlay", a hint for the third image. That image in turn might say "ternary" or "cipher" as a hint for the second image)
I'd love to get more suggestions from you all for other neat tricks along these lines that could be done. The overall puzzle, ideally, shouldn't take more than a few hours' work from several reasonably smart people with diverse backgrounds. I also encourage those of you whose families consist of gigantic nerds to try doing this yourselves; it's honestly a lot of fun.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Edit: What about cases where changing one frame has cascading effects (different lag patterns, RNG)? Adaption may be trivial or not.
If you have to rebuild significant portions of the input for any reason, then it's reasonable to claim authorship; you might well still list the previous author in the "special thanks" section of the publication, but you wouldn't be obligated. It doesn't matter if the visible improvement is only a single frame; what really matters is the amount of work you put into the run.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
What would you use that glitch for? A submitted TAS would have to truly start from scratch. I guess it could be useful if you wanted to do a run where you already have the weapons from the start, but that wouldn't be a standard any% or 100% run.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I have implemented A* for my own game work, thanks. It's not a very complicated algorithm.
Good to know. That's makes the discussion a lot easier. Where did you try it? And how did it perform? Did you implement it directly in an emulator or did you use some interface?
I'm not talking about playing in an emulator, I'm talking about a game I'm (slowly) developing along with members of the Angband development community. Specifically, the game is Pyrel, a 2D roguelike (dungeon crawler). A* was used for AI pathfinding; however, it wasn't fast enough (Pyrel may have dozens or hundreds of enemies on a level, and running A* for each one is not plausible), so we switched to a heatmap approach.
* At the start of each level, turn around, jump, and then start moving forwards
This should IMO be easily found since AFAIK it pays off after a few seconds only.
Did you miss the part where I pointed out that maintaining 1 second's worth of possible paths in an NES game requires more memory than exists in the entire universe? All of your other "A* should find this automatically" comments fall under the same problem. There is such a massive potential search space in a videogame that A* simply is not a plausible way to find optimal solutions. Using A* to pathfind through the game requires the user to simplify the problem space to the extent that it cannot match the results that can be achieved by even a mildly experienced TASer working "by hand".
Let's put it another way: A* boils down to a breadth-first search. You examine all the possible paths to a goal until you find the first one that hits that goal. There's also some optimization in there to prioritize the order in which paths are processed, and to deal with the situation where an intermediate state can be reached from multiple prior states. However, that prioritization cannot reject states, but merely say that a given state is more likely to lead to a short path than another.
In a videogame, there are functionally no situations in which you can reach the same intermediate state from multiple prior states. If nothing else, the game timer will ruin you, since it advances every unpaused frame. Which means that practically possible action from every state (i.e. node) is unique, which leads to the "requires more memory than exists" problem. Remember, 1 second of gameplay requires (2^8)^60 = 3 * 10^144 possible states, i.e. more than the number of atoms in the universe.
Even a tenth of a second ((2^8)^6) requires 2.8 * 10^14 possible states. If each state took only a single byte, you'd need 256TB of RAM. For one tenth of one second of gameplay. If you had one of the world's most powerful supercomputers you might have that much RAM at your disposal. And you still wouldn't be able to consider any deviation from the "optimal path" that takes more than a tenth of a second to pay off.
Do you understand now why these huge numbers make optimal solving of games completely infeasible?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
As a general rule, this falls under "trying to solve games programmatically" and has similar flaws.
Before diving into the details, I would be interested in knowing who in this thread did actually know A*-search before reading this topic.
I have implemented A* for my own game work, thanks. It's not a very complicated algorithm.
Now, tell me how A* is going to figure things out like (examples taken from SMB1):
* At the start of each level, turn around, jump, and then start moving forwards
* Collect a mushroom and fireflower so the fortress level(s) can be finished faster
* Going through the wall in 1-2 to get to the warp zone faster
* The flagpole glitch
* The flagpole glitch with jumping off of an enemy
* The vine screen-scrolling glitch
* Avoiding fireworks
Like I said, you run into the problem that each state of the game may or may not be "closer" to your goal state than any other state, because there are a lot of situations that require you to slow down in your visible progress (distance towards goal) in order to set things up to ultimately be faster.
If all you care about is reaching the goal, regardless of the time taken, then sure, that's doable. Search YouTube for "infinite Mario"; there was an AI contest awhile back to write a Mariobot that could "solve" procedurally-generated levels, and the winner used A* search. Though, come to think, even that would have problems with the "maze" fortress levels.
But winning games is easy when you have tools. The trick is to win optimally. And that requires far more lateral thinking than A* is going to be able to provide.
EDIT: thanks for the correction, zoibot. I thought the number was a bit small...
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
As a general rule, this falls under "trying to solve games programmatically" and has similar flaws. The most glaring is that for an NES you have 8 inputs per turn, which means that each extra step you take in your search adds 8 more states to be evaluated. That means that after 1 second (60 frames), you have 8^60 ~= 1.5 * 10^54 states to deal with. For reference there are estimated to be about 10^80 atoms in the universe.
In order for a computerized solver to make any kind of progress, it must be able to recognize some states as being suboptimal. In most pathing situations, you can recognize when you reach the same position via multiple paths, and thus throw away all but the shortest path. But in a videogame, things are happening while your path moves. Enemies change position, time passes, etc. Also, your path is not just your position, but also your velocity and other game state; recognizing when a change in all that extra state is "redundant" is very difficult.
Even Super Mario Bros. 1, one of the simplest 2D platforming games, has many situations in which you need to take seemingly-suboptimal actions that don't pay off until quite some time in the future. Is it worth slowing down in order to get a mushroom? What about to manipulate the position of an enemy?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I suspect you'd have more luck figuring out how to write the necessary inter-language glue code needed to control Lua from your language of choice.
This sounds like an interesting approach, I did not think about yet.
Using sockets might actually do the trick (but wouldn't be fast).
Perhaps the WinAPI-Library contains something useable as well.
Have you done something like that before?
I've written C <-> Python glue code using SWIG in the past; it's a bit clunky (and SWIG takes some getting used to) but it does work. Lua itself is designed to be easily embedded in other programs (which is why it's the scripting language of choice for many, many games), though I don't know if that means you can simultaneously embed a single Lua instance in two separate programs.
Sockets might well be your most straightforward option, since it seems like you're going to have to have some inter-process communication. You might want to look up ways to do remote procedure calls (RPCs) in Lua; there's at least one library that can do it. That would save you from having to manually interact with sockets, as well as from having to devise your own protocol. The basic concept for RPCs is that you have a server that exposes a set of functions, and a client that connects to the server and learns about those functions; the client then can "call" the functions as if they were local objects, with the RPC library automatically handling the transfer of arguments and return values to/from the network.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I suspect you'd have more luck figuring out how to write the necessary inter-language glue code needed to control Lua from your language of choice.
Bottom line is, though, that FCEU/FCEUX were never approached as "the emulator is a library", but rather as "the emulator is a program". In the latter situation it makes far more sense, from an ease-of-development (of the emulator) sense, to embed a scripting language than it does to convert the entire emulator into a library. Certainly the latter approach makes future hypothetical developers' lives easier, but it's harder to implement in the here-and-now.
So I'm sympathetic to your problem, but I can't bring myself to say that FCEUX is doing anything wrong.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Sorry I can't help you -- I discovered long ago I don't have the persistence to make TASes. But I wanted to wish you well. I look forward to when this TAS is completed! :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I think rather than showcasing a glitch it'd be better to just show a scene that gives a feel for what the game is like. Something like 0:57 in the encode: a few mechs, some destroyed terrain, some bullets and explosions.
(Screenshot from the YouTube encode, obviously not usable in the publication)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The last sentence in the publication description ("Most of the mechs can only walk...") is a bit misleading since two of the mechs can fly, and in any event walking isn't seen much in this run. I suggest replacing it with this:
"Each of the mechs has different movement rules. For example, one can roll as a ball, another can walk and walls and the ceiling, and a third is an agile flier. Additionally, the player can eject from their mech and fly using a jetpack, although they are extremely vulnerable in this form."
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That's why I said "any official production". If at least one official version of the game recognizes that button, then it's clear to be used, just like we often use a specific version of a console game because that version has favorable behavior.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Well, two questions:
1) Is the software modified to enable this button? If it is, then using it is of course right out.
2) If the software isn't modified (i.e. the "escape" input is recognized by the game code), then is the button made accessible in any official production of the game? If not, then that implies hardware modifications are needed to enable it.
I mean, this isn't like a normal console where all of the buttons should be considered valid inputs; each arcade machine is basically a game and console bundled together. It's reasonable for the game developers to ignore inputs that wouldn't be physically possible on unmodified hardware.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
A debit card is a card you can use to pay directly from your bank account. They're more dangerous than credit cards since a criminal could potentially drain your entire bank account if they got their hands on your card data. However, they also don't require credit checks, charge interest, or other things like credit cards do.
A prepaid "credit card" is really more like a debit card with an independent account, as I understand it. You put some money "on the card", and that's all the money that the card can access. They're pretty safe since the scope of potential damage is so limited; the worst case is that you lose the money on the card, and no more.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Easy yes vote. Great work, Dooty! This game really benefits from optimized movement, taking damage, and luck manipulation; the TAS looks nothing like normal play (which tends to be fairly slow-paced and methodical).
Your little dances after the mission ended were amusing, too. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Amazon may have non-credit card systems available for you to use. I seem to recall they support paying by cell phone (i.e. the charge is added to your cell phone bill) in some parts of Europe, for example.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That'd be kind of a niche feature. Though saving replays would be more general-purpose, and would provide a baseline for allowing TASing (by modifying the replay files).
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I hardly think they didn't know what the mystery stretch goals would be. You don't start a project of this magnitude without having all your ducks in a row beforehand.
On the other hand, I do suspect that the mystery goals were probably things that wouldn't inspire much excitement if we knew what they were beforehand, and they were interspersed with the other goals as a way to maintain momentum. I.e. people go from "Oh man, we've almost unlocked the mystery goal!" to "Well, that was kind of lame, but look! We're almost to something that we actually care about!"
Whereas the recent reordering is most likely an attempt to keep the "initial wave" of interest riding high, since they honestly have a tremendous amount of momentum.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I asked this before, and it seems ok as long as its for testing purposes.
Yeah, this of course would not be sufficient for putting the console-verified checkmark next to a run. But it would make it a lot easier to demonstrate playback of lots of games at an event like AGDQ. You could theoretically even have a kiosk setup where visitors could request a run and watch it play back.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Random question - Can a NESBot be made to be compatible with a Powerpak and thus allow console verification of any NES game? Or is there a technical reason making this impossible?
It looks like the Powerpak has a built-in file browser. Movie playback typically starts from power-on of the console, so that browser would cause desyncs. It would probably be easy to fix by just inserting the necessary browser-navigation input at the beginning of the movie, though.
I don't know how the Powerpak actually works, but assuming that everything after that point is like playing the game normally, it should be fine otherwise.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
(Screenshot from the YouTube encode, obviously not usable in the publication)