Jess Ragan

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

Legend has it that Nintendo studied the hardware of the ColecoVision very carefully before releasing the NES, which is probably why it seemed to address all the limitations of that system and the SG-1000. No more scrolling issues, no RAM bottleneck, no limitation of two colors per 1x8 line, etc. etc. They also finally killed that damn numeric keypad trend from the late 1970s and early 1980s, where every game system just had to have a touch tone telephone receiver built into the front. You do not need this abundance of buttons! You could make gameplay a whole lot smoother and less confusing just by using a better interface. Er, anyway. Unlike before when I was a mere spectator, I'm actually looking at the ColecoVision from the inside. I'm in the process of making a game, and have done several demos. It adds perspective, and makes me realize just how involved it is to make games, and by extension artwork, for this system. Donkey Kong looks kind of weird and simplified in the ColecoVision version of that game, because the hardware necessitated those changes. I don't know what you did to get around this, Opcode... I'm assuming you pulled out a heaping helping of those "magic sprites" Nanochess talks about to fill in the color gaps?

Like this faintly animated ROM featuring the YouTube semi-sensation Layman Video Gamer. Layman said he loved the ColecoVision... let's see how much he likes being INSIDE one! It'll be like that one especially ridiculous episode of Spider-Man and His Amazing Friends, when they're fighting Video Man. I just realized that instead of just games, people can whip up greeting cards and all sorts of weirdness on the ColecoVision. Maybe I shouldn't encourage that... the complete list of NES games is thousands and thousands of entries long because everybody kept using NESticle to turn Mega Man into Mega Butt and River City Ransom into Wilford Brimley Battle. layman.rom

I saw footage of this on YouTube. It's janky and limited in that distinct ColecoVision/MSX way, but it aims pretty high for that format, and actually looks better than the Micronics NES version in some respects. At the same time, it does illustrate that the CV wasn't capable of keeping up with the gaming trends of the mid 1980s, particularly scrolling.

It's legendary kusoge, among the worst games on the Super NES. As a result, it's frequently reviewed by YouTube content creators, particularly the yellers like AVGN. That notoriety probably explains its high market value. (Don't buy it, though! It's crap! It's like the Simpsons arcade game, if it had been made by the people who made Bart vs. The Space Mutants!)

It'd make more sense if you saw the ending in the arcade version. Just... trust me on this one.

whackem_game.rom Fixed the previously mentioned issues, and added some extra graphics for when Byron gets bonked. Oh, this is shaping up pretty darned well!

We have collision detection! And point labels! (You would not believe how annoyed I get when ColecoVision arcade ports don't have these.) One slight problem: new Byrons will pop up in holes where there is already activity from bonked Byrons. This seems easy enough to fix, by placing a flag in the PoppinByrons routine preventing new Byrons from being spawned in those locations. There's still no trace of sound or music. I have ideas for these, but as I've stated before this is not my strong suit. whackem_game.rom

On a related note, can you check for tiles near or colliding with a sprite? I presume VPEEK would be the way to go for this.

Dang! Good call! I just made the change and the game runs more consistently now. Can you explain why?

whackem_game.romwhackem_game.bas The game! It's starting to resemble a game! I'm excited. So far I've got a working mallet, a working score (built from one 16-bit variable and one 8-bit variable; when both are full the score rolls over), a working timer, and one to three Byrons that pop out of holes when the timer "interval" reaches "intervalmax." There is still no collision detection; I'll need to squeeze that in there in a later update. The game is probably way too fast at the moment, but I'm planning to include a dynamic difficulty adjustment based on the stage reached. The higher the stage, the faster the action and the more Byrons that appear. Butts will also appear more frequently in later stages, as well as deadly bombs that end the game instantly. As with your standard whack-a-mole style video games, the player is expected to reach a target score for that stage, which raises depending on the difficulty level. Everything's running well so far, even if the code is an absolute mess. One sticking point is that swinging the mallet noticeably slows the game down, and spamming it will reduce the action to a crawl. I'm not sure if this can be fixed, but I certainly hope there's a solution.

More progress. I've got the mallet up on the screen... it's fully controllable with the joystick, and can be swung by pressing the fire button. (Probably either fire button, judging from the way the Coleco controller is read and how I've set it up. I don't know how to parse bits out of a byte, although I'm sure there's a way to do it.) Next on the menu? Getting the Byrons to pop up! whackem_game.rom

We've reached a slight impasse, it seems. CONT1 can't be used to read diagonals, at least not by saying things like IF CONT1.LEFT AND CONT1.UP... for up and left. I can read the individual directions by addressing CONT1 directly, but this presents its own problems... pressing fire in conjunction with one of the directions adds 64 to the total, and could complicate matters slightly. I'll have to brainstorm and see what I can do to work around this.

It's said that the ColecoVision was made with "off the shelf" parts. Evidently the parts of the MSX and SG-1000 were taken from the same shelf, because the machines are so similar that they're dangerously close to compatible. The Dina 2-in-1 offers cross compatibility with the SG-1000 and the ColecoVision, and the MSX library is chock full of games originally released for the ColecoVision. The ColecoVision can even play music originally written for the Sega Master System, the next gen upgrade of the SG-1000! So we know what these machines have in common. What's the difference between them? I know the MSX has a lot more RAM than the ColecoVision, but how do the SG-1000 and ColecoVision compare? Wikipedia offers scant information about the SG-1000, but for all I know the two systems could be one and the same, aside from a different BIOS and address calls. And what of the ZX Spectrum? How close is that to all of these "off the shelf" game consoles?

Golly. This is way better than the Parker Bros. version, and I was okay with the Parker Bros. version back in the 1980s. Moving up and down is a little tricky, but past that, it's hard to complain about what's here. It feels less like an abstraction of the arcade game and more like a legitimate port.

Now we're making tracks! I've got a playfield for the game, along with some limited animation. You can probably guess where I'm going with this... it's a Whack A Mole/Mole Attack style game, with Byron popping out from one of nine holes. A cartoon mallet is controlled by the player, and the fire button swings it. Bopping Byron on the head scores you points, while bopping him on the butt subtracts them. Reach the target score in the allotted span of time and you advance to the next stage; fail to do this and you lose. (Later stages have Byron holding up a bomb... this will instantly end the game if you strike it.) In addition to the standard whack a mole gameplay, I'm planning quick draw bonus rounds which challenge you to hit one safe target from several that pop up at once, or hit Byrons in the order that they appear (kind of like Simon). It's still not playable, but I've got most (all?) of the graphics ready. I just need to figure out the game logic; I'm probably going to use a DIM statement to split the screen into nine sections, and each section operates independently from the others. Sound will likely be a problem... I've never been good at this, but it seems there are various tools that will make things easier for me, including one by the ever-busy Tursi. byron_bash.bas byron_bash.rom byron_title.rom byron_title.bas

I've finally advanced to sprites on the ColecoVision, and noticed something peculiar. If you stack one sprite on top of another to add color and detail to it, it will flicker ever so slightly as the two sprites struggle for dominance. I thought it was because I was putting the sprite drawing commands inside an infinite loop, but no, even using the command once still resulted in flicker. Evidently, you can't overlay sprites without the two of them fighting over which one displays, even if you're just using two sprites. It explains why when they drew Mario on Donkey Kong, they only had ALL red pixels, ALL blue pixels, and ALL white pixels in each of his three sprites, with none of the pixels from different colors touching.