IRF

I was thinking the same thing about the topic having 'veered off' a bit. To bring it back on topic, JianYang mentioned that they found the game a bit too fast. There is a combination of keypresses which will slow the game down, which would perhaps make it more playable. (NS revealed it to me in private correspondence.) Question for NS: would it be appropriate to reveal this secret here, or is it not intended for public knowledge? P.S. I would like to add my appreciation of your FREE contributions as well, Norman Sword!

My personal experience was that v2.2.9 was more buggy - it crashed more often - and is therefore less 'stable' to my mind than v2.3.7 is. So I would also recommend just using the latter as it has more features and ironed out some annoying aspects of the former. Plus it's probably easier just to get used to using one version. P.S. I seem to recall that I once compiled a list of suggestions, in case John Elliott ever got round to doing another update of the editor.

I can't help thinking that it might be possible, in theory, to beat a total score of 40,000? Or, failing that, at least 39,500? Perhaps with a bit more judicious jumping in Solar Power Generator to avoid the solar beam (which saps air and therefore reduces the potential score whenever Willy gets touched by it)? EDIT: I take back that last point about the solar cavern - I just watched Danny's recordings of it (in both BB and SP versions of the game), and he manages to get Willy in almost exactly the right place throughout, so that he hardly ever gets zapped by the beam!

If the fast speed is panicking JianYang, then maybe that is the point of 'Manic Panic'... 😄

Here are some further ideas: The collectable items could be Christmas presents. (Either that or fairy lights, since the items do 'twinkle'!) Deadly baubles on the branches? I think the water/ramp cells in 'Out on a Limb' look very 'coniferous'. I wonder whether this should be a mini-game (10 to 20 rooms), as 64 rooms of tree branches might be a bit repetitive? If it is a full game, then perhaps the lower levels should be a few rooms across, with only the upper reaches being a single room (split down the middle by the trunk) wide? That way, it would taper inwards from the bottom to the top, like a Christmas tree! Obviously there should be either a star (a multi-component guardian, like the demon in 'Entrance to Hades'?) or a guardian fairy - something difficult to navigate past anyway - at the very top of the tree! Maybe there is a nativity scene under the tree on the far side, and the mission is to reach the stable and deliver all the presents to the Baby Jesus? You have to get past Mary/Maria first though! 'Jingle Bells' would fit perfectly as a 64-note in-game tune. With a different Christmas carol as the title tune, to accompany a snazzy Christmassy title screen. Willy's sprite is wearing a Santa hat.

'Willy's Christmas Caper' sounds like a great idea, Danny! Like the upper rooms of the Banyan Tree (i.e. A Bit of Tree and the lower half of Under the Roof), but stretching upwards for many more levels/rooms before you can cross from one side to the other. I presume it would be Christmas presents that you have to collect from amongst the branches? (Whilst dodging deadly baubles?) P.S. Perhaps you should create a new topic for other Xmassy suggestions?

BTW, that's a very interesting titbit of knowledge about JSW2. 🙂 We should probably give Pgyuri a shout anyway, pointing him to this project and saying: "Look what someone else has done with a similar idea to yours (developed independently). It would be a good way to announce the revival of this site over on WoS. 😀

And Mr Rowson gets credit then. 😉

Good stuff! I feel that Pgyuri (or is it Pyguri?) from the World of Spectrum forum deserves a mention, for having come up with the original 'dark cavern' idea 💡 which inspired the 'Lantern' and 'Torch' game modes of this project - although of course Mr Sword has refined the idea greatly and made the dark caverns infinitely more playable! 👍

If Manic Panic has reached the status of 'finished product', I wonder whether it would have a higher profile if you were to upload it to the Downloads section of the site (which should automatically generate a new discussion topic as well), rather than putting it at the end of the existing 'Playing Around' discussion? Just a thought..

Excellent!

The start of the Move Willy(3) routine (#8FBC-#8FD0) could be simplified/shortened: Within that part of the routine, Willy's Direction and Movement Flags variable (#85D0) is loaded up to A twice. (First to check if he's moving left or right - Bit 1 - and RET to Main Loop if he isn't; then to check which way he's moving, left or right? - via Bit 0 - before deciding which path to proceed through the rest of the routine.) But in between those two checks, the Rope Status Indicator (#85D6) is loaded up to A and its value tested (with a RET to Main Loop if Willy's on a rope). If the test of the rope status is put first in that sequence, before the movement/direction flags are loaded up to A, then you could test Bits 1 and 0 of A in turn (reacting accordingly) via BIT instructions, thus removing the need to reload #85D0 into the Accumulator for a second time. That should provide a modest saving of three bytes.

When Norman is back and picks this up, I wonder if he would be amenable to Daniel Gromann creating an entry for some future update of his website jswcentral.org for 'Manic Panic'? The many novelties in the project mean it's definitely worthy of an entry!

In response to the suggestion in bold, I've taken a look at what it would take for Willy to be able to observe the portal guardians from a 'leap of faith' vantage point at the top of the relevant caverns (Cold Room and Return of Kong). For the Cold Room, the torch beam would have to extend downwards by at least 16 character-rows below Willy's feet; for Return of Kong, it would need to reach 14 rows down. By way of comparison, the beam currently reaches a depth of 9 rows below Willy's feet (and a height of 10 rows above his head when pointed upwards). So the torch beam would need to be much 'stronger' in order to resolve the 'leap of faith' issue. But that might disturb the current aesthetics a bit too much? **** Sounds like the cavern roof is leaking... That gives me an idea for an advanced modification - water slowly flooding a cavern from the bottom up, one character-row every minute or so (or maybe even a pixel-row at a time)... If Willy goes under the water (e.g. to reach the portal at the end), then the air supply depletes super quickly! Anyway, that's an idea perhaps for another day - happy summer to you too!

I think his username is Pgyuri, not Pyguri. (A typo which I was guilty of myself last night!) He did do a variant where you can set off a 'flare' - only five of which are available per cavern - if you press a certain key it sets the Screen Flash Counter variable to 7, so that all the visible screen elements cycle down from white to black (like what happens when you gain an extra life in the original Manic Miner). That effect allows you to survey the whole cavern for precisely seven time-frames of the game, which does make it slightly more playable/less insane. (Nowhere near as playable as it is with Normans Sword's Torch beam though.) I wonder whether it would be worth 'borrowing' the flare idea to cover the few scenarios where the torch beam doesn't reach far enough. e.g. when dropping down into the open portal from the top of caverns such as the ones based on the Cold Room and Return of Kong. In both of those scenarios there is a horizontal guardian which intermittently either goes through the portal [Cold Room penguin], or passes the portal just above it [rolling rock in Return of Kong]. In Candle Mode it's pure guesswork when dropping down as to whether you're going to hit the guardian or not before you manage to reach the portal! Setting off a flare before you make the drop could help you to get the timing right.

I wasn't suggesting anything needed changing with the blue conveyor, just thought it was worthy of a mention. As you say, it would be impossible to iron out every logical inconsistency. Another example: in the attached image, it could be argued that the red crumbly cells at the top right shouldn't be illuminated by the torch, considering that Willy is positioned behind a solid wall and floor at that moment in time. But trying to make the logic of the torchbeam's illumination contingent on the room layout surrounding Willy's current position would be a nightmare to implement! Anyway, you've done a great job expanding out Pyguri's concept of the torchlit caverns. :)

I forgot to say that the question of whether or not the air supply depletion is paused (because Willy isn't moving), in the recording referred to above, follows the same pattern. i.e. Air continues to be depleted when Willy is only prevented from moving because he is blocked by a wall, but isn't depleted in all the other scenarios: when Willy turns on the spot, or jumps or drops vertically onto a conveyor whilst the 'upstream' key is pressed. Again, the discrepancy has been resolved in MP13.

One more short recording, to demonstrate a (harmless) visual quirk I noticed in Torch Mode. See the conveyor above Willy's head when the torch beam is rotated to certain angles. Some portions of the conveyor seem to be colour-inverted compared with the rest of the conveyor. I think this is because the normal colour setting for the conveyor in question is black INK on blue PAPER, but in Torch Mode everything that isn't lit up by the torch beam is rendered in blue INK on black PAPER. MP12 Conveyor Animation.rzx

If Willy is trying to walk up a conveyor but is stopped by a wall, he is technically still moving sideways (the Movement Flag is set). As distinct from when he jumps or falls vertically onto a conveyor with the 'upstream' key kept pressed, or when he does a 'turn around on the spot' manoeuvre on a conveyor. The attached recording was done whilst playing MP12 in Candle Mode. The first time Willy is on the conveyor, with the Right key depressed but up against a wall, I tried to rotate the torch beam using H-J but failed. Then I let go of the Right key and immediately pressed it again (then kept it depressed). Willy turns round on the spot and stays put. This time I could rotate the beam using H-J keys. I then made Willy fall onto the conveyor with the Right key depressed, and again I could rotate the beam. A bit later in the recording I jumped vertically up onto another conveyor, with the Right [upstream] key depressed, and once again I could rotate the beam. It's good that you have resolved the discrepancy between the different scenarios, in MP13. :) MP12 Conveyor Torch Rotation.rzx

Thanks for the latest (final?) file, Norman! Having seen it in action, I can now answer my own questions in red:

Regarding the above oddity, I've been back and checked and that was the case in the earlier Manic Panic files as well, I just didn't notice it at the time. **** Back on the subject of rotating the torch beam, if Willy finds himself on a conveyor belt standing still (e.g. if you fall onto a conveyor whilst keeping the 'upstream' sideways movement key depressed, so the keypress and the conveyor cancel each other out), are the rotate keys active whilst Willy remains stationary on the conveyor? I presume the answer is yes, because the sideways movement flag isn't set in that situation, even though a Left-Right movement key is being pressed by the player.

Question: in Eugene's Lair, why when I first enter the cavern is the vertical Amoebatron colour-cycling (as if it is an 'Angry Eugene', although it doesn't settle down directly above the portal in the way Angry Eugene does), but then if I lose a life and the cavern is refreshed, the Amoebatron stops colour-cycling and remains cyan (until such time that all the items have been collected, at which point the colour cycling kicks in again and it descends to guard the portal as you would expect)?

My replies in red:

To be clear, I wasn't suggesting that Willy should automatically look downwards when he falls down a shaft. I just wondered whether the player retains the ability to rotate the torch beam whilst he is falling. I would have expected that this would not be possible in your earlier test file (described in post #164 of this thread), where you had forced the beam to face forwards based on Willy's facing direction AND based on his jump/fall counter*. But I would have expected that it would be possible to look down whilst falling in the later test file (described in post #166), where you only tested Willy's facing direction and not the jump/fall counter to decide whether to force a sideways beam. It sounds like you have proved me wrong on that point? (*Actually, there are two separate variables involved in jumping. There is a joint variable for Airborne Status, which is reset to 00 by default, holds 01 when jumping, values from 02 upwards when falling - acting as a Fall Counter - and is set to -01 [#FF] as a 'Willy is dead' indicator. And a separate Jump Counter variable which keeps track of Willy's progress through a jump. I presume the former is the one that we're talking about in terms of what you were testing at one stage, to determine whether to make the torch beam face forwards?)

It is also not possible to look all around whilst Willy is being moved along by a conveyor, where you might expect* him to be able to do so. That would probably require a fundamental change in logic, with the check for Left-Right keypresses temporarily disabling the check for Clockwise-Anticlockwise keypresses. i.e. the basis for being unable to rotate the lamp wouldn't be "Is Willy moving sideways?", but "Is the player actively moving Willy sideways?" (*Then again, logic would dictate that his legs shouldn't animate in that scenario either, as you pointed out elsewhere a while ago.)