THOUGHT I'D WRITE A BIT about what I'm planning to do for the 2006 Minigame Compo.
Bigger enemies! Plus falling brick!
Your goal: the suitcase full of cash.
About to Squish 'Em!
Ooh, now he pops back up and is angry! (White and unSquishable.)
It's a pretty fun game; I enjoyed it a bunch 20+ years ago (and last night, for that matter).
Looking a little closer...
I really think the game was originally designed for the VCS!
Check it out:
-6-digit score, though the 8bits can easily support a score as wide as the screen.
-The playfield is symmetrical, but only the center. There are obvious reasons why it is easier to have a partially symmetrical playfield on the VCS, holding PF0 static; no real reason why on the A8.
-Relatedly, the left eight pixels are blank for most of the screen. No real compelling reason to do this on the A8; on the 2600 this would hide unsightly HMOVE lines.
-Most notably: only two sprites on any one scanline: the man and the enemy. This is really inexplicable; the A8 could support up to 3 enemies on any one platform without flicker and still have the missiles left over for the falling brick.
-Also notable: color changes, both in the playfield and on the man, happen on a line-by-line basis. This is a limitation of the 2600; not necessarily of the A8. (Since only one sprite is used for the enemies, you could use all 3 sprites for the man, which would allow more than one color per row.)
-Also: the score and the extra men are on different lines, despite the fact that they don't overlap.
And of course, after writing all this down and being proud of my amazing detective skills, I go back and read the instructions, which have a Atari 2600 section.
So, has this ever turned up? Interesting that a game obviously designed with the 2600's limitations in mind (and apparently developed simultaneously for the 2600, A8, Colecovision, and VIC-20) would then *not* end up being developed/released for that platform.
Anyway, given all that, you'd think that a 2600 conversion would be easy, right? Well, I though so, anyway.
But after writing some things down, it turns out to be a little trickier than I thought. There isn't enough time for a partially symmetric playfield, two single-line-resolution sprites (one with single-line-resolution color changes), a falling brick, and all the counter updates and loop maintenance stuff.
So...first order of business: what feature gets cut?
After a bunch of thinking and scribbling last night, I figured that PF1 only is used to display 2 "pipes;" PF2 is used to display four. So, why not make PF1 symmetric as well as PF0? With that change, I think everything else will fit.
(Question for A8 folks: After counting and recounting on my TV screen last night, Squish 'Em only displays 144 pixels left-to-right - what's that all about?)