Jump to content
  • entries
    106
  • comments
    796
  • views
    140,721

Minigame Compo 2006 Possible Entry


vdub_bobby

1,171 views

THOUGHT I'D WRITE A BIT about what I'm planning to do for the 2006 Minigame Compo.

 

A 4K port of Squish 'Em, an early 8bit game. (Yes, I was planning this before I read this. :P)

 

Screenshots:

Typical screenshot:

blog-6060-1142445130_thumb.png

Bigger enemies! Plus falling brick!

blog-6060-1142445123_thumb.png

Your goal: the suitcase full of cash. :)

blog-6060-1142445075_thumb.png

About to Squish 'Em!

blog-6060-1142445150_thumb.png

Squished!

blog-6060-1142445137_thumb.png

Ooh, now he pops back up and is angry! (White and unSquishable.)

blog-6060-1142445143_thumb.png

 

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. :lol:

 

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

11 Comments


Recommended Comments

Interesting. I played it on the C64. The C64 has improved graphics over this:

http://www.lemon64.com/games/details.php?ID=2443

 

Tony Ngo is an incredible designer, he also did Park Patrol! :thumbsup:

 

I wonder what the relation between Sirius and Activision is. I assume at some point Sirius was assimilated by Activision. That's how Park Patrol, Pastfinder and Zone Ranger became Activision titles and Activision re-released titles like Fast-Eddy.

Link to comment

Hmmm. Just played the C64 version as well. My impressions:

 

Graphics, especially pipes/girders, bricks, and the man are better, but not tremendously so for any individual object; the combined effect looks much better than the A8 version, though. The man, especially, benefits from a much wider sprite.

On the other hand, the enemy sprites, though multi-colored, look worse to me: much blockier and just generally uglier. Also, the falling objects (no longer just bricks!) have crappy 2-frame animations. They would look better as un-animated falling objects.

The game moves slower. The A8 manual has the claim from Tony Ngo that all enemies can be jumped over; I would dispute that claim as applied to the C64 version! The man and, especially, the enemies move so slowly from L-to-R that sometimes the enemies cannot be jumped over! That's a somewhat major design flaw.

The music I like better on the A8; might just be because of fond memories from my youth. :thumbsup:

 

Overall, the slower pace of the C64 version kills it for me; despite it's graphical improvements.

 

The weird thing is this: The A8 would have a hard time matching the width of the C64's sprites, but all the other graphical improvements are fairly trivial on the A8, as far as I know. It wouldn't be hard to use a redefined char set for the bricks, pipes, and girders, giving a much better look. And you could pretty easily use two sprites for the man to give him him a better look (i.e., more colors per row) and similarly for the enemy sprites, and still have the missiles left over to combine into a single-colored sprite to use for the falling objects.

Link to comment

If you look at some PoP kernels, maybe you can get away without having to cut any kernel feature.

Which PoP kernels? The ones cd-w has written or the ones you wrote way back when?

 

And - I could keep everything in there if I went to two-line-resolution for the sprites. But I don't think losing asymmetry on PF1 is that big of a deal and I think the sprites would really suffer at 2-line resolution.

 

But I'll take a look. :thumbsup:

Link to comment

Hi there,

 

It looks a lot like my 2600 version of Climber 5. I may be over simplifying things but I think all this can fit without compromise. Of course I know it's easy to say that without proof :thumbsup:

 

Go for it! I think it would make a wonderful addition to the library.

Link to comment

After playing the game a little more I say it is doable.

 

The main sprite doesn't use the whole height of the kernel. Also it looks like the enemies don't use the whole height of a "zone". Knowing this you could swap data for the enemies while drawing the zone. The falling brick could be a ball which would have the same color as the PF (I don't see this as a problem).

 

:thumbsup:

Link to comment

I have fond memories of this game, too. Ahhh, to be young again... *sniffle*

 

Didn't this game have some sweet sound effects? And those little spider-esque, squiggly line sprites (in the first screenshot)! This game is so classic!

Link to comment

Which PoP kernels? The ones cd-w has written or the ones you wrote way back when?

Those without SC requirements. That would be mine or the earlier ones of cd-w.

Link to comment

Not any news. But the 4K minigame deadline is still months away; I decided to put this aside while I worked on something else. :)

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...