Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I'm also confused - did you intend to upload a movie that starts in the middle of a level, took no re-records to make, and only lasts for 7 seconds? Or did you accidentally overwrite your movie with this one?
In any case, you should make sure Mario never stops running to the right except when it's absolutely necessary to stop. If you wait for enemies like you do here, then it's really obvious that you're not beating the game as fast as possible, which won't be accepted. Also, unless this was changed to not work in the conversion to the SNES version, you should start each level by doing the jumping-backwards trick to accelerate faster.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Enemy positions/directions/movements are randomized upon entering the room in this game, right? In that case it would be much better to start the bot right before entering the room it's supposed to optimize (and let it choose how soon to enter). The disadvantage is that more frames will be emulated for the room transition, so each attempt will be somewhat slower, but the advantage is that it will be able to manipulate the luck more, instead of being stuck with poor results from having bad luck before it started.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Viewer wrote:
This seems to be working. Thank you, nitsuja.
Did you see the questions I asked? It would help to find what's causing the bug. Some games require sync sound to not desync, so for them you'd have to choose between probably crashing and probably desyncing, as it is now.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Does anyone know if there are any videos online somewhere of (record level times in) Sonic Advance 2? (They're not at the Sonic Center...) I think they would help whoever makes a TAS of it to have them for reference, more than the overall time numbers would. And besides that, I'm curious to see (about) how fast this game can really go.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
flagitious wrote:
Possibly I have overlooked something here, does anyone know of any advantages of the snes version for a tool assisted run?
Yes; the last of the levels can only be accessed on the original by playing through the rest of the game 8 times (!) (edit: ok, not necessarily in a row for normal play), whereas you can go through all of the levels in one run from the start on the SNES version. A version of smb2j hacked to not have that silly requirement is accepted, but that is still a hack so I'm not really sure which one would be preferred.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Maybe someone should find out which of those (from all the mario tricks pages) affect the SNES version, as extra information that maybe someone will use.
Bisqwit wrote:
Avatar.. yeah, let's see how quickly I revert this time. :P
Well, that sure was fast. (Or was it a new record?)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Try disabling "Sync sound with CPU" (inside the movie play dialog) when playing the movie.
Also, could you give some information about your system and what sound settings you have selected (especially what it says for Sound Driver), and what game it was and whatever else you think might be relevant? This problem happens to some people, but I have never seen it happen or heard of any conditions that cause it, so it is still a complete mystery to me.
megaman wrote:
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
xebra:
Isn't this what humans do when they play the game? If you accept that the thought process of a human can theoretically be calculated or at least approximated by a computer, then it's incorrect to say such things are absolutely impossible, and pseudorandomness is not inherently chaotic in any case; it is only aimed at being unpredictable to humans in real-time. I would argue instead that, while not impossible, it is impractical and may even get worse results than doing it otherwise, which is probably reason enough to pursue other methods first.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Truncated wrote:
anything where the consequences follow logically from the actions, humans beat computers by silly margins. Conversly the only place where computers beat humans is when the consequences do not follow logically from the actions
I can see what you mean by this, but actually, computers are also great at following things logically, if they are given enough information and a good enough formulation of the problem. The problem is more that most things don't follow logically from the information we have, and we don't understand the process we use to make intelligent guesses/decisions in the absence of complete information, at least not well enough to be able to tell a computer to do what we do. Also, even for things that do follow logically, it is often difficult to reduce our level of knowledge of them to a set of statements or instructions.
Michael Fried wrote:
It works pretty well for chess so I don't see why it couldn't work for TASs if people are willing to spend the time working on making the bot better.
Sure, heuristic functions could help, depending on the algorithm used. But I'm not sure if this is the best or easiest way to convey to the bot what it should or shouldn't do. And playing this game for fastest time is much more complicated than playing chess for a win.
DrJones wrote:
Of course, I was talking about teorethical ways of implementing a bot able to play games. Splicing up the task between various levels of abstraction seems to me a better method than brute forcing, and helps us having a better understandment of the problems that may arise.
...
I would be surprised if you or anyone is able to flesh out this system and get it working anytime in the near future. I don't mean to be discouraging by that, though; I really hope it happens despite how unlikely I think it is. It's certainly possible, I know that much.
(There are already similarly multi-layer AI's in use in some places, although not ones capable of playing any game of arbitrary length optimally...)
DrJones wrote:
The main problem I have found, is that it is very hard for bots to "see" what's happening in the game, and detecting if they have reach the goal, and such.
I have an heuristic idea. Collisions are very interesting. ...
OK, now this confuses me a bit. I thought you weren't talking about the low-level details of things because that is a layer that would be left up to Bisqbot or some algorithm to handle. Isn't "seeing" things in the game exactly what Bisqbot already does by looking at memory addresses and checking which program instructions got executed? I can't tell if you are proposing to do exactly what Bisqbot does for this, or if you mean something completely different.
DrJones wrote:
An actual pruning method would be comparing the actual path with other path obtained by an human player.
Since it breaks down when either the tactics or the strategy change, and since it is likely that at least one of those was not done optimally by the human player, I'm not sure how useful this would really be.
DrJones wrote:
I just don't understand why are you writing so strongly negative posts.
I think Xebra is acting this way because he posted this topic in the NES Games forum with the intention of at least discussing Bisqbot as relates to optimizing Zelda 1 in practice, and because there is another post in the General forum that is more about the general things that are being talked about a lot here instead. So, it seems like it's from frustration. (But to be honest, he acts disagreeably pretty frequently anyway...)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The plugins don't seem to affect timing/lag at all. They can easily affect how much your computer lags when it renders the game, but they will not change how much time goes by inside the game or how many frames it generates. If we're suspicious that the plugin is having some effect on it, we can always try playing back the movie with different plugins to make sure it still stays synchronized.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
We already tolerate small graphics/sound glitches due to the emulator on other consoles. However, I think we should aim for getting the best accuracy that anyone is able to get with the same emulator and game as being what is captured to AVI. If it's unavoidable that one of the characters looks weird or one of the levels is too dark or one of the enemies is invisible or all the special effects are too bright/loud, I would say that's a small enough glitch to forgive (until better emulator support is available for it), but if the game is obviously screwed up for more than a very short part of it (all level graphics are missing, main character is upside-down, collision detection is broken (plugins won't cause this, btw), etc.) then it's probably not acceptable. I can't think of any way to avoid deciding it on a case-by-case basis, but on the other hand I think the right decision should be pretty clear (like the above examples) for most games.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
asteron wrote:
Yeah that did look a little weird.
Actually this has been answered already. Bisqwit wrote that description from my format header and I think it's accurate.
There's no support for weird peripherals, sorry. Especially not a microphone - would the sound stream go in the movie or something?
asteron wrote:
Something else I thought might be useful in the movie format is a "director's commentary" section which would be a set of text in the movie format tagged with start and end frames of when the text should be displayed.
Hmm... well I don't even know how to display text so I wouldn't be able to put it to much use as things are now. (Actually, I guess I could dedicate a new window to it....) I don't think I'll bother with doing this anytime soon, but it's not a bad idea - hasn't this been done for some AVIs outside of the game?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
For the most part I agree, except I think that a room in Zelda 1 is not quite too long for a bot to optimize, when enough restrictions have been added. It might be long enough that the current algorithm would have to be modified (a genetic algorithm sounds good for this to me), but you can also get pretty far by changing the input generation and failure conditions. (Making it considerably more likely for it to walk in the direction it's trying to go, making it fail if it gets knocked back away from its goal position, making it fail if it's too far away from its goal position to possibly be able to reach it faster than the current run does, etc.) It would take some clever restrictions, but they aren't too hard to come up with.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DrJones: It's a little unclear what you're suggesting and how you think it could actually be implemented. It sounds to me like it would take enormously more programming effort to get anything. Sure, better search algorithms than pure randomness can (and possibly should) be used. But this talk about playing more than small segments and actually affecting the strategy... unless you have some damned amazing AI planned, that is quite impossible for a game like this, especially if you want it to be able to handle other games like this without being completely remade. Maybe a pruning method makes sense, but it has to be incredibly good pruning to reduce the computation time enough. So far nobody has come close to suggesting what that pruning method might be, probably because it's very difficult to figure out.
Bisqbot (after being modified with some much-easier-to-figure-out heuristics) can already handle improving both tactics and skill within a practical timeframe, and the high-level strategy has already been optimized independently of the low-level playing by some humans with actual intelligence. Doing even better than that might be a nice goal, but maybe we should start small and consider something that could be completed within the next 6-12 months of part of the free time of a few individuals.
DrJones wrote:
People taking into account the number of buttons should consider that waiting is an acceptable movement, too. Action buttons can be pushed while in motion, too.
Maybe you haven't read their posts carefully enough, for they are already taking these things into account by considering combinations of buttons.
So... to stay on topic: Michael Fried already posted a nice list of memory addresses. We don't have any relevant program code addresses yet, but maybe they aren't so necessary for this game. What things would Bisqbot need to be able to optimize that are not adequately covered by the addresses he listed? The thing that comes to mind right now is: How can it detect screen transitions? And do we want to try getting it to handle rooms that require pushing blocks? (If so there probably needs to be a way to detect if the secret entrance has been opened, and some support for intermediate goals of X,Y position.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I've heard that the N64 version of Wetrix plays much faster than any other versions of it, almost unplayably so. I haven't played any other versions of it, but can believe them since I find it almost impossible to play. (Maybe that's more because it's so easy to get very unlucky than it is the bad controls, though - what am I supposed to do when I get 6 uppers followed by 5 bombs and 15 water drops in a row at the start of the game?)
I'd say play Pro mode to start at a higher level, and, uh, either see if it's possible to overflow the score counter or stop at some high number of digits. I wouldn't stop at level 10 though, that could be too early. Actually, it might be better to play the Challenge mode, either 5 minutes or 500 pieces (whichever is longer), and aim only for highest points possible to get within that limit. That seems less arbitrary than picking a score to stop at.
Since you can manipulate luck and drop pieces very fast without worry, it should get pretty crazy compared to what anyone could do normally. (How many ducks is it possible to have at once? And you'll want to have a rainbow most of the time in addition to as many ducks as possible, right?)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Boco wrote:
It can "make things worse" in the sense that allowing it greatly increases the range of possible input, which means you'll take longer to find a solution because you'll try things that evaluate the same many many times.
Only in your scheme will it take longer to find a solution.
If the attempts are random (i.e. what Bisqbot does) then it won't take any longer. You could even add 1000 extra buttons that don't do anything and let it press them at random, and it still would barely affect the computation time.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Boco wrote:
Your way allows for both holes in the searchspace and repeated computation.
The former is not a disadvantage, because the holes only exist in what you don't have time to compute anyway. Repeated computation is a disadvantage, but not a big one at all because the whole problem is that there are lots of possibilities, and when there are lots of possibilities the chance of repeating one is small. (If it is a problem, it could be reduced by remembering previous attempts in some way, but I suspect that would add more overhead than the time it saves.)
xebra wrote:
Hopefully, on some far removed day in a far removed galaxy, someone with the programming expertise to do something more than talk will do something more than talk.
I think Bisqbot is already nearly sufficient for doing a concept test of a room or two. It's not so far off. All this talk about making it distributed and scripted and automated to go through the entire game perfectly once it's planned out and set up... I think that is the far-off part of it, and unnecessary at that, although it would surely be neat if it happens. (note: That was probably your point - this response is not directed at you.)
xebra wrote:
Until we know which things do and do not affect randomness.
Isn't this pretty easy to test beforehand? Even without looking at the game's random generator function (which can be done) it's possible to be reasonably sure whether it affects the randomness. However, in this case it's probably not worth it to add the restriction either way, because if pressing B more times doesn't do anything besides possibly affecting randomness, then doing so can't make things worse. (Which agrees with what you proposed before, in this one case.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
xebra wrote:
JXQ wrote:
I don't understand why you think eliminating invalid key combinations is a bad idea.
Why allow your input generating algorithm to create invalid key combinations in the first place? There should be nothing to prune.
That is exactly how I read Boco's original statement. I don't think "prune" was used literally to mean that the entire tree is generated and pruned; it was in the context of random tries already, so it seemed to simply mean that you shouldn't generate invalid (or unuseful) input, as a means of cutting down on the amount of possibilities. What is useful input in one part of the game may not be useful in another part, though, so that's why a little extra logic added to the input generation would save a lot of computing time... but as far as I can tell you're both taking that into account already.
edit: Just saw the last posts... maybe I misread that after all. I can't tell, but I assumed it was on-topic.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Phil wrote:
Probably because some people think it will beat the current run.
If it works at all, it will beat the current run - it can easily be programmed to not accept results that are slower. You're right that we can't be sure it's perfect when all the possibilities aren't being checked, but we can at least make sure it'll be closer to perfect than before. (If it just can't find anything fast enough for a segment then that segment won't be played by it, but a lot of rooms are probably short enough for it to succeed.)
Phil wrote:
Doing a room as quickly as possible doesn't mean that the randomness will be better.
Usually if you do the previous room more quickly that means you have more chances for manipulating luck later (there might be some good luck that you couldn't get before because of being even a few frames slower before). Unless the luck is predetermined by how the last room ended - I don't think this game does that, but even if it did, there are ways of working around it.
Michael Fried wrote:
Just program in all the knowledge that a person has, and...
Now there's an optimistic statement, even in this context... (Although there is the disclaimer that it would be extremely hard)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
This does a good job of showing off the game and (in many levels) coming as close as possible to losing without actually losing. But it's closer to how the game is meant to be played normally than it is to being played perfectly, and there's no way to improve or compete with this kind of run when the goals are so unclear. Maybe this should be published as a concept demo or added as a supplement to another run?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OK, it's probably an emulator bug, I can't quite tell what from this but I have some ideas of things that might help. Sorry... I'll try fixing it when I can.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Which other (sound/input/RSP) plugins, though? And what settings did you change? (hotkeys, full-screen, anything.) And what's the result of the desync, that he quickly gets destroyed by the Zerg?
(Also, anti-aliasing is an option in the graphics plugin settings, both for 1.5.2 and for 1.6, it's right in the middle of the front page of its settings. All it does in this game is make the tiles line up incorrectly, if it's on.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Have you tried turning off "Volume Envelope Height Reading" and/or turning on "Sync samples with sound CPU" and/or turning on "Fake Mute desync workaround"? (I'll try testing these specific examples you gave, anyway.)
