Intellivision Hombrew Idea Thread

[GroovyBee]

Well, that's true, but the Atari 2600 isn't good at drawing arbitrary lines either, and Atari still managed do to a simplified version of Missile Command for the 2600 that captured the essence of the game (with a lot less arbitrary lines.)

 

Having had a quick look at the 2600 version it doesn't have very many line angles. So it should be possible to have the line patterns predefined in GRAM. The only problems I see are handling intersecting lines and multiple fragments when the missile splits (assuming you support that). Predefined patterns would be much easier than using Bresenhams and a pool of GRAM characters.

[+DZ-Jay]

A Logan's Run game using Night Stalker mechanics would work very well, I would think.

 

But how would you get the people chanting "renewal" to sound right?

 

With IntelliVoice, of course!

 

-dZ.

[tz101]

Could Kaboom! be done on Inty?

[catsfolly]

Could Kaboom! be done on Inty?

Kaboom could be done on the Intellivision. The bombs couldn't be as colorful as the Atari 2600 version though. And it would be harder to play the game with the Intellivision controllers (the 2600 version worked best with the paddle controllers.)

 

(Hmmm... (WARNING - rambling technical "thinking out loud" interlude follows) Maybe if we used scrolling to move the bombs,and then on each frame, offset the paddle and bomber motion object positions so they didn't scroll, and dynamically counter-scrolled some gram stamps to display a non-scrolling score, and dynamically swapped out the stamps for the border between the top of the screen and the bomb area to counteract the scrolling effect, we might be able to put the bombs and fuses on separate backtab characters and have burning fuses...)

[intvnut]

Well, that's true, but the Atari 2600 isn't good at drawing arbitrary lines either, and Atari still managed do to a simplified version of Missile Command for the 2600 that captured the essence of the game (with a lot less arbitrary lines.)

 

Having had a quick look at the 2600 version it doesn't have very many line angles. So it should be possible to have the line patterns predefined in GRAM. The only problems I see are handling intersecting lines and multiple fragments when the missile splits (assuming you support that). Predefined patterns would be much easier than using Bresenhams and a pool of GRAM characters.

 

I whipped this up on the plane ride back from DC last night (and spent this morning debugging it). It is completely non-optimized. Really, it's just a proof of concept to demonstrate the algorithm, not great code. And I think a bug or two still lurks in there, since I get the occasional spurious pixel.

 

It uses a pool of 48 cards (configurable) in an LRU setup to provide a very simple bitmap sketching buffer. If you try to plot a pixel in a BACKTAB card that is currently blank, it'll "reap" the card that was least recently plotted to, blanking it and moving it to the new position.

 

With that engine underneath, I draw 8 different "incoming missile" lines at random velocities. When one hits the bottom, I reinitialize its position/velocity, so that there's always 8 active incoming missiles. (That too is configurable.)

 

It's not Missile Command, but I think it demonstrates some level of feasibility if someone wants to take this code and do something with it. I have no desire to myself.

lines.zip

[intvnut]

Well, that's true, but the Atari 2600 isn't good at drawing arbitrary lines either, and Atari still managed do to a simplified version of Missile Command for the 2600 that captured the essence of the game (with a lot less arbitrary lines.)

 

Having had a quick look at the 2600 version it doesn't have very many line angles. So it should be possible to have the line patterns predefined in GRAM. The only problems I see are handling intersecting lines and multiple fragments when the missile splits (assuming you support that). Predefined patterns would be much easier than using Bresenhams and a pool of GRAM characters.

 

I whipped this up on the plane ride back from DC last night (and spent this morning debugging it). It is completely non-optimized. Really, it's just a proof of concept to demonstrate the algorithm, not great code. And I think a bug or two still lurks in there, since I get the occasional spurious pixel.

 

It uses a pool of 48 cards (configurable) in an LRU setup to provide a very simple bitmap sketching buffer. If you try to plot a pixel in a BACKTAB card that is currently blank, it'll "reap" the card that was least recently plotted to, blanking it and moving it to the new position.

 

With that engine underneath, I draw 8 different "incoming missile" lines at random velocities. When one hits the bottom, I reinitialize its position/velocity, so that there's always 8 active incoming missiles. (That too is configurable.)

 

It's not Missile Command, but I think it demonstrates some level of feasibility if someone wants to take this code and do something with it. I have no desire to myself.

 

Aha... I found the remaining bug that was causing the spurious pixel. Once a BTAB card gets reaped, it's still possible for a later pixel to try to sketch on that card in its old location, since the actual reaping doesn't get done until the ISR. (I do this delayed update to prevent flicker.)

 

The fix is to mark the BTAB location as reaped in BTAB itself, by setting one of the unused bits in the card #. This won't change how it's displayed by the STIC, but it will prevent it from getting sketched on.

lines.zip

[intvnut]

Could Kaboom! be done on Inty?

Kaboom could be done on the Intellivision. The bombs couldn't be as colorful as the Atari 2600 version though. And it would be harder to play the game with the Intellivision controllers (the 2600 version worked best with the paddle controllers.)

 

(Hmmm... (WARNING - rambling technical "thinking out loud" interlude follows) Maybe if we used scrolling to move the bombs,and then on each frame, offset the paddle and bomber motion object positions so they didn't scroll, and dynamically counter-scrolled some gram stamps to display a non-scrolling score, and dynamically swapped out the stamps for the border between the top of the screen and the bomb area to counteract the scrolling effect, we might be able to put the bombs and fuses on separate backtab characters and have burning fuses...)

 

That's pretty much how River Raid and Bump'n'Jump work their magic....

[intvnut]

Aha... I found the remaining bug that was causing the spurious pixel. Once a BTAB card gets reaped, it's still possible for a later pixel to try to sketch on that card in its old location, since the actual reaping doesn't get done until the ISR. (I do this delayed update to prevent flicker.)

 

The fix is to mark the BTAB location as reaped in BTAB itself, by setting one of the unused bits in the card #. This won't change how it's displayed by the STIC, but it will prevent it from getting sketched on.

 

The moment you say you found the last bug is about 3 seconds before you find the next one. There's a corresponding bug that occurs when two (or more) pixels get plotted in the same frame-time in a blank card. The code I posted earlier will end up reaping a GRAM card for each and allocate all of them the same BTAB card. The net result is that it'll reap too many GRAM cards but only (effectively) keep the last one.

 

The fix there is to go ahead and put the allocated card in BTAB but leave it set to "black" so it blends into the background until the ISR has a chance to blank and update the corresponding GRAM slot and then rewrite the BTAB location as non-black. It was a one-liner fix.

 

I hadn't actually observed the resulting artifact this bug introduced. Rather, it just occurred to me that it could happen while I was in the shower. It took me staring at the screen for a few minutes to actually see the bug happen. With this much motion onscreen it's easily missed. Plus, with these random, uncorrelated lines, the situation that triggers the bug wouldn't happen very often. If you actually wrote a Missile Command clone, though, where there's a bit more correlation between the various lines (both for the incoming missiles and your own anti-ballistics), the bug would be more obvious.

 

Oh, and one last thing: Credit where credit is due! I can't say I came up with this sort of dynamic LRU-based update approach myself. Arnauld Chevallier has written a number of different pieces of code that did dynamic GRAM allocation for bitmap-like things (see IntyOS for one example). It's those demos that inspired me to try this.

lines.zip

Edited November 1, 2010 by intvnut

[~llama]

I have a couple of questions on this topic: What kinds of games tend to take the best advantage of the Intellivison's hardware (that is, what kinds of games are best suited to the way the graphics hardware works and to the controllers)? It seems like the specifics of any system's hardware design are such that some types of games work better than others... what are the Intellivision's strong suits? Which games really show off the system's capabilities more than others?

 

It seems like one thing homebrew games are really good at is pushing systems beyond where they were taken during their original lifespans, and as somebody who wants to write homebrew games for the Intellivision (but is a total INTV n00b) I want to know where the limits are of what can really be done.

Edited November 29, 2010 by ~llama

[intvnut]

I have a couple of questions on this topic: What kinds of games tend to take the best advantage of the Intellivison's hardware (that is, what kinds of games are best suited to the way the graphics hardware works and to the controllers)? It seems like the specifics of any system's hardware design are such that some types of games work better than others... what are the Intellivision's strong suits? Which games really show off the system's capabilities more than others?

 

It seems like one thing homebrew games are really good at is pushing systems beyond where they were taken during their original lifespans, and as somebody who wants to write homebrew games for the Intellivision (but is a total INTV n00b) I want to know where the limits are of what can really be done.

 

Well, first off, I think some of the conventional wisdom may now be obsolete. That said, let's examine it.

 

Intellivision offers a character-based persistent display, generous amount of RAM, a powerful CPU, a fair bit of ROM, and clunky-but-feature-filled controllers. The 2600 offers limited ROM space (unless you bankswitch), limited RAM, simple-but-fast controllers and a highly flexible, but high maintenance display.

 

If you look at the original early-80s canon for both systems, you'll find many 2600 games that are focused around a "graphics kernel", with fairly simple, twitchy gameplay based around a "main screen" or small number of closely related screens. Most of the game logic is therefore tied to the screen refresh, leading to very fast-paced, fast-response games with simple inputs and low in-game variety. On the Intellivision, you'll find many slower paced games, many with much richer input schemes that are significantly lower bandwidth. The persistent display means that the game logic can progress slowly, because the STIC does all the refreshing for you. As a result, if you look at the early 80s releases, you won't really find a good Utopia on 2600, nor will you find a good Kaboom! on Intellivision.

 

What parts of that stereotype become obsolete? Well, for one, both systems have figured out how to get tons of ROM and RAM for a new homebrew. That leveled that bit out. For another, a good number of Intellivision homebrews eschew the built-in EXEC operating system. This makes the games much more responsive. That makes the "fast vs. ponderous" distinction go away. So now you have plenty of twitchy Intellivision games, and plenty of 2600 games with rich environments to explore.

 

Now it mainly comes down to how well your graphics fit onto the system's graphics chip and how well the controls map onto the system's default controllers. For example, I'm not sure you could do Oystron on the Intellivision, but it obviously works great on the 2600. Then again, I didn't think Missile Command or Qix would be doable, but my recent "lines" demo suggests that I may've been wrong. Even so, either would be a stretch for the system.

 

The Intellivision offers you a fair bit of CPU power, a character-based display with a user-defined set of tiles for the characters, 8 MOBs, 3 voice sound, and controllers with a fairly rich set of possible inputs. That offers many possibilities.

 

The biggest thing to be mindful of, though, is the character based display and all the limitations it brings. You don't get a bitmap, and you don't get to define your own grid. You get 64 8x8 pictures, and you have to place them on a 20x12 grid. That'll drive a big component of your display design for how your game works. MOBs are almost an afterthought for your primary game layout, since they'll mainly be the characters that inhabit the world you build on that character grid.

 

Anyway, that's how I see it. Others most likely take a different view. Please speak up!

Edited November 29, 2010 by intvnut

[GroovyBee]

It seems like one thing homebrew games are really good at is pushing systems beyond where they were taken during their original lifespans, and as somebody who wants to write homebrew games for the Intellivision (but is a total INTV n00b) I want to know where the limits are of what can really be done.

 

Personally, I'd say don't worry about the limits of the system at the moment. Just get your game idea into something that will work on the existing hardware and make a start on it. If the game evolves as you get up to speed on the platform that's all part of the fun. There are no hard and fast rules for creating games on retro platforms. Just strive to make a fun game to play and have a great time developing it along the way.

[+DZ-Jay]

I have a couple of questions on this topic: What kinds of games tend to take the best advantage of the Intellivison's hardware (that is, what kinds of games are best suited to the way the graphics hardware works and to the controllers)? It seems like the specifics of any system's hardware design are such that some types of games work better than others... what are the Intellivision's strong suits? Which games really show off the system's capabilities more than others?

 

It seems like one thing homebrew games are really good at is pushing systems beyond where they were taken during their original lifespans, and as somebody who wants to write homebrew games for the Intellivision (but is a total INTV n00b) I want to know where the limits are of what can really be done.

 

Well, first off, I think some of the conventional wisdom may now be obsolete. That said, let's examine it.

 

Intellivision offers a character-based persistent display, generous amount of RAM, a powerful CPU, a fair bit of ROM, and clunky-but-feature-filled controllers. The 2600 offers limited ROM space (unless you bankswitch), limited RAM, simple-but-fast controllers and a highly flexible, but high maintenance display.

 

If you look at the original early-80s canon for both systems, you'll find many 2600 games that are focused around a "graphics kernel", with fairly simple, twitchy gameplay based around a "main screen" or small number of closely related screens. Most of the game logic is therefore tied to the screen refresh, leading to very fast-paced, fast-response games with simple inputs and low in-game variety. On the Intellivision, you'll find many slower paced games, many with much richer input schemes that are significantly lower bandwidth. The persistent display means that the game logic can progress slowly, because the STIC does all the refreshing for you. As a result, if you look at the early 80s releases, you won't really find a good Utopia on 2600, nor will you find a good Kaboom! on Intellivision.

 

What parts of that stereotype become obsolete? Well, for one, both systems have figured out how to get tons of ROM and RAM for a new homebrew. That leveled that bit out. For another, a good number of Intellivision homebrews eschew the built-in EXEC operating system. This makes the games much more responsive. That makes the "fast vs. ponderous" distinction go away. So now you have plenty of twitchy Intellivision games, and plenty of 2600 games with rich environments to explore.

 

Now it mainly comes down to how well your graphics fit onto the system's graphics chip and how well the controls map onto the system's default controllers. For example, I'm not sure you could do Oystron on the Intellivision, but it obviously works great on the 2600. Then again, I didn't think Missile Command or Qix would be doable, but my recent "lines" demo suggests that I may've been wrong. Even so, either would be a stretch for the system.

 

The Intellivision offers you a fair bit of CPU power, a character-based display with a user-defined set of tiles for the characters, 8 MOBs, 3 voice sound, and controllers with a fairly rich set of possible inputs. That offers many possibilities.

 

The biggest thing to be mindful of, though, is the character based display and all the limitations it brings. You don't get a bitmap, and you don't get to define your own grid. You get 64 8x8 pictures, and you have to place them on a 20x12 grid. That'll drive a big component of your display design for how your game works. MOBs are almost an afterthought for your primary game layout, since they'll mainly be the characters that inhabit the world you build on that character grid.

 

Anyway, that's how I see it. Others most likely take a different view. Please speak up!

 

I agree with intvnut. I would like to add that, although your demo showed that something like the main feature of Missile Command or Qix may indeed be technically possible to do on an Intellivision, they may still not be practical as a complete game. All that effort would go into reproducing a very simplistic graphics style from back in the day when nothing more than lines and blocks were practical. This may seem like a technological feat on the Intellivision to us (and indeed it is!), but hardly the stuff of legend, as far as game-play and graphics go. That said, it should still be an interesting tech demo.

 

I believe that all that effort should be better spent in stretching the capabilities of the Intellivision to provide an enhanced experience. Take 4-Tris for instance: it works so well not because it is able to reproduce colored blocks on the screen (the Intellivision does that almost for free), but because it offers a rich musical score and addictive, real-time gameplay, among other features.

 

Likewise for Space Patrol: it's not the fact that you made the screen scroll with a parallax effect, it's that the levels are ingeniously designed and the game-play, sprites, and sounds are fantastic. Parallax scrolling is almost incidental to the game (though, very much impressive, I must say!).

 

All great games germinate from a great idea. My advice to ~llama would be, start with that: come up with an interesting concept (or base it on an existing one) and then figure out how to bring it to life around and in spite of the limitations of the platform. If a particular feature is not practical to do (or impossible), reduce it to its basic concept, its essence. Try to distill what exactly it brings to the game, and offer that in an alternative way. Sometimes it's a matter of increasing the difficulty to compensate for a lack of concurrent antagonists, or decreasing it for a scaled down game area. If the concept is solid, game-play will likely not suffer just because, say, your main sprite has only one color instead of three, or you have only 5 antagonists at a time instead of 10.

 

So, to answer ~llama's question directly: What kind of games work best on the Intellivision? Well, any kind of game, really. Perhaps the more apt question is what kind of features shine best on the Intellivision? Here are just a few:

- Static backgrounds composed of tiles

- Pre-rendered graphics

- Multiple players/antagonists at once, up to 8

- Music and sound effects

- Multi-axis Scrolling

- "Free-form" player movement along multiple axes.

- More complex input than just move/fire.

- Rich antagonist AI

 

What kind of features do not work well, or are not possible at all on the Intellivision?

- Bitmap or vector graphics

- Raster effects

- HBlank multiplexing

- More than 8 individual sprites, displaying, animating, moving, and interacting at the same time.

- Real-time lighting or perspective effects

- 3-D real-time imagery

- Richly colored sprites and background tiles

[+DZ-Jay]

It seems like one thing homebrew games are really good at is pushing systems beyond where they were taken during their original lifespans, and as somebody who wants to write homebrew games for the Intellivision (but is a total INTV n00b) I want to know where the limits are of what can really be done.

 

Personally, I'd say don't worry about the limits of the system at the moment. Just get your game idea into something that will work on the existing hardware and make a start on it. If the game evolves as you get up to speed on the platform that's all part of the fun. There are no hard and fast rules for creating games on retro platforms. Just strive to make a fun game to play and have a great time developing it along the way.

 

Amen! I keep hitting limitation after limitation on my current game project as I progress (mostly on GRAM/MOB availability), but coming up with work-arounds or alternatives is part of the challenge. Through it all, the game has evolved into something slightly different than I had in mind when I started, but still very much effective.

 

-dZ.

[intvnut]

I agree with intvnut. I would like to add that, although your demo showed that something like the main feature of Missile Command or Qix may indeed be technically possible to do on an Intellivision, they may still not be practical as a complete game. All that effort would go into reproducing a very simplistic graphics style from back in the day when nothing more than lines and blocks were practical. This may seem like a technological feat on the Intellivision to us (and indeed it is!), but hardly the stuff of legend, as far as game-play and graphics go. That said, it should still be an interesting tech demo.

That would be why I have no plans to develop it into a Missile Command clone. That said, if it triggers anyone's imagination for a new game concept, then it's time well spent. As you say later, Inty game development often focuses on working around the limitations of the system. If you have more tools to push those limits back, all the better.

 

 

Likewise for Space Patrol: it's not the fact that you made the screen scroll with a parallax effect, it's that the levels are ingeniously designed and the game-play, sprites, and sounds are fantastic. Parallax scrolling is almost incidental to the game (though, very much impressive, I must say!).

David did an excellent job with the levels, and that really made the game. The other technical aspects were definitely important, but as you said, I could have dropped a gewgaw or doodad here or there (ie. dropped parallax and used hardware scrolling) without losing the gameplay. After all, you don't shoot at the mountains.

 

I think that highlights a second important idea: Collaborate! Or at the very least, find a sounding board to bounce ideas off of, even if it's just in private. I thought I could do Lunar MP (as Space Patrol was once called) by myself. In the end, I enlisted David to design the levels and Arnauld to score the music. The result was 100x what I could have done by myself.

 

Sometimes it's a matter of increasing the difficulty to compensate for a lack of concurrent antagonists, or decreasing it for a scaled down game area. If the concept is solid, game-play will likely not suffer just because, say, your main sprite has only one color instead of three, or you have only 5 antagonists at a time instead of 10.

David and I struggled with that part a fair bit. In the end we came up with a few strategies. I pushed at it from the engine side, using multiplexing and trickery to allow for more bad guys and bullets on screen. David worked on staggering enemy onslaughts out just enough that ambushes still felt like ambushes, but didn't require more than the 5 saucers flying onscreen at a time. We also spent some time tweaking the aggressiveness of the AI to perfect the balance.

 

In the end, that fine tuning came down to play testing. If I wasn't having fun playing my own game, something was wrong. :-) In the end, Space Patrol has ended up being one of my favorite Intellivision games, and I'd like to think it's not just out of programmer bias. (Utopia, Astrosmash, Space Spartans and Beamrider also make my short list.)

 

So, to answer ~llama's question directly: What kind of games work best on the Intellivision? Well, any kind of game, really. Perhaps the more apt question is what kind of features shine best on the Intellivision?

I'd also highlight the Intellivision's keypad, that allows for certain kinds of interaction. Look at Space Spartans and Baseball for two effective uses of the keypad. And the Intellivision offers the 16 direction disc, which can work well for freeform navigation on the display. (Emulators have a tough time truly supporting the full 16-direction input, though, unless you use an analog joystick.)

 

What kind of features do not work well, or are not possible at all on the Intellivision?

- Bitmap or vector graphics

*cough*Vectron*cough* Yeah, I definitely have to agree on this point.

 

- More than 8 individual sprites, displaying, animating, moving, and interacting at the same time.

There are tricks to get around some of that limitation, ranging from multiplexing (which brings flicker) to (ab)using GRAM to give the illusion of more moving objects at the expense of program complexity. Worm Whomper uses GRAM rather effectively to give a huge onslaught of inchworms. Space Patrol uses both GRAM-based motion and multiplexing to get its screen full of moving objects and enemies.

 

But really, start with an idea and see where it goes. The most important ingredient is FUN. :-)

[~llama]

I'm thinking about porting Desert Bus. That should be fun, right?

[intvnut]

I'm thinking about porting Desert Bus. That should be fun, right?

 

Hmmm.... I'd hate to debug any overflows in the scoring logic. Maybe if you get to 99 points, you can implement the same 'special visual treat' as Vectron.

[+DZ-Jay]

I'm thinking about porting Desert Bus. That should be fun, right?

 

Hmmm.... I'd hate to debug any overflows in the scoring logic. Maybe if you get to 99 points, you can implement the same 'special visual treat' as Vectron.

 

I would make one change though: the message should say "Congratulations, you drive very good." That'll surely make it worth their while!

 

-dZ.

[GroovyBee]

I'm thinking about porting Desert Bus. That should be fun, right?

 

For your first project I think that a "watching paint dry" simulator would be the way to go. Obviously, it'd have to be real time.

[+DZ-Jay]

I'm thinking about porting Desert Bus. That should be fun, right?

 

For your first project I think that a "watching paint dry" simulator would be the way to go. Obviously, it'd have to be real time.

 

Only if it's the same paint color per 8x8 tile; otherwise, you'll have to make the simulation on the Stella.

[daldude]

Ms Pac Man.

 

A new version of Pac Man that looks more like the original arcade version, someone was working on a one and only got as far as just being able to move Pac Man around and making the Ghosts turn blue but they did not move and could not be eaten and had no eyes and there was no score or sound but it looked real awesome for it not being complete yet.

 

Auto Racing with the ability to make your own tracks like you could with Moto Cross.

 

 

Mario Bros (Talk about a member sore thumbs club game)

 

and make these games available for sale as a ROM for a price for those who have a CC3 and can't afford to pay 70 one game. Maybe after they recover the costs to produce the cartridges they could then sell the games as ROMs.

 

 

 

 

 

 

[+DZ-Jay]

Ms Pac Man.

 

A new version of Pac Man that looks more like the original arcade version, someone was working on a one and only got as far as just being able to move Pac Man around and making the Ghosts turn blue but they did not move and could not be eaten and had no eyes and there was no score or sound but it looked real awesome for it not being complete yet.

 

 

I think you're talking about my port of Pac-Man from back in 2010. Ah, memories.

 

In case you were not aware, that version of Pac-Man turned eventually into Christmas Carol. By the way, I've since stopped working on it.

 

-dZ.

[vprette]

 

I think you're talking about my port of Pac-Man from back in 2010. Ah, memories.

 

In case you were not aware, that version of Pac-Man turned eventually into Christmas Carol. By the way, I've since stopped working on it.

 

-dZ.

 

do pengo! :-)

[+DZ-Jay]

 

do pengo! :-)

 

Thanks for the interest, but I'll leave the ports to others. I have ideas for some original games.

 

-dZ.

[Fushek]

 

Thanks for the interest, but I'll leave the ports to others. I have ideas for some original games.

 

-dZ.

 

What defined the Intellivision were the unique, original games that came out for it. Don't get me wrong, I'm thankful for any game coming out (Smurf, Space Raid) but I truly appreciate something original such as Carol, Paddle Parry and the pending Kroz.

[JoeM_Intellivision]

Agreed again.