Jump to content
Jet Set Willy & Manic Miner Community

Automated generation of Manic Miner speedrun/walkthrough


crem

Recommended Posts

On 3/27/2021 at 6:08 PM, crem said:

I decided to give level 19 another go with extremely long search (2 days long) and extended logging and also additional checks that watch where the search starts to miss the current best score. It turned out that I have a bug somewhere.

At frame 720 it said that it found another way to reach the same position with more AIR remaining, so it pruned the original state.

At frame 759 it reported that if you press the same keys from that "better" frame 720 as in the original walkthrough, it results on losing a game (probably colliding with a guard).

Which means that probably I have a bug in duplicate state detection, those states also differed by something else..

Could the implication of the bug mentioned above possibly be that there is a better final score to be achieved for this cavern than the one you have reported so far?

Link to comment
Share on other sites

37 minutes ago, IRF said:

Could the implication of the bug mentioned above possibly be that there is a better final score to be achieved for this cavern than the one you have reported so far?

Yeah it's possible. I'd estimate the probability that better solution exists less than 50% but still much larger than 0%.
Maybe 30% chance. Worth giving another try.

Link to comment
Share on other sites

Investigating how I can clean up the keyboard data as presented. Not as simple as I originally thought. The data for the keyboard presents a stream of key presses. Which I show in the demo game. The problem presented to me, when I try to modify the visual text stream is what can and can not be modified.

If Willy starts a jump the visual data stream switches off (no keys needed while travelling in an arc across the screen). The visual data just shows a series of nulls "." indicating no key pressed. The game however might be moving Willy or Willy might be static, in a vertical jump. There is no indication of when the jump lands and no indication in the stream of keyboard data inputs of what is happening. It becomes difficult to correlate the data with movement. The amount of horizontal movement is directly related to the amount of time Willy is in flight. The Data steam will give no indication of flight termination. e.g. when or where willy lands on a platform

In order to tie the data with movement you have to watch the game being played. It does still leave big gaps in the movement when jumping and possible just standing still static play. It also loses the X position of willy because willy can move in the x direction when jumping and the data will give no indication as to when the x-movement stops. and possible stationary play begins.

In order to tie flight movement and no keyboard activity, with static no keyboard activity I have taken the step of recording the game status of willy as regards to platforms. This status is surprisingly not recorded in the game with any meaningful variables. So I have added my own. (This problem will also be evident in JSW- the platform status is not recorded)

No idea how far I will go with looking at this, already getting pretty complicated for what could be little reward in progress towards cleaning the data up.


 

Link to comment
Share on other sites

Doesn't the fact that the Airborne Status Indicator (#806B) = zero tell you that Willy is on a platform of some sort?

You can also distinguish times when Willy is jumping sideways from when he is standing around by the Movement Flag in #806A.

Link to comment
Share on other sites

19 hours ago, IRF said:

Crem, unless I'm mistaken I don't think you ever posted your video of Willy completing the first Kong cavern without flipping Kong?  (Although you did provide a datastream which your algorithm came up with for that scenario.)

Indeed I think I didn't post it earlier, here it is.

Link to comment
Share on other sites

P.S. In your earlier post containing the keypress datastreams, it states that the Kong run without flipping Kong had the 'First frame stationary' bug in place.  I don't think that would make a difference to the completion time in this case, because Willy has to wait around at the end for the rolling rock above the portal to get out of the way.

However, in the same post (see below), it also states that the Cavern 6 datastream also had the 'First frame stationary' bug.  Did you check that that didn't have any effect on the possible final score either?

 

 

Edited by IRF
Link to comment
Share on other sites

1 hour ago, IRF said:

However, in the same post (see below), it also states that the Cavern 6 datastream also had the 'First frame stationary' bug.  Did you check that that didn't have any effect on the possible final score either?

To answer my own question, it doesn't seem to improve the final score if you set off one frame earlier in 'Processing Plant'.  Either way, you have to wait around for a few frames for the magenta Pac-Man guardian to move out of the way.

Here is a 'cleaned up' version of the datastream for cavern 6, with the first stationary frame omitted and no jerky movement while waiting for the magenta guardian (I hope it works!):

Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q . . . . . . . R R R R RM . . . . . . . . . . . . . . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q . . . . . . . M . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . RM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . RM . . . . . . . . . . . . R R RM . . . . . . . . . . . . Q QM . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . .

Edited by IRF
Link to comment
Share on other sites

 

On 4/2/2021 at 9:10 AM, IRF said:

This was bothering me - why walking instead of jumping isn't one frame faster.  If Willy walks just ahead of a horizontal guardian, it can't catch him; but if he walks whilst jumping sideways, it can.  (The last frame of a sideways jump is spent falling vertically downwards, if the platform you land on is the same height as the platform you launched from.)

However, having thought about it some more, it occurs to me that when Willy walks off the end of a platform, he spends one time-frame 'hovering' at the same height before he starts to drop.  And that frame offsets the frame spent falling straight down just before the end of the jump.  So it all makes sense to me now. 🙂data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

Another mystery solved! 👍

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.