Skip to main content

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
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)

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.


Popular posts from this blog

Polymer Picker, and why 8-bit programming matters to me

Late last year, I released a BBC Micro game, Polymer Picker . Realising that 2022 marked the centenary of the BBC, as well as the 40th anniversary of the release of the BBC computer (which was designated as one of the BBC's 100 Objects ), I wanted to work on something that related to the BBC's mission of being able to 'educate, inform and entertain' . So what better way than to release a game for the BBC computer, that in a sense, fulfils those values? But, with video games being so widely available, and playable on all kinds of devices, why did I decide to create my own game for such a niche platform?  Video games are big business. They have been for a number of years. In May 2023, it was reported that Nintendo's latest edition of The Legend of Zelda sold in excess of 10 million copies in three days .  However, there remains sustained interest in video games from yesteryear. Children who grew up in the 8-bit computer revolution are now into their 40s and 50s, and

Using Beebasm for BBC Basic games programming (Mac & Windows)

In August 2021, I released Androidz Redux , a remastered version of my 1994 game Androidz . This process started a year ago, with a couple of days spent playing around with the original code, far away from a real BBC computer. The original game was published in a magazine called Acorn Computing, and has been available to play online for a number of years now. Because I wrote the game on an actual BBC Micro, I used what tools I had at the time, namely some graph paper to create the graphics, and the computer itself to do the actual coding. This is a world away from the tools we now have at our disposal. Fully rounded IDE's such as Visual Studio Code (my current favourite) make it an awful lot easier to program games. Even editors such as Notepad++ offers some ability to edit BBC Basic code. One of the difficulties with editing old games on modern systems is ensuring that you are able to ensure that the BASIC code is properly tokenised before running on an emulator/system, and indee

Blogger for Word and DirectNIC

Now I can use Word to make postings. This post was done using it. Glad to see that my office installation of Word works properly with it. I think now that my personal website has settled down nicely. The only major downtime for which I had to make workarounds was DirectNIC ’s hosting of one of my work sites. Hurricane Katrina brought New Orleans practically underwater, taking down some of their infrastructure. I did say things were coming back to normal, which is somewhat optimistic, as the Mayor of New Orleans has ordered everybody to leave the city, as it is in no habitable condition. In fact, DirectNIC have been keeping their servers on with diesel generators, and some of their team have been holed up in the building during the whole event. Their blog has been reported widely in the media, since apart from their postings, they have had photos, and live camera feeds showing how things really are from the center of the city. Btw, I’ve moved the worksite back to them now, f