Blue Meanie - a most vicious puzzle game

I sporadically make visits to the BBC Micro games archive, and have a quick blast through some arcade smashes of the past, and lesser known titles. Hidden amongst the catalogue are some real gems.

Mike Goldberg's Blue Meanie is one of them.

Anyone familiar with the BBC Micro games scene may know the name of Mike Goldberg. An artist and illustrator, he created many pieces of artwork for various magazines during the 80s and early 90s. He has a distinctive style, and is very obsessed with cats. These artistic talents were evident in the games he had published commercially (notably, under the MRM brand - he was one of the M's), as well as within the pages of computer magazines. Most of his work was featured in The Micro User, or Let's Compute!, then dubbed the world's first computer comic.

This latter period - from 1989 to 1991 - saw Goldberg produce games for typing in from the pages of the magazine. These games became more and more advanced in design and execution. Out of them all, I would say he reached the heights of originality and technical accomplishment with the puzzle game Blue Meanie. Published in the July 1990 issue of the magazine (this link is a zipped PDF of the issue), it was quite a hefty listing to type in, but if you look at the large, bright graphics, you can appreciate why.

Arguably some of the largest sprites to ever grace the platform, the game made great use of the four colour low resolution Mode 5 palette to create bright and bold graphics.

But beneath the cute exterior, lies some fiendish brain bending puzzles. The plot is simple enough, guide the Blue Meanie through 30 rooms full of junk, collecting a given item, then heading for the exit. The junk in each room consists of various objects, which move and interact with each other in different ways.

Additionally, and here was the crucial part, how you completed a level directly influenced the layout of the next, as an increasing portion of the previous level remained onscreen when you proceed. This meant that you had to carefully consider how you pushed or converted objects in case they made the next level impossible to complete.

Every five or so rooms, you would start with a completely fresh level, but that was small gruel for what could become an utterly frustrating experience. And with only a 60 second countdown to escape each room, this would have me thumping the keyboard in utter frustration!

Although the game has been available for many years as a download, playing it online via the site reveals the limitations of onscreen instructions. Mick Brown has done an absolutely stellar job of curating much of the content for the games site, and included instructions from the magazine into the games, as much as possible.

In the case of Blue Meanie however, the description and behaviour of the various objects is somehow lost, without the visual guide that accompanied the listing in the magazine. Here are screenshots from the magazine showing how each block is supposed to behave.

Having played the game several time, I am pretty sure that the behaviour of one of the objects does not match what is described, and am wondering if there is some sort of bug.

The block in question is the Magnet. The magnet behaves as intended when pushed up or down, attracting the nearest Up block. However, I could not get the block to attract the nearest Chest, when pushed left or right. Any opportunity I had to attempt this did not result in the intended behaviour.

The archive site allows you to examine the contents of each game 'disc'. Opening up the PDF, and the game disc, I had a browse through the code. Blue Meanie uses some assembly language to enhance the speed of sprite rendering, but a lot of the code is written in BBC Basic. The ability to mix assembly language within BBC Basic is a really good thing, as you can take advantage of the speed gain without having to go the whole way to producing a fully machine coded (and therefore, more difficult to follow) end product.

Here, in listing 4, are two procedures - PROChitUD and PROChitLR. These determine which block is being pushed. Within the two are some SOUND statements, which allowed me to figure out which lines are used to determine whether you are using the Magnet.

From PROChitUD:

1120 IF(X%?y%)=143AND(X%?-960)=0SOUND1,8,145,1:PROCslide(X%-640,X%-960,-320,&5180):ENDPROC
1130 IF(X%?y%)=122AND(X%?1920)=0SOUND1,8,145,1:PROCslide(X%+1280,X%+1600,320,&5180):ENDPROC

And from PROChitLR:

1310 IF(X%?y%)=122AND(X%?64)=0SOUND1,8,145,1:PROCslide(X%+32,X%+56,8,&5180):ENDPROC
1320 IF(X%?y%)=229AND(X%?-40)=0SOUND1,8,145,1:PROCslide(X%-32,X%-56,-8,&5180):ENDPROC

The X%?y% is what I believe to be an indirection operator, 'poking' the region of screen memory represented by X%, and bringing back a value that is present there, which represents which sprite you are hitting (either moving up or down, or moving left or right, hence the two different procedures). However, the SOUND statement gave the clue as to which block this was. &5180 happens to be the memory address that refers to the Magnet sprite itself.

PROCslide actually performs the animation of the given block you are moving. Within the procedure, the number &5180 comes up again. The Magnet block requires special treatment:

1500 IFn%=&5180PROCattract(J%)

PROCattract is used to establish (or supposed to) which Up or Chest block is to be swallowed up by the Magnet:

1520 DEFPROCattract(J%)
1530 u%=J%:v%=J%
1540 uok%=0:vok%=0:stop%=0
1550 REPEAT
1560 IFuok%=0u%=u%-32
1570 IFvok%=0v%=v%+32
1580 IF?u%=255uok%=1
1590 IF?v%=255vok%=1
1600 IF?u%=120stop%=1
1610 IF?v%=120stop%=2
1620 IFu%=exit%uok%=1
1630 IFv%=exit%vok%=1
1640 UNTILuok%=1ANDvok%=1ORstop%>0
1650 IFstop%=1ANDu%+32=exit%ENDPROC
1660 IFstop%=2ANDv%-32=exit%ENDPROC
1670 IFstop%=1SOUND2,7,12,10:PROCslide(u%,J%-8,8,&50C0)
1680 IFstop%=2SOUND2,7,12,10:PROCslide(v%,J%+8,-8,&50C0)
1690 ENDPROC

Truth be told, I don't exactly know what is happening here. My guess is that the code is attempting to figure out where the nearest item (Magnet or Chest) is, and then it slides that item towards the magnet, via the call to PROCslide. One call moves the item left, while the other moves it right.

But, look at the last argument in both calls. The sprite address in both calls is the same - &50C0. If I take a look back at the PROChitUD and PROChitLR procedures, I see the only reference to this address occurs in PROChitUD:

1110 IF(X%?y%)=232AND(X%?-960)<>255AND(X%?-960)<>iH%SOUND1,1,22,1:PROCslide(X%-640,X%-960,-320,&50C0):ENDPROC

By testing the SOUND command in this line, I can confirm that &50C0 actually refers to the Up block! Chests are not affected at all. So, the instructions are incorrect, concerning the behaviour of the Magnet.

The above scan from the magazine should instead state:

Magnet: Can be moved in any direction. It attracts the nearest Up block if being pushed up, down, left or right, unless a Blue is in the way.

This has been bugging me for ages, and I finally took the time to work out what was going on. I'll have to play the game again to confirm if this behaviour does indeed work as intended. If anyone else can test this, feel free to play the game to confirm if I am not mad!

You see what a pandemic does for me? Solving a 30 year long problem!

Update (2nd Oct, 2020): the thread I started on Stardot about the game has resulted in a revised version being created with modified instructions. This not only includes the Magnet behaviour, but improved descriptions of how items such as the railings and snooker tables behave. If you ask me, the above screenshots should be displayed next to your browser window, so you have a handy onscreen reference. You'll definitely need them for some of the screens.