Intellivision Hombrew Idea Thread

[Rev]

Just a place to throw out ideas for anyone to work on or if you have a neat idea for a homebrew.Dont give out any ideas if you do not want someone to know about it though.

 

 

 

 

How about a game kinda based off Night Stalker,not i direct rip off but along the same lines.inty needs more adventure type games..maybe have up to 10 different mazes and many varying enemies ? and some different kind of weapons. im tired of the bunker always being in the middle!

[Cebus Capucinis]

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

[jaybird3rd]

If somebody was to do a "sequel" to Night Stalker, it should incorporate some of the features that had to be cut from the original (the spider web, the bazooka to blast through walls, etc), and a greater variety of robots. I'd also like to see more than one room.

 

One idea I've had is a game world that is an actual maze (preferably a dynamically-generated maze) made up of interconnected rooms, leading to something "special" in the center. You'd have to defeat a certain number of robots in each room before the doors to the adjacent rooms open up, so the gameplay would be a combination of fighting robots and finding your way through the maze. I've been looking at a disassembly of Aquarius Night Stalker with a similar idea in mind for that system. It could work on the Intellivision, too, although it might require extra RAM.

 

Having said all that, I'd much rather see original games than ports, remakes, or sequels.

[Cebus Capucinis]

Sounds like Logan's Run to me...

 

I'm just really, really hoping here.

[tz101]

Berzerk for the Intellivoice module. Can it be done?

 

Battlezone/Robot Tank type of first person tank simulator.

 

Both would be excellent additions to the Inty.

[+DZ-Jay]

Berzerk for the Intellivoice module. Can it be done?

 

Battlezone/Robot Tank type of first person tank simulator.

 

Both would be excellent additions to the Inty.

 

Battlezone seems like a stretch, since it uses polygon wireframe graphics, which won't translate easily into "tiles". I guess it is possible, just like Joe made that demo of Doom on the Intv, though I don't think it'll be very playable or visually acceptable.

 

-dZ.

[GroovyBee]

Battlezone seems like a stretch, since it uses polygon wireframe graphics, which won't translate easily into "tiles".

 

Battlezone on the 2600 :-

 

http://www.youtube.com/watch?v=BAX2SAIR67A

 

Looks like scaled sprites to me, so its definitely possible on the Inty. However, I think the 2600's much larger palette and its colour changing ability adds a lot to the game which the Inty couldn't mimic.

[+DZ-Jay]

Battlezone seems like a stretch, since it uses polygon wireframe graphics, which won't translate easily into "tiles".

 

Battlezone on the 2600 :-

 

http://www.youtube.com/watch?v=BAX2SAIR67A

 

Looks like scaled sprites to me, so its definitely possible on the Inty. However, I think the 2600's much larger palette and its colour changing ability adds a lot to the game which the Inty couldn't mimic.

 

In the 2600, you draw background and sprites in raster lines, having full control (well, mostly) of the graphics as they are being generated. In the Inty, you have no such ability; everything must be a card referenced from GRAM, which only contains 64 slots. Re-drawing the images in GRAM on every frame, to account for perspective and orientation changes, is very expensive.

 

And even if you wanted to treat GRAM as a screen buffer, drawing directly to it, it is still only 64 tiles big, which covers only a fraction of the BACKTAB.

 

The alternative, as you suggested, is to use pre-rendered sprites; but then, is it really Battlezone? I'm guessing that most of the appeal of the original game is the "simulation" feel it offers. Using pre-rendered 8x8 sprites may kill this effect. It may still be fun to play, but how would it distinguish it from other sprite-based shooting games? It seems to me it would be closer to, say, Duck Hunt than Battlezone.

 

-dZ.

[+DZ-Jay]

In the 2600, you draw background and sprites in raster lines, having full control (well, mostly) of the graphics as they are being generated. In the Inty, you have no such ability; everything must be a card referenced from GRAM, which only contains 64 slots. Re-drawing the images in GRAM on every frame, to account for perspective and orientation changes, is very expensive.

 

And even if you wanted to treat GRAM as a screen buffer, drawing directly to it, it is still only 64 tiles big, which covers only a fraction of the BACKTAB.

 

The alternative, as you suggested, is to use pre-rendered sprites; but then, is it really Battlezone? I'm guessing that most of the appeal of the original game is the "simulation" feel it offers. Using pre-rendered 8x8 sprites may kill this effect. It may still be fun to play, but how would it distinguish it from other sprite-based shooting games? It seems to me it would be closer to, say, Duck Hunt than Battlezone.

 

-dZ.

 

I just viewed the 2600 video you posted. I take most of my comments back: it is done to great effect, so it is very possible in the Inty.

 

-dZ.

Edited September 18, 2010 by DZ-Jay

[tz101]

What about Berzerk? The graphics are simple. Hardest part would be the voice samples on the Intellivoice module.

[GroovyBee]

What about Berzerk? The graphics are simple. Hardest part would be the voice samples on the Intellivoice module.

 

A Berzerk style game could be done using Inty sprites but you'd be limited to something like K-Razy Shootout on the A8 range :-

 

http://www.youtube.com/watch?v=f41sgMt57zE&NR=1

 

With more advanced programming techniques you could store pre-shifted robot sprites in GRAM which would allow you to have more robots on screen at the same time. That would get you much closer to a version of Berzerk.

 

As far as speech is concerned I haven't investigated that beyond looking at the code samples provided in the sdk1600 development kit. I don't see why it wouldn't be possible though.

[Austin]

How about a racing game (maybe top-down, super sprint-style) that takes advantage of the 16-direction disc for smoother turning?

[GroovyBee]

How about a racing game (maybe top-down, super sprint-style) that takes advantage of the 16-direction disc for smoother turning?

 

Also possible. But with only 64 tiles for the background (minus car sprites) it would take some careful track design.

[+DZ-Jay]

 

As far as speech is concerned I haven't investigated that beyond looking at the code samples provided in the sdk1600 development kit. I don't see why it wouldn't be possible though.

 

You're in luck! The Intellivision has a nifty accessory called the IntelliVoice, which offers speech facilities, used in some games to great effect. The SDK supports the IntelliVoice and even provides a group of default allophones.

 

As for the rest of the Berserk game, I think the robots move slow enough that setting them as pre-shifted tiles in the background should work well and be fairly simple.

 

-dZ.

[sack-c0s]

I'm thinking that if you stripped pang down to the bare essential gameplay and didn't get too hung up on having massive amounts of background graphic detail you could do a decent playable version for the intellivision

 

http://www.youtube.com/watch?v=Hmt15j7A32Y

[GroovyBee]

I'm thinking that if you stripped pang down to the bare essential gameplay and didn't get too hung up on having massive amounts of background graphic detail you could do a decent playable version for the intellivision

 

Agreed! There are plenty of shapes in GROM that can be used for the crispy bits on mountains so that would free up GRAM for other uses. If you could design a good background (with 2 or 4 background colour changes per backtab row) you could make good use of the colour stack display mode too.

[Rev]

at this point in time.i think most intv enthusiests would take any game!!!!!

 

i would be happy if PONG was released on it. why was it never on it to begin with?

 

i can see it now.....PONG on intv.....500 copies sold!!!!!!!!

 

[GroovyBee]

at this point in time.i think most intv enthusiests would take any game!!!!!

 

Personally I'd rather release games that are equal to or better quality than the best games released back in the day. Its not like modern homebrew developers are constrained by time, money or a low ROM budget.

[intvnut]

at this point in time.i think most intv enthusiests would take any game!!!!!

 

Personally I'd rather release games that are equal to or better quality than the best games released back in the day. Its not like modern homebrew developers are constrained by time, money or a low ROM budget.

 

I mostly agree... Dunno about the "time" bit though, seeing as I've got a day job that eats much of my time. Then again, we certainly don't have a marketing department breathing down our necks to ship ROMs in time for Christmas, though.

[intvnut]

at this point in time.i think most intv enthusiests would take any game!!!!!

 

i would be happy if PONG was released on it. why was it never on it to begin with?

 

i can see it now.....PONG on intv.....500 copies sold!!!!!!!!

 

 

I did write Pong, actually, and it's hidden in some of the older 4-Tris cartridges.

[intvnut]

Berzerk for the Intellivoice module. Can it be done?

 

Battlezone/Robot Tank type of first person tank simulator.

 

Both would be excellent additions to the Inty.

 

Battlezone seems like a stretch, since it uses polygon wireframe graphics, which won't translate easily into "tiles". I guess it is possible, just like Joe made that demo of Doom on the Intv, though I don't think it'll be very playable or visually acceptable.

 

-dZ.

 

Well... that "Doom" demo was a fake for April Fools Day. That said, Arnauld and I did have some success at making a Wolfenstein 3-D type raycasting engine at one point.

 

Anyway, you could prerender enemies at various distances and orientations. After all, that's what the original Doom did--it stored 8 (or was it 16?) for all the angles a bad guy could face relative to you.

 

What about Berzerk? The graphics are simple. Hardest part would be the voice samples on the Intellivoice module.

 

A Berzerk style game could be done using Inty sprites but you'd be limited to something like K-Razy Shootout on the A8 range :-

 

http://www.youtube.com/watch?v=f41sgMt57zE&NR=1

 

With more advanced programming techniques you could store pre-shifted robot sprites in GRAM which would allow you to have more robots on screen at the same time. That would get you much closer to a version of Berzerk.

 

As far as speech is concerned I haven't investigated that beyond looking at the code samples provided in the sdk1600 development kit. I don't see why it wouldn't be possible though.

 

If you take a look at the "Geese" demo in there, it makes amusing use of GRAM to allow dozens of geese to amble about the screen. It's a pretty silly demo, of course. The game Worm Whomper uses a metric ton of worm graphics in GRAM to draw all the little inchworms that stream toward you. So, yeah, I'd say pre-shifted robot sprites in GRAM may be the way to go.

 

As far as speech goes... there should be no problem with that.

[GroovyBee]

Well... that "Doom" demo was a fake for April Fools Day. That said, Arnauld and I did have some success at making a Wolfenstein 3-D type raycasting engine at one point.

 

Interesting! Did it have free movement or fixed rotation steps of 90 degrees with the player always in the middle of each cell?

[intvnut]

Well... that "Doom" demo was a fake for April Fools Day. That said, Arnauld and I did have some success at making a Wolfenstein 3-D type raycasting engine at one point.

 

Interesting! Did it have free movement or fixed rotation steps of 90 degrees with the player always in the middle of each cell?

 

It's a proper Wolf 3-D style engine with raycasting, using colored squares mode to render solid-color wall segments. (Wolf 3-D stretched textures onto wall columns, whereas this is doing good to just get a solid color up there.)

 

It's not the fastest code in the world, but not for lack of trying. Arnauld and I put a lot of effort into optimizing the critical code paths. It takes around 13-14 display frames to render a new scene, so it only ends up pulling about 4 FPS. I've put a copy (with source) here:

 

http://spatula-city.org/~im14u2c/intv/dl/IntvWolf.zip

 

There's an experimental post-render mode in there that, when toggled on, tries to fine-tune the column heights with GRAM cards. The version in here is flickery. It's possible to remove the flicker, but we never got around to it.

[GroovyBee]

It's not the fastest code in the world, but not for lack of trying. Arnauld and I put a lot of effort into optimizing the critical code paths. It takes around 13-14 display frames to render a new scene, so it only ends up pulling about 4 FPS. I've put a copy (with source) here:

 

Thanks for the Wolf code. I can see some division in there for the raycasting. When I did a raycast engine many years ago I don't remember it doing much division. It had a load of tables, shifts and multiplies. I'd like to do a 7800 raycast engine at some point, the Inty might get a port of that .

[intvnut]

It's not the fastest code in the world, but not for lack of trying. Arnauld and I put a lot of effort into optimizing the critical code paths. It takes around 13-14 display frames to render a new scene, so it only ends up pulling about 4 FPS. I've put a copy (with source) here:

 

Thanks for the Wolf code. I can see some division in there for the raycasting. When I did a raycast engine many years ago I don't remember it doing much division. It had a load of tables, shifts and multiplies. I'd like to do a 7800 raycast engine at some point, the Inty might get a port of that .

 

The division is for normalization. You can think of the Wolf 3-D raycasting process as being similar to finding the intersection of an arbitrary line with the grid on some graph paper. We only need to test the ray at the grid lines to see if there's a hit, and where on the wall there's a hit.

 

The normalization process makes sure one of the components of the vector is 1.0 and the other can be whatever it likes. As we step from grid-line to grid-line, we adjust the other coordinate to see where on the gridline we hit. Make sense?

 

Now, it should be possible to eliminate the divide altogether with a lookup table if you constrain the range of angles you could face. You can store the prenormalized vectors for each of the columns being shot. If you allow the player to face 64 directions, that's 16 directions per quadrant. If you stored a pair of vectors for each of the 32 columns we're shooting rays on, that'd require 16 * 32 = 512 total entries. If each entry was 4 words, that's 2K words of ROM space--not too bad, actually, if it's the heart of the algorithm. You could bring that down by a factor of 2 or 4 by taking advantage of some of the symmetries, too.

 

All that said, I don't think you get fast enough to be fun. The divide is about 25% of the execution cycles, so making it free would only get you to about 6FPS.