IRF

Fabian, I should warn you that there is a bug in the JSW64 game engine, which may or may not affect your game. Do you have any 'Skylab' type entities in the game? (i.e. Droplets that shift horizontally in between each descent.) Because if there are any Skylabs, what you will find is that, once you have visited the room containing Droplets during the course of playing the game, then the Skylabs will be turned into Droplets (i.e. They will no long shift their horizontal position), and that will remain the case even if you abandon the game and start a new one. (Only reloading the game file will revert them back to horizontally-shifting Skylabs.) There is a fix for this bug though, should you need it. Let me know if the game contains both Droplets AND Skylabs, and I'll go back through my notes and dig out the bugfix.

I haven't had chance yet, no. It's on the To Do list.

Fabian, whilst assisting Daniel with his conversion of 'Madam Blavskja's Carnival Macabre' from 128K to 48K, I discovered an unused two-frame sprite buried in the code. It looks like some kind of one googly-eyed robot. Perhaps it could be used somewhere in your Roddenwald project? (I also noticed that there was an unused frame of animation for the 'Playing Card' guardian in the room 'Malocchio's Games of Chance' - the guardian in question doesn't animate, staying stuck on the same animation frame. But the presence of another unused frame seems to suggest that it was supposed to alternate between looking left and right?)

The likeness is even more uncanny in this one...

Funnily enough, I was thinking the other day that the coronavirus looks like the vertical guardians in Wacky Amoebatrons (in both game engines).

I just tried out cavern 23 - it's a great, multi-faceted puzzle!

It's here: http://jswmm.co.uk/topic/518-file-jsw128vm/ Once you're on the title screen, if you press 'O' then you get an options screen which allows you to change a LOT of things about the game - the ability for Willy to shoot a gun or a bow&arrow is just one of many new features...

I've just discovered the excellent set of accompanying notes (in PDF format) which Norman Sword added to the first post in this thread, via a subsequent edit a few days after the original post.

One of Norman Sword's working files, posted here on this forum, gives Willy a Licence to Kill...

Hint: they are based on real-world phenomena. Maybe it's too difficult... Look at them closely; what are they? Hope you feel better soon Fabian. But on a related note, and in response to the above quote, I haven't seen the guardians in question yet but I'm going to take a wild guess that the "real-world phenomenon" they are based on is the Coronavirus?

Congratulations, Danny! And Fabian, it's a great game!

There is a potential flaw in the JSW128 game engine (or at least in John Elliott's explanatory notes for the engine). Whilst the original guardian class table (#A000-#A3FF) provides a #FF Terminator byte at the address #A3F8, if you create further guardian class tables then another #FF Terminator byte needs to be inserted at the start of the final 8-byte entry of the additional tables. e.g. - If you create an additional guardian class table across pages #D8-DB of memory, then an #FF value needs to be inserted at address #DBF8. If you don't do that, and if the first entry of the additional table has a defined guardian (i.e. of Class #00), then there is a risk that the code which populates the guardian buffer (#8922-#8949) will cause errant Class #00 guardians to appear in any room* that uses the additional guardian class table, with potentially disastrous consequences! (*Unless said room has a full complement of eight guardians, or unless the structure 'FF 00 FF 00 FF 00 etc' is used to terminate a less-populated room's guardian list, instead of 'FF 00 00 00 00 00 etc'.) The explanatory notes for the JSW128 game engine should alert the game designer of the need to include a #FF Terminator byte at the start of the last slot in every guardian table (unless the editor could be made to automatically insert the Terminator byte whenever a new guardian table is created). ** EDIT: A similar bug afflicts the Softricks Edition of JSW - for the same reason, there should be an #FF byte at address #A7F8 (corresponding to the start of the last entry in the double-length guardian class table in the Softricks engine), but it seems that there isn't. ** FURTHER EDIT: There is also a glitch in JSWED, whereby if a room has a full complement of eight guardians, and if you delete one of them in JSWED's GUI [other than the last one in the list] and then navigate away from that room in the GUI before replacing the guardian that you've just deleted, then a guardian of class #00 (if guardian class #00 has been defined) appears at the left-hand side of the room when you play the game, due to the failure of JSWED to write a 'Terminator' byte into the guardian list for that room. I guess what happens is that, in general, when you delete a guardian from an early slot in the guardian instance list (guardians are listed as pairs of values in Offsets #F0-#FF in the room definition), then the later entries get shuffled up to fill the gap. If there were fewer than eight guardians then there will be an #FF Terminator byte at one of the even addresses in the range of Offsets #F0-#FF, and it will gets shuffled up as well. But if there were a full complement of eight guardians prior to the deletion of one of them, then seemingly Offsets #FE-FF for the room are just NOPped out, and this is interpreted as an instance of Guardian Class #00 in the room (with a horizontal coordinate of 00).

I can change the CC robot sprite now (in V6b).

On V6, for me for some reason, I can change the colour of the horizontal robot in Central Cavern, and I can toggle it between 4-frame and 8-frame versions when the background colour behind the +/- symbol is blue. But I can't select a different sprite for the Central Cavern robot. :unsure: :wacko:

Ah, I've just seen the notes, and discovered the use of the 'P' key for toggling between 4 and 8 frames for horizontals guardians. The flaw you've discussed probably explains why I can't seem to change the sprites for some of the guardians.

I just noticed that a V6 has been uploaded (attached to post 1 in this thread). I'm not sure what the difference is with it, but I tried to change a guardian's sprite, failed to do so, but ended up with it walking backwards! Oh, and a big red number '5' appears now when the editor is viewed in 'guardians moving' mode. (I'm not sure what the '5' signifies?)

I left a big clue in post 17 of this thread. ;)

I cracked the cheat code a while ago, as you know (but kept it under my hat). Daniel was halfway to cracking it when he started this thread. Then he got distracted by another project whose release is imminent - after which he should be able to resume work on this puzzle...

Welcome, Fabian! I was recently introduced to your JSW games - I've been helping Jetsetdanny out with his project to convert your 'Madam Blavskja's Carnival Macabre' to the 48K game engine. It's a nice, very atmospheric game. ?

I'll save my congratulations until it's released! ;-)

Nice touch in V5 to make the border colour match/indicate the selected guardian colour. :)

Fair enough. Presumably with horizontal guardians it would be more difficult to store the colour, because the 'speed' bit for HGs shares a byte. Vertical guardians just have a single byte dedicated to the attribute. (That's assuming that the guardian data storage may be as it is in original MM; yours may be compressed?)

I tried editing the guardian in V4. I managed to successfully change the sprites for a guardian (i.e. the pixel pattern which is drawn), and that change persisted once I left the editor. I could also change the colours of guardians within the editor, but when I went to exit the editor and play the game, the colours reverted. So for example, in Central Cavern you can have a yellow penguin replacing the yellow robot patrolling along the green conveyor. But you can't change that to a red penguin (well, you can in the editor but not in the game itself).