IRF

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 . . . . . . . . . . . .

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?

Thanks, no surprises there really. Final score 1692, for the record.

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.

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?

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.)

The Readme file for 'Jet Set Mini' contains the following excerpt: The attached .RZX recording illustrates the bug referred to above. The guardian on the right of 'Pool Party' appears to display some very strange behaviour - it doesn't always kill Willy (though it sometimes does), but instead appears to bounce him like a basketball! Once the recording has finished playing back, you can take over control of the game and have a play with this quirky feature yourself. (The Infinite Lives POKE is enabled, so you can bounce around for as long as you like.) Quirky Guardian Interaction in Swimming Pool of Jet Set Mini.rzx

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. 🙂

Thanks, Norman Sword! I'm relieved that I managed to come up with the correct sequence (particularly in relation to the number of frames of 'doing nothing')! It actually looks more automated (in the sense of being played with precision of movement) than the sequence that the algorithm came up with. I guess it takes a human eye to finesse the algorithm's output.

Crem's table of movement keypresses earlier in this thread includes two entries for the first Kong cavern - one with and one without flipping Kong - but only one entry for the second Kong cavern (with Kong flipped). Flipping Kong in the latter cavern is pretty much done 'en route' to the portal. However, if speed is of the absolute essence, I thought I would point out that the cavern can be completed one time-frame quicker by skipping the jump up to the second switch in the second Kong cavern (i.e. not flipping Kong for extra points and instead just walking along the top-right crumbly platform and dropping straight into the portal - 1777 points are available that way).

Idea for a Manic Miner mod:- Now that we have pretty much established the maximum possible score in each cavern, adjust the air supply for all the caverns so that reaching the portal can only be done with maximum efficiency. The player will either reach each portal just in the nick of time (with only a single bonus point NO bonus points being awarded for the last gasp of air remaining surplus remaining air!), or else they will fail to reach the portal in time and lose a life. The aim is simple - to escape through the portal in the Final Barrier - good luck with that! The maximum possible score, by my calculations - assuming no loss of lives (which would allow items to be collected multiple times) - would be 13,500 points. (85 items in the game x 100 + 2 Kongs x 2500 + 20 caverns x 1 point of spare air supply.) Bonus points for anyone who manages to complete the caverns with any, er, bonus points. 😄 (You could complete the Kong caverns with some spare air by not bothering to flip Kong, but the points gained wouldn't offset the loss of points for not doing so. Alternatively, you could make the air supply/time limit in the Kong caverns even stricter, so that detouring to flip Kong is in fact a time-consuming and thus fatal mistake!)

I've prepared a 'cleaner' version of the essential keypresses for The Warehouse (in the Bug-Byte version of Manic Miner). All the superfluous left-right shuffling has been taken out, but the core route discovered by crem's algorithm is the same. Hopefully, it will illustrate more clearly the technique for proceeding down/across a crumbly field that I referred to in my previous post. Norman Sword, would you mind plugging this datastream in to your automated MM tool, to see if it works, when you get a moment please?: R R R R R R R R R R R R R . . . . . . . . . . . . . . . . . . . R Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . R . . . . . . . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . . . . . . . . RM . . . . . . . . . . . . R R R R R . . . . . . . . R R R R . . . . . . . . RM . . . . . . . . . . . . RM . . . . . . . . . . . . R R . . . . . . . . . R R R R . . . . . . . . R R R R R . . . . . . . . . RM . . . . . . . . . . . . M . . . . . . . . . . . . M . . . . . . . . . . . . M . . . . . .

Crem's algorithm has taught me a new technique - the most efficient way of proceeding diagonally down through a field of crumbly blocks. Rather than dropping down to the required level first and then walking along the bottom; or walking across the top and then waiting to drop down; it is quicker (ultimately accruing most points) if you take a 'stepped' approach. i.e. walk along until just before you are about to cross a cell boundary into the next column, then wait until the rest of the platform underneath Willy has crumbled away and he drops down to the next row, then hit the sideways movement button (best to start pressing it while Willy is mid-fall) and proceed sideways by four animation-frames until just before Willy crosses the next cell boundary, then stop pressing the Left/Right button and wait again to drop down to the next row, etc. (That's assuming there aren't any Fire blocks or guardians in the way, of course.) So thank you, crem's algorithm! EDIT: Using the above technique, I have just managed to reach the floor of The Vat (at the bottom-right corner) before crem's algorithm did so in his recording of that cavern (in fact, I got there so soon that I nearly landed on the yellow kangaroo guardian!) However, I didn't end up with a better score than the algorithm, because the time-critical factor in The Vat is that you have to wait for the yellow kangaroo to get out of the way of the portal before you can reach it.

Thanks, Norman. It looks like I was on the right track. 🙂 The table I was referring to in 'Willy Does the Great Pyramid' is the jump block (I wasn't aware of that term). However, in Geoff's older games, the patch data for each room was indeed held in the form of a vector (a two-byte jump address within the 256-byte room definition). I suppose it would be possible to compress the current two Offset bytes (one each for a Room Setup patch and a Main Loop patch) into a single Offset byte - using the upper bits to index the Room Setup patches, the lower bits for the Main Loop patches, and extracting out the appropriate bits to obtain the indices into the jump block (or jump blocks plural - the Room Setup and Main Loop patches are intermingled in '...Pyramid', I believe, but they could be held in two separate blocks). That would be possible because there are fewer than eight Room Setup patches in '...Pyramid', so only three bits are needed to account for those; and there are fewer than sixteen Main Loop patches in the game, requiring only four bits. P.S. I've seen use of jump blocks in the JSW64 game engine as well, to deal with moving and drawing the various guardian types (there are many more types of guardian in JSW64).

Further explanation: In Geoff Modes I and II, a Main Loop Patch Vector for each room is stored (as a two-byte word, giving the location of the start of the room's patch) at Offsets #EE - #EF in the room definition. A subroutine is CALLed from the Main Loop which loads up the Patch Vector to the HL register-pair and then flow of execution jumps to the patch, via a JP (HL) command. (If a room doesn't have a patch, then the Patch Vector just points at a RETURN command.) In Geoff Mode III (a.k.a. 'Pyramode'), each room has a Room Setup Patch Vector and a Main Loop Patch Vector, but still only two offset bytes (#EE and #EF) are used in the room definition. Offset #EE corresponds to the Room Setup Patch Vector and Offset #EF to the Main Loop Patch Vector. The actual Patch Vectors are stored in a lookup table which starts at #8600. Subroutines are CALLed from the Room Setup routine and from the Main Loop, which pick up the value stored at Offset #EE and #EF respectively for the current room. That value is then used as an index to point at the appropriate place in the lookup table at #8600. Since each entry in the lookup table is a word (pair of bytes), the value taken from the Offset byte is doubled so that each incrementation of the value skips forward two places in the table. Once the correct Patch Vector (entry in the table) has been identified, the same approach as Geoff Modes I and II applies. i.e. the value is loaded up to HL, and then flow of execution proceeds to the appropriate patch via a JP (HL). I believe the above provides a sound body of nomenclature for the Patch Vector system (though perhaps Geoff may wish to comment?) In other words, the Patch Vector for a room is simply a means of pointing the programme towards the Patch for the room - it tells you the location in memory where the actual patch is stored. Under the above arrangement, it would not be correct to say that only certain rooms have a Patch Vector, whilst other rooms don't: in Geoff Modes I and II, all rooms have a (singular) Patch Vector - even if, for some rooms, it merely RETURNs flow of execution straight back to the Main Loop without doing anything - whilst in 'Pyramode', all rooms have precisely two Patch Vectors (Room Setup and Main Loop). Similarly, it would not really be meaningful to say "Room X has a nice Patch Vector". For example, if Room X has a nice, non-standard visual effect, or a guardian with an unusual trajectory, or whatever - implemented via the Patch Vector system - then what you're really talking about there is a Patch. So it would be more logical to just say "Room X has a nice patch"! At least, that's how I see it anyway. 🙂

I would say Geoff Mode III. The Patch Vector system is implemented differently for a start. (There are both Room Setup and Main Loop patches, each of which only uses a single offset byte in the room definitions.)

I just manually took the algorithm's new route through the Bug-Byte version of The Warehouse (i.e. top-right item collected last), and I managed to match the previous best score for the BB version of 1951. But I don't think the SP version's best score of 1952 is possible in the BB edition. The threshers are wider than the spinning triangle, so you have to wait for a single time-frame for the right-most thresher to get out of the way before making the jump towards the portal.

The only thing I would add to Norman's explanation is that "moving Willy up" (as per the phrase in bold in the above quote) might be a misleading way to consider it. When the vertical position of his sprite whilst on a ramp is adjusted, an adjustment is made to his pixel y-coordinate by adding a certain value (depending on his current frame of animation). So in that sense his y-coordinate is increased. However, the effect on the screen is to draw his sprite lower down - because y=0 at the top of the screen - and so Willy is actually moved down, not up, in terms of where you see him.

Yes, I think that's true - the value of the Jump Counter is only used during a jump, and it is always set to zero at the start of a jump (at the same time that AIRBORNE is set to 1).

There's a subroutine at #8E9C which is called to automatically ensure that attribute and pixel y-coordinates stay in sync when Willy is jumping/falling/on a rope. https://skoolkid.github.io/jetsetwilly/asm/8DD3.html#8e9c In up/down room transition, Willy's attribute coordinates and pixel y-coordinate are manually adjusted, one after the other. Ditto for when Willy moves along from one ramp cell to the next (though visually Willy is drawn on a ramp as Norman describes, unless he's jumping through the ramp).

I think I know what you're saying here (you tell the algorithm not to press movement keys if AIRBORNE does not equal zero), and yes I think there is a special case in JSW that will confound that. If Willy jumps or falls onto a rope [but not if he gets picked up by a rope when he is walking or standing still], then Airborne may hold a non-zero value, which only gets actively reset to zero at the point where he jumps off the rope, falls off the bottom end or climbs up into the room above. So if you told your algorithm not to bother trying to press any movement keys unless AIRBORNE = zero, then Willy might get stuck on a rope.

Well there's a challenge for you Danny - try to match (or beat!) the algorithm's best score for MM-SP's The Warehouse, in the MM-BB version of that cavern!

I'm not sure I'm able to answer crem's questions with the degree of certainty that he might need. However, skim-reading them has prompted me to point out that the variables at #85D0 and #85D2 do not get re-initialised at the start of a game. i.e. When you first load the game, Willy starts off facing the bath tap, at the opposite end of the bath from the tap. However, after playing a game and starting another one, his facing direction and frame of animation are sometimes different from that initial setup. That could make a difference (of a few frames) in terms of the possible completion time - small beer in the grand scheme of things, but I just thought I'd mention it. (Of course, it's not an issue if you load up the game file as the first step in each iteration of your algorithm.)

Hmmm, I'm not sure that the first jump over the leftmost harvester is the time-critical moment? Crem, I seem to recall you saying that you awarded bonus points to the algorithm to make it collect the leftmost item first. Could a similar thing be done to make it collect the top-right item last? Then see if the algorithm follows the same route in the BB version as it did in the SP version, would it be able to match (or beat) the current maximum score? (I'm saying all that like it's a trivial thing to do - it probably involves a great deal of work for both crem and his algorithm! If so, feel free to ignore my musings!)

I've just discovered that the game was mooted here on Dr Broad's site, back in the day: https://www.oocities.org/andrewbroad/spectrum/willy/list.html Geoff Eddy has (according to Daniel Gromann on 12th August 2006) been "working sporadically" on Willy does the Great Pyramid, which "may appear for real sometime in the next year or so..." On 9th October 2006, Geoff himself told me: "At the moment all 64 rooms have been designed, complete with items, and I started placing the guardians. That was a few months ago, and due to my lack of both CFT and inspiration, I haven't done anything else since. I was wondering if anyone might want to have a look at it and finish it off, or suggest patch vectors and the like."