Automated generation of Manic Miner speedrun/walkthrough

[crem]

That's how the conveyor logic implemented in ZX version.

• What conveyor does, is "presses" the right or left movement key for you when you are on the surface of it.
• Also, when both "left" and "right" keys are pressed, Willy "keeps the horizontal momentum" (i.e. if he was moving right, he'll continue doing that, same with left, same with not having horizontal movement).

When you jump onto the conveyor from the platform on the left, Willy still moves right when it touches the conveyor, so it's possible to continue going right.

But it's not possible to jump to the right part of the conveyor while still having the "rightwards momentum":

• either you jump from the right to the left and you move to the left,
• or you jump from the "yellow brick" and as it's higher than the conveyor, Willy lands on it vertically as it's not a jump anymore, but "fall".

[SymbolShift]

4 hours ago, crem said:

That's how the conveyor logic implemented in ZX version.

• What conveyor does, is "presses" the right or left movement key for you when you are on the surface of it.
• Also, when both "left" and "right" keys are pressed, Willy "keeps the horizontal momentum" (i.e. if he was moving right, he'll continue doing that, same with left, same with not having horizontal movement).

When you jump onto the conveyor from the platform on the left, Willy still moves right when it touches the conveyor, so it's possible to continue going right.

But it's not possible to jump to the right part of the conveyor while still having the "rightwards momentum":

• either you jump from the right to the left and you move to the left,
• or you jump from the "yellow brick" and as it's higher than the conveyor, Willy lands on it vertically as it's not a jump anymore, but "fall".

Your absolutely right (and Spider) about the platform being on a higher Y level than the conveyor. The other place this can be verified is the Solar Power Generator, jumping right off the platform and onto the conveyor brings willy to a halt, exactly the same as in the Central Cavern.

[SymbolShift]

That said, I'm reluctant to believe that this behaviour was intentional. When Willy makes contact with a conveyor traveling in the opposite direction (coming from any Y height), is he "supposed" to walk, or stop? The fact that both situations are present in the game, makes me think that only one behaviour is correct. The logical behaviour is that Willy should stop, however the guardians ignore this rule and travel in both directions.

We may never know which behaviour is correct/intended.

[Norman Sword]

JSW and MM - walking on a conveyor.


Part 1:-


When Willy is jumping he can have a forward movement component for the arc of travel.. Which is basically an automatic key press in the direction he is jumping.

When the arc of the jump is finished,  and he starts falling, the code kills his movement key and willy no longer has a horizontal movement component for his actions.

This means at the point of landing on a conveyor from any fall, (note I say fall- and not jump) Willy can NOT have a horizontal movement component and this coupled with the automatic key press supplied by the conveyor results in the actions as seen.

All other instances of landing on a conveyor that is level or above the start point have the horizontal component still intact from the start of the jump, and this is transfered to the point of landing. Nothing strange or convoluted in this coding of action.

Edited May 19, 2022 by Norman Sword
Spelking and grommet.

[SymbolShift]

2 hours ago, Norman Sword said:

When Willy is jumping he can have a forward movement conponent for the arc of travel.. Which is basically an automatic key press in the direction he is jumping.

When the arc of the jump is finished,  and he starts falling, the code kills his movement key and willy no longer has a horizontal movement component for his actions.

This means at the point of landing on a conveyor from any fall, (note I say fall- and not jump) Willy can NOT have a horizontal movement component and this coupled with the automatic key press supplied by the conveyor results in the actions as seen.

All other instances of landing on a conveyor that is level or above the start point have the horizontal component still intact from the start of the jump, and this is transfered to the point of landing. Nothing strange or convoluted in this coding of action.

Thanks Norman. Your detailed explanations are well appreciated! 👍

[Norman Sword]

JSW and MM - walking on a conveyor.

 

Part 2:-


Your past, influences your future

Jsw and MM on the zx spectrum both use a lookup table for translating joystick/ keyboard actions into a new key press action.

The predefined actions for every combination of key press is contained in those lookup tables. With some responses being the supposed quirks in game play.

One action that might not be recognised is the response to an action when two horizontal actions are asked for. Normally the player only asks for a response for moving in one direction. Which is how most of the game is played. The player presses a direction key and Willy responds by moving in that direction. But suppose Willy is asked to walk both left and right at the same time? The action for that situation is contained in the keyboard translation / response table, and that action is to respond only on the previous key pressed, and ignore the new key.

To see what this means walk to the right of the bathroom and press the key to move left. Whilst holding down left and walking left, press the right key. The movement lookup table will ignore the new key being introduced into his movement and Willy will continue walking left. Whilst walking left no matter how long or short the right key is pressed, its actions will be ignored, until the left key is released.

Jumping and falling introduce more variables, but walking and holding a key down will continue on that walk until the key is released. Willy can of course walk over a conveyor whilst holding down the key. The conveyor will press the direction key for the conveyor, and the game engine via the lookup table will ignore any change in horizontal movement.

Back to jumping onto conveyors. The most important point about the movement lookup table is that new horizontal actions are defined by the old actions. hence "Your past, influences your future" . The actions that a conveyor has is defined by the actions undertaken to arrive on the conveyor. If your previous action had a horizontal movement as a component of its action and that action is still being requested, then the movement table will oblige and continue with that horizontal movement.

Which is why I tried to explain the consequence of falling onto a conveyor. Because when the horizontal movement of Willy is stopped (previous action) the new action (the conveyor) tries to takes over the  horizontal movement of  Willy.  (see stopped on a conveyor :- at the end)

In the situations of Willy landing with a horizontal movement component still being his last horizontal movement action. If requested to continue with the horizontal movement. (e.g. you are still pressing the key) then the conveyor action will be ignored.
 

Stopped on a conveyor.
The movement action table also explains why you can stop on a conveyor.  If your previous horizontal action was no movement (e.g. a fall) then a request to move in the opposite direction of the conveyor. Will upon landing on that conveyor, result in no movement. This situation is a request to move horizontally both left and right, from a previous null horizontal movement.. That request is translated as a new null horizontal movement reponse.  These actions are all defined in the movement lookup table. 
 

Edited May 20, 2022 by Norman Sword
Adiing "horizontal" to clarify.

[Spider]

For what it is (probably) not worth, the BBC version of this both the original 1984 release and the new 2021 rebuild both behave the same too. I half thought this was worth mentioning as they are coded quite differently from what I can see , but my 6502 is very poor indeed.

[Spider]

Just a small conveyor follow up.

The Sam Coupe version (the full one with the extra level sets) not the free demo, full one is bizarrely denied, behaves differently, you're automatically moved leftwards. I tried holding right but it had no effect. Similar if you jump from the middle block to the right, you're moved left (not show in video)

 

Worth a glance if you've not seen this version before. 25s video.

Unable to locate a working version for the Atari (ST 16bit) and the Amiga version is identical to the ZX in its behaviour, I think (untested but I'd remember)

I was also able to get the Dragon32/64 version (no video and anyway you'll probably not want to see it!) to run but that behaves the same as the ZX. The controls would not map properly, I ended up with tab for 'right' , 'backspace' for left and space for jump. Hlaf temped to turn the keyboard upside down, or get a better emulator that lets you map it out. Never mind was good enough for the test.

EDIT... Video changed from .avi to .mp4 to (try) to make it display in the post.

Edited May 28, 2022 by Spider

[DigitalDuck]

About time I made an account here, I think...

So crem initially made these to help with speedrunning the game, and they were very useful for us in either confirming that our routes were optimal or finding new routes.

I took crem's inputs and used them (in a modified form) to help produce a fully optimised TAS (tool-assisted speedrun; essentially completing the game as quickly as possible using tools like slowdown, frame advance, rewind/rollback, savestates etc.) which you can find here: https://tasvideos.org/5052M

Anyway, in the progress of doing so I managed to save a single frame (i.e. score an additional point) on Endorian Forest - scoring 1841 points. This was due to some forward planning on the collapsing ground - I spend as much time as possible on it while climbing up and it results in one less frame waiting for it to disappear on the way back.

This means the highest obtainable score for the Bug-Byte version is 39531 and the highest obtainable score for the Software Projects version is 39532.

[jetsetdanny]

That's extremely impressive! Something that I was already taking for granted (the previously established highest obtainable scores) has turned out to be wrong.

Congratulations on obtaining even higher scores and thanks for sharing the video! 🙂 👍

I wonder if this is really it, or if there may still be a surprise or two lurking in those caverns... 😉