Jess Ragan

Thanks. I think this game is a little beyond my ability to program, honestly. Whack a mole is one thing, but Alley Cat is a great deal more complex, with a hub and at least five action stages. However, I wouldn't object to doing artwork for someone else, should they want to tackle the game.

Can I just say that this is a really out there choice for a homebrew? It's like you were making... game dot com games or something.

I actually lost some progress earlier when I busted a FOR/NEXT loop, couldn't find the damn thing, and had to restart from a way too old back up copy. Ugh. UGGGGGH. But now has arrived the MYSTERY BYRON! Whack him with the PEEK-0 hammer for a bonus, higher than all other bonuses in the game and perhaps even double that. And gaze in awe at his iridescent green BONUS! sign! It looks nice... the VDP has some gross colors but it comes through on the shades of green. Next? Bombs! Hit them and be blown sky high! (But the program is already the size of many ColecoVision games and it's only 75% finished. I might not be able to make it as explicit as I wanted. I don't know what the overhead is on the compiler. These games go up to 32K, right, Nanochess? Is bank switching a concern, or is that handled auto-magically? whackem_game.rom

Yo yo, I've got some truth to throw down for you intermediate programmers out there. If your program is getting complex enough that the performance is starting to sag, cut down on redundancies! For instance, say you've got a score. Instead of PRINTing that score every time the game loops, update it only when your score changes! The graphic data will stay on the screen, and you don't have to waste the CPU's time having it update on every cycle. It'll give the ColecoVision plenty of time to work on other features. Kind of had to learn that lesson myself with the Byron game, the hard way. Free knowledge for anyone who wants it.

You like what you see with this concept art, or do you think it looks a little weird? Everything's so damn SQUARE with tile based graphics, and the ColecoVision has varying shades of eye-searing orange pinks and gross barf yellows. It doesn't feel as spontaneous as the IBM and Atari versions, yanno? Even though the IBM version had like four colors.

Don't you just hate it when someone makes a post about an arcade game that wasn't released for the ColecoVision, and you think someone's making a port of it to the ColecoVision, except the post is "Wow, don't you wish this game was on the ColecoVision?" This is kind of like one of those posts. Except Alley Cat isn't an arcade game, and I've actually done my homework. Using Tursi's image conversion tool, I've made a couple of ColecoVision ROMs to illustrate what Alley Cat could look like if someone ported it. What I'm learning from this experience is that porting games to the ColecoVision means a lot of compromise, and tailoring specifically for the console. The apartment that works as a hub in Alley Cat looks completely different from the IBM PC Jr. and Atari computer versions, and I don't think there's realistically any way around that. It gives the game (or the prospective game) a different feel from those versions, for better or worse. It's all a little... loud. (I considered putting shadows behind the garbage cans to hide the black parts on their bottoms, but I worried that it would camouflage the cat.) I've also included images for those of you who don't want to spend the time starting a ColecoVision emulator. There's very little difference. alley cat cv.rom alley cat cheese.rom

I was thinking about using the second player keypad as an optional control. Heck, if I were really daring, I could even create an expansion module consisting of a matrix of nine very large buttons, similar to what you might find on an arcade panel. Call it Expansion Module 99: the Mole-er Controller. As for the graphics, I'm using Aseprite to build them. There's a grid option that lets you separate your pixel art into 8x8 chunks, so I can more easily work around the system's limitations. One thing that's weird is that I used your TMScolor program to turn some custom border graphics I made into CV graphics. The top and bottom of the graphics had dithering in it despite my best efforts to limit each line to two colors. But I liked how it looked, so I'll probably keep it that way.

whackem_game.rom We're in the mid to late alpha stage. This demo lets you play one round with standard settings. Once it's finished, the game halts and needs to be restarted either with the reset button on the ColecoVision, or the appropriate option on your favorite CV emulator. I'm liking where this is going. I have the level logic for the first two stages set up, but it's not read yet, nor is that section of the game finished. Adjusting the level stats not only makes the game faster or slower, but can be used to create special situations ("sure shot" stages where players are given a limited number of targets, making accuracy a must, "speed round" stages where TONS of Byrons pop out of the holes, etc.). The original plan was to include bonus stages, but I haven't gotten to that yet... I imagine it'll be tricky. While I'm at it, here are a few conceptual scenes in the game. High scores are a possibility, but let's see where development takes us first. The red game over screen appears only when the player strikes a bomb... it's a little showy and may not be in the final build because of memory constraints. (I'm doing pretty well with ROM size so far, but there's still sound effects to worry about.) Anyway! Give it a spin, let me know what you think.

I'm having trouble just getting past the title, if I can be honest. Parker Bor(e)s would be a good way to describe many of their 2600 games. Even Tutankham, which I was okay with when I played it as a kid, does not hold up under the weight of time, or its arcade counterpart, or even the recent 2600 port of the game that looks nearly arcade perfect by comparison.

Hm. Not the answer I was hoping to hear, but knowing that 0-31 is free for the user to access and change is useful information indeed. Aren't they ordinarily computer commands, like backspace and return and communications with other systems?

Appreciate the encouragement!

Did I ask this? I was meaning to. Say you want to change the colors for text or whatever, but you don't want to change it in the character set, but rather on the screen itself. Is there a span of addresses for this? Say, you printed something on the top row, but you wanted it red (indicating a mistake by the player) rather than its default white and grey color. Can you do that? How would you do that? It'd be really helpful to know this for color strobing and the like.

Do I dare ask what the hell is a Collectorvision club? I know about Opcode's thing, but Collectorvision is doing something too? There's like two competing ColecoVision game distributors? I greatly under-estimated this market...

Fair. There's a part in the BBC film Micro Men where Clive Sinclair actively expresses contempt for video games. "My lifetime of accomplishments has been reduced to Jet Set Fucking Willy!" That contempt for video games is further expressed in the ZX Spectrum hardware, which is hella cheap and completely unsuitable for video games. No sprites. A single channel buzzer for sound. Colors are kept a safe distance apart at all times, like dancing couples at a Mormon prom. I don't even think that system has a joystick port by default; you have to go out and get a Kempston adapter or some such. It's like whoever designed the internals of the ZX Spectrum cackled madly to themselves and shouted, "Just TRY and make this thing play games!" Challenge accepted. There are thousands of ZX Spectrum games, and thousands of Generation X nerds in Britain who grew up with this machine, and still have fond memories of it. When there's a will, there's a way. People would (and have) gamed on a calculator, after all.

I'm old enough to remember a time when sprites were the deluxe package, rather than standard equipment on video game hardware. "Watch in awe as a small patch of graphic data is seamlessly moved across a complex background, without one affecting the other! It's like maaaaagic!" (I remember back in 1996, when I was making shareware for DOS PCs, how distinctly irritating it was that there were no hardware sprites available. There were screen stamps, but they're not the friggin' same thing, due in large part to the lack of collision detection and the stamps polluting any graphics underneath them. It was 1996. 1996, and this hardware standard STILL didn't have sprites. The Commodore 64 had sprites! The TI 99 4/A had sprites! What gives, IBM?)