Automated generation of Manic Miner speedrun/walkthrough

[Norman Sword]

Manic Miner contains a feature that vertical guardians do not adjust their attributes to within the minimum area needed. It is evident Matthew was aware of this and adjusted the sprites accordingly. By the time we get to the skylab and other screens the attribute bleed into un needed squares becomes noticeable. But not in need of a re write (this is NOT a bug)

I have edited the routine to enable me to play either with the normal style routine or the routine that checks for the extra square when needed.

The result in the solar power room is - 
With 3 attributes coloured in by the sprites - and deflecting the solar beam - 1137 points- Bottom
With checking and varying between 2 and 3 attributes deflecting the beam - 1129 points. - top pic


  

Edited April 5, 2021 by Norman Sword
adding picture connection.

[IRF]

Thanks, Norman.  It's interesting to see that the deflection of the beam (by the vertical guardian extending its reach) is favourable to Willy in that instance.  (N.B. It can work the other way too, in some circumstances. e.g. if Willy had been standing a bit further to the left in the screenshot I uploaded a few posts back, then he would have been zapped by the beam, but only because the beam had been deflected downwards by the blue vertical guardian's 'shadow'.)

Question: Is the red part of the solar beam in your top picture intended to show where the beam is in contact with Willy?  If so, then shouldn't the final character of the beam revert back to yellow?  Since Willy is only occupying two character-rows at that moment in time (as evidenced by the fact that the difference in score = 8 points. i.e. only 2 cells of Willy's white INK are in contact with the beam).

Quote

(this is NOT a bug)

I mentioned it as a bug because SkoolKid lists it as such in his disassembly (instead of it being in the 'Trivia' section).  There is also a similar entry in the 'Bugs' part of the disassembly concerning the attributes bleeding out of Skylabs whilst they are on their landing pads just after crashing - the rationale for that not being a bug, I tell myself, is that the dust emanating from the disintegration of the Skylabs is what is temporarily colouring the platforms.

 

Edited April 5, 2021 by IRF

[Norman Sword]

This routine I have used several times in various ways. The beam of light is yellow until the point of contact with Willy, then it turns red. The beam once red, stays red until the end of the beams passage across the screen. So in the picture the red is indicating the point of contact and the path in red from that point onwards.  Having just tested  just the point of contact in red as a routine, I can say it looses the visual impact of leaving the beam red from the point of contact onwards.

 

Edited April 6, 2021 by Norman Sword

[IRF]

I think it's a useful tool (the beam turning red where Willy enters it), but the usefulness would be enhanced if it were to revert back to yellow 'downstream' of Willy.  Because that would allow you to more clearly distinguish between times when the beam is sapping 8 units of air (as per your images), and when it is sapping 12 units - if Willy were to jump in the air in the scenario shown by your images (and assuming the beam stays in the same place), then in the next time frame, his sprite would be spanning three character-rows, and so three characters of the beam would be highlighted red in the upper image.

[IRF]

There are also occasions when the solar beam only saps 4 air units, so it would be useful to only have a single character of the beam highlighted with red in such circumstances.

In the two attached images, the solar beam is sapping 4 units and 12 units of air in those respective time frames.

In the first image, the right of Willy's sprite falls under the shadow of the adjacent guardian, which protects him from the air-sapping effect of that character of the beam.  Then the beam is deflected by the guardian, so it passes horizontally through the left of his sprite.  A single red character of the beam would help to highlight what is happening.

In the second image, the solar beam is passing vertically through Willy whilst he is jumping/falling and not cell-aligned.  So three red characters of the beam would be visually useful here.

Norman, I presume the beam is highlighted in red PAPER but with white INK in your images?  (So that any infilled pixels of Willy's sprite would be visible within the red beam?  I can't tell from the images you supplied so far, because Willy just happens to be in right-facing animation frame 0 is all cases, meaning that the right half of his sprite is comprised entirely of unfilled pixels.)

Edited April 6, 2021 by IRF

[IRF]

Whilst I was at compiling the previous images, I also came up with this one, which highlights more clearly the 'protective shadow' provided by the vertical guardians.

N.B. No air-sapping took place in this frame - which might be counter-intuitive, since the front part of his head is within the beam and is drawn with white INK!  But that's because the solar beam itself is drawn with white INK (on yellow PAPER) attributes, overlaying the front of Willy's head (which had previously been discoloured by the guardian's blue INK, earlier on during the processing of this pass through the Main Loop.)

Presumably, Norman's modified solar beam wouldn't turn red at all here (which is good, both in terms of gameplay and analysis of the beam mechanics!)

Edited April 6, 2021 by IRF

[MtM]

I may have this wrong or overlooked something, but given Norman's genius, and of course that of others too, could perhaps the beam turn different colours depending on whether it is sapping 4 / 8 / 12 units of air?, so red for 8, blue for 12, bright green for 4? Just a suggestion. Or maybe Willy would be better off changing colour, depending on what he is doing on screen, how his pixels are spread to so speak?

 

Just to make an awkward request, I would like the end of the beam, unless it is currently in contact with MW and so displaying as above, to go through the rainbow effect of colours too, get a bit of that Defender action going there 😉 - it will show though practically that the beam in terminating there.

 

On a roll here (!) - how about a feature whereby if the beam contacts a sprite, the sprite is stunned for a few seconds and stops moving due to the power of the beam? Or alternatively the sprite speeds up as if boosted by the beam's power?

 

[IRF]

The attached screenshot - based on a modified file in which only those characters of the solar beam that are currently sapping Willy's air supply get highlighted in red PAPER - demonstrates that in some circumstances, there can be separate, discrete elements of the beam sapping Willy's air.

The intermediate character does not affect the air supply because it falls under the shadow of the adjacent guardian, which changed the INK attribute in the cell holding part of Willy's sprite to non-white (before the Main Loop drew the beam in this frame), therefore that character of the beam is drawn with the regular yellow PAPER/white INK attribute.

N.B. It's all a bit academic, as Willy pixel-collided with the guardian and died shortly after the screenshot was taken! 😮😆

Edited April 9, 2021 by IRF

[IRF]

7 hours ago, IRF said:

The intermediate character does not affect the air supply because it falls under the shadow of the adjacent guardian, which changed the INK attribute in the cell holding part of Willy's sprite to non-white (before the Main Loop drew the beam in this frame), therefore that character of the beam is drawn with the regular yellow PAPER/white INK attribute.

On reflection, the above aspect is potentially confusing, because of the coincidence of the solar beam detecting white INK - causing the air to sap - and the fact that the solar beam is drawn with white INK.  (Even though the former - Willy's sprite - is non-BRIGHT white, whereas the beam's INK attribute is BRIGHT white.)

A further modification (screenshot attached) helps to provide clarity.  This time, the solar beam's INK setting is cyan - the rationale being that Willy is 'blue in the face, gasping for air'! - which applies whether the beam is sapping (red PAPER) or not (yellow PAPER - so it temporarily and harmlessly colours the guardians' INK cyan as well).

Note that Willy's INK was still coloured non-BRIGHT yellow 'behind the scenes' by the adjacent guardian (before the solar beam's INK overwrote it in the same frame, this time with BRIGHT cyan) - this went unseen, but you can tell by the fact that his front foot (which falls beyond the reach of the beam as it is deflected away) also falls under the guardian's shadow, and so his front foot is visibly rendered with yellow INK in the screenshot.

[IRF]

Furthermore, I would humbly point out that the subtlety of where exactly the light beam is causing Willy harm is lost if it is rendered in red from the first point of contact with Willy and then stays red all the way until the beam terminates.