Jump to content

Recommended Posts

I was wondering if Gauntlet would work on Intellivision, not much yet as I don't know the console well enough?

 

-I switched from the original semi-overhead to bird's eye ala' GTA1, this cut the sprite directional card maximum from 5 down to 3 with mirroring. Was mostly thinking of the challenge of getting 2 player sprites & enemy sprites into the GRAM with minimal animation.

 

-There should be enough cards in the GROM for wall graphics. I drew some item cards but they too could be replaced with GROM cards like $ for treasure, already used an E for exit.

 

-Trying for a little color layering in the player sprites just for purely aesthetic reasons but it likely won't fit.

 

-I think the monster hordes will have to be a dynamic grid of foreground & background layer alternating graphics not unlike how Gauntlet was done on the Nes. This is the main crux I'd like to hear thoughts on.

 

-Might as well support the Intellivoice and get speech like "The elf needs food, badly." into the game.

 

Anyway just looking for feedback, also the resemblance is minimal so it could just be a Gauntlet clone which gets us off the hook at arcade accuracy, just a thought. :)

post-29395-0-03289500-1333714195.png

Share this post


Link to post
Share on other sites

I was wondering if Gauntlet would work on Intellivision, not much yet as I don't know the console well enough?

 

-I switched from the original semi-overhead to bird's eye ala' GTA1, this cut the sprite directional card maximum from 5 down to 3 with mirroring. Was mostly thinking of the challenge of getting 2 player sprites & enemy sprites into the GRAM with minimal animation.

 

-There should be enough cards in the GROM for wall graphics. I drew some item cards but they too could be replaced with GROM cards like $ for treasure, already used an E for exit.

 

-Trying for a little color layering in the player sprites just for purely aesthetic reasons but it likely won't fit.

 

-I think the monster hordes will have to be a dynamic grid of foreground & background layer alternating graphics not unlike how Gauntlet was done on the Nes. This is the main crux I'd like to hear thoughts on.

 

-Might as well support the Intellivoice and get speech like "The elf needs food, badly." into the game.

 

Anyway just looking for feedback, also the resemblance is minimal so it could just be a Gauntlet clone which gets us off the hook at arcade accuracy, just a thought. :)

 

Hello,

 

I'm not familiar with the game Gauntlet (I recognize the name, but don't recall which one it is), so I don't have much to say about the design. However, I'm curious to know why you are dependent so much on GROM. You have 64 GRAM cards, and your screenshot seems to use no more than 10. If you plan on using double vertical-resolution sprites, and you use all 8 MOBs, that'll only increase your GRAM use to about 26.

 

Considering the monster hordes, you could implement that by cycling GRAM on background cards. You could reduce the GRAM usage there by making all monsters of the same class use the same GRAM card. This would have the effect of making monsters of the same class share the animation frame (e.g., they will all walk in lockstep). Then you only need at most two GRAM cards per monster class that will appear on the screen concurrently (two, because monsters could straddle two cards at some points).

 

This would also free the MOBs for the player sprite and "main" monsters (i.e. monsters that are actually attacking the player).

 

You mentioned the "challenge of getting 2 player sprites & enemy sprites into the GRAM." Do you mean it's a two player game? Also, keep in mind that for animation, you do not need to load the entire frame sequence into GRAM at once, you can just cycle a single card (or two, for double vertical-resolution) with new card data on every frame. That's how I animate all my sprites in Christmas Carol.

 

-dZ.

Edited by DZ-Jay

Share this post


Link to post
Share on other sites

Hello,

 

I'm not familiar with the game Gauntlet (I recognize the name, but don't recall which one it is), so I don't have much to say about the design. However, I'm curious to know why you are dependent so much on GROM. You have 64 GRAM cards, and your screenshot seems to use no more than 10. If you plan on using double vertical-resolution sprites, and you use all 8 MOBs, that'll only increase your GRAM use to about 26.

 

Considering the monster hordes, you could implement that by cycling GRAM on background cards. You could reduce the GRAM usage there by making all monsters of the same class use the same GRAM card. This would have the effect of making monsters of the same class share the animation frame (e.g., they will all walk in lockstep). Then you only need at most two GRAM cards per monster class that will appear on the screen concurrently (two, because monsters could straddle two cards at some points).

 

This would also free the MOBs for the player sprite and "main" monsters (i.e. monsters that are actually attacking the player).

 

You mentioned the "challenge of getting 2 player sprites & enemy sprites into the GRAM." Do you mean it's a two player game? Also, keep in mind that for animation, you do not need to load the entire frame sequence into GRAM at once, you can just cycle a single card (or two, for double vertical-resolution) with new card data on every frame. That's how I animate all my sprites in Christmas Carol.

 

-dZ.

 

Well you should try Gauntlet out, MAME would be your best bet to try out this arcade classic, plays best with 2 or more players. Gauntlet 2 is harder but it has more variety in terrain behaviors.

 

Is the GRAM a single group bitmap like a Nes CHAR or are we talking about 64 individual cards with independent control? Perhaps I have the wrong impression on how the GRAM works which is likely since I just started my research into the INTV lol.

 

I checked out Christmas Carol on YouTube and I thought it looked cool, reminds me of Mister Do crossed with Bomberman. :)

Share this post


Link to post
Share on other sites

Hello,

 

I'm not familiar with the game Gauntlet (I recognize the name, but don't recall which one it is), so I don't have much to say about the design. However, I'm curious to know why you are dependent so much on GROM. You have 64 GRAM cards, and your screenshot seems to use no more than 10. If you plan on using double vertical-resolution sprites, and you use all 8 MOBs, that'll only increase your GRAM use to about 26.

 

Considering the monster hordes, you could implement that by cycling GRAM on background cards. You could reduce the GRAM usage there by making all monsters of the same class use the same GRAM card. This would have the effect of making monsters of the same class share the animation frame (e.g., they will all walk in lockstep). Then you only need at most two GRAM cards per monster class that will appear on the screen concurrently (two, because monsters could straddle two cards at some points).

 

This would also free the MOBs for the player sprite and "main" monsters (i.e. monsters that are actually attacking the player).

 

You mentioned the "challenge of getting 2 player sprites & enemy sprites into the GRAM." Do you mean it's a two player game? Also, keep in mind that for animation, you do not need to load the entire frame sequence into GRAM at once, you can just cycle a single card (or two, for double vertical-resolution) with new card data on every frame. That's how I animate all my sprites in Christmas Carol.

 

-dZ.

 

Well you should try Gauntlet out, MAME would be your best bet to try out this arcade classic, plays best with 2 or more players. Gauntlet 2 is harder but it has more variety in terrain behaviors.

 

Is the GRAM a single group bitmap like a Nes CHAR or are we talking about 64 individual cards with independent control? Perhaps I have the wrong impression on how the GRAM works which is likely since I just started my research into the INTV lol.

 

Oh, I see. GRAM is not a bitmap in the sense of a screen buffer like the C=64; it's 64 individual cards of 8x8 pixels. The same is true for GROM, except that it only holds 214 cards, which include the basic printable ASCII set and some geometric figures and lines. It was supposed to hold 255 cards, but... well, "flak" got in the way. :)

 

The Intellivision graphics are all "tile-based." The background is drawn by assigning any of the GROM or GRAM (within certain constraints, depending on the colour mode) to the Background Table, called the BACKTAB. The BACKTAB is a grid of 20 columns by 12 rows or cards.

 

There are also 8 MOBs (Movable Object Blocks, used for sprites) which can be assigned any of the GROM and GRAM cards. The MOBs can be single resolution (using a single card) or double resolution (using two consecutive cards).

 

The background supports only single-resolution 8x8 tiles.

 

I checked out Christmas Carol on YouTube and I thought it looked cool, reminds me of Mister Do crossed with Bomberman. :)

 

I'm glad you liked it. It has evolved greatly since that video was taken (that was a demo created in two weeks, the game has had now over a year of refinement and development time). If you're interested you can subscribe to the beta-tester group and get updates on the progress (and help test the game, of course). I expect to release the game this year.

 

-dZ.

Edited by DZ-Jay
  • Like 1

Share this post


Link to post
Share on other sites

By the way, by "double-resolution" I mean that a pixel is drawn in half the vertical resolution of the background. The background uses two raster lines for each pixel.

 

A double-resolution MOB is two cards, drawn on top of each other, making it 8x16 pixels. however, the pixels are drawn on a single-raster line, squashing the MOB and making its effective height 8x8 as compared to the background, but allowing for more detail.

 

A single-resolution MOB uses a single card, which means that it'll be squashed to an 8x4 resolution, as compared to a background tile.

 

Alternatively, you can "zoom" the MOBs vertically and horizontally, doubling the pixel height and width, relative to its resolution.

 

I hope this makes sense.

 

-dZ.

  • Like 1

Share this post


Link to post
Share on other sites

The closest thing to Gauntlet on the Intellivision right now would be Imagic's Sword and Serpents. Here is a gameplay video I found. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=video&cd=1&ved=0CD0QtwIwAA&url=http%3A%2F%2Fgamesdbase.com%2Fgame%2Fmattel-intellivision%2Fswords-and-serpents.aspx&ei=eQJ_T6OxC4XO9QTA0dnkBw&usg=AFQjCNF6-G6kI6pf3tbLXFWWhiW_NnIf-Q

 

 

Bladejunker, Are you planning on making a Gaunlet version for Intv? That would be great, I LOVE Gauntlet. And with the voices? Sweet!

Share this post


Link to post
Share on other sites

Swords and Serpents was the first game I thought of as well, particularly since it has a two player simultaneous mode. It's not the greatest game, but it certainly proves the concept is doable on the system, likely with a greatly reduced enemy count. That's not necessarily a bad thing anyway as I'm not a big believer in recreating games that have been done umpteen times before and we can easily play the pixel perfect original. Creating some inspired-by variant would be nifty though...

Share this post


Link to post
Share on other sites

Oh, I see. GRAM is not a bitmap in the sense of a screen buffer like the C=64; it's 64 individual cards of 8x8 pixels. The same is true for GROM, except that it only holds 214 cards, which include the basic printable ASCII set and some geometric figures and lines. It was supposed to hold 255 cards, but... well, "flak" got in the way. :)

 

The Intellivision graphics are all "tile-based." The background is drawn by assigning any of the GROM or GRAM (within certain constraints, depending on the colour mode) to the Background Table, called the BACKTAB. The BACKTAB is a grid of 20 columns by 12 rows or cards.

 

There are also 8 MOBs (Movable Object Blocks, used for sprites) which can be assigned any of the GROM and GRAM cards. The MOBs can be single resolution (using a single card) or double resolution (using two consecutive cards).

 

The background supports only single-resolution 8x8 tiles.

 

I checked out Christmas Carol on YouTube and I thought it looked cool, reminds me of Mister Do crossed with Bomberman. :)

 

I'm glad you liked it. It has evolved greatly since that video was taken (that was a demo created in two weeks, the game has had now over a year of refinement and development time). If you're interested you can subscribe to the beta-tester group and get updates on the progress (and help test the game, of course). I expect to release the game this year.

 

-dZ.

 

Well that's good news about the cards being individual files since I was wondering how the heck anybody could fit animation let alone color layers or double res sprites into such a tiny space.

 

On the beta-tester group I'll be sure to look into that. :)

Share this post


Link to post
Share on other sites

The closest thing to Gauntlet on the Intellivision right now would be Imagic's Sword and Serpents. Here is a gameplay video I found. http://www.google.co...LXFWWhiW_NnIf-Q

 

 

Bladejunker, Are you planning on making a Gaunlet version for Intv? That would be great, I LOVE Gauntlet. And with the voices? Sweet!

I'd like to but I'm not any kind of programmer unfortunately. I was just looking to consult with some experts on feasibility. Maybe someone would like to collaborate on it with me but don't hold your breath. All I can do is draw sprites. ^_^ Thanks for the S&S vid link, game looks okay so I might try to find a copy. :)

Share this post


Link to post
Share on other sites

Swords and Serpents was the first game I thought of as well, particularly since it has a two player simultaneous mode. It's not the greatest game, but it certainly proves the concept is doable on the system, likely with a greatly reduced enemy count. That's not necessarily a bad thing anyway as I'm not a big believer in recreating games that have been done umpteen times before and we can easily play the pixel perfect original. Creating some inspired-by variant would be nifty though...

Well that was my main concern which is the enemy hordes and if the INTV could render that well which may be possible with background card cycling as DZ-Jay suggested. I don't mind making a game inspired by Gauntlet since licenses are hard to come by and the best INTV game possible is definitely better than a port that falls short of the source material. I agree new games are more interesting than ports, just had Gauntlet on the brain. :)

Share this post


Link to post
Share on other sites

The closest thing to Gauntlet on the Intellivision right now would be Imagic's Sword and Serpents. Here is a gameplay video I found. http://www.google.co...LXFWWhiW_NnIf-Q

 

 

Bladejunker, Are you planning on making a Gaunlet version for Intv? That would be great, I LOVE Gauntlet. And with the voices? Sweet!

I'd like to but I'm not any kind of programmer unfortunately. I was just looking to consult with some experts on feasibility. Maybe someone would like to collaborate on it with me but don't hold your breath. All I can do is draw sprites. ^_^ Thanks for the S&S vid link, game looks okay so I might try to find a copy. :)

 

Hey, although programming games is hard (sorry, but it is), it is not insurmountable. It may be harder if you are not a programmer, but it doesn't mean you cannot learn. There are many people here willing to help, providing guidance, sample code, and such.

 

There is also an SDK available that provides many utility functions and plenty of samples, including a very simple game. I'm not an expert by any means, but I'll offer any help I can provide.

 

I started creating a game framework to aid in programming Intellivision games, but it is not finished yet. The first release was just a simple state machine that encapsulated various game "states" such as "title screen, "game play," and "game over." It basically put together various functions available in the SDK into a simple framework. It also included automatic controller decoding. However it does not include any facilities for sprite handling.

 

It's actually the core of Christmas Carol devoid of game logic, and without the graphics driver. (The sprite driver of Carol is crap, and is constrained by various design decisions I made long ago when I didn't know what I was doing, that are completely stupid. It does not lend well to a general framework, so I didn't include it.)

 

I posted the framework in this forum, along with various articles on how it works and how to use it. If you're interested, look for "P-Machinery."

 

I started working on the second version that will include a generalized sprite driver to handle sprites and animation but I haven't had a chance to complete it. The idea is to abstract the lower level things and allow the creation of games at a "higher level"--e.g., working with Sprite objects rather than with bitmap registers of the video chip. You'll still need to program in Assembly, and it may not fit every type of game, but for most games, it should be easier with P-Machinery than starting with a blank canvas.

 

-dZ.

Edited by DZ-Jay
  • Like 1

Share this post


Link to post
Share on other sites

Hey, although programming games is hard (sorry, but it is), it is not insurmountable. It may be harder if you are not a programmer, but it doesn't mean you cannot learn. There are many people here willing to help, providing guidance, sample code, and such.

 

There is also an SDK available that provides many utility functions and plenty of samples, including a very simple game. I'm not an expert by any means, but I'll offer any help I can provide.

 

I started creating a game framework to aid in programming Intellivision games, but it is not finished yet. The first release was just a simple state machine that encapsulated various game "states" such as "title screen, "game play," and "game over." It basically put together various functions available in the SDK into a simple framework. It also included automatic controller decoding. However it does not include any facilities for sprite handling.

 

It's actually the core of Christmas Carol devoid of game logic, and without the graphics driver. (The sprite driver of Carol is crap, and is constrained by various design decisions I made long ago when I didn't know what I was doing, that are completely stupid. It does not lend well to a general framework, so I didn't include it.)

 

I posted the framework in this forum, along with various articles on how it works and how to use it. If you're interested, look for "P-Machinery."

 

I started working on the second version that will include a generalized sprite driver to handle sprites and animation but I haven't had a chance to complete it. The idea is to abstract the lower level things and allow the creation of games at a "higher level"--e.g., working with Sprite objects rather than with bitmap registers of the video chip. You'll still need to program in Assembly, and it may not fit every type of game, but for most games, it should be easier with P-Machinery than starting with a blank canvas.

 

-dZ.

Thank you very much for the advice and directions on where to find resources. I may try programming in the future but as of now I've settled on the task of creating a simplified guide of how old school gaming systems function for pixel artists to conform to there limitations. I actually started with the Atari 2600 which was very hard to describe to the pixel art forums in terms they could work with, its been slow going but 2 people had a go at mockups based on the 2600 limits I specified.

Generally speaking the pixel art forums stop somewhere around Nes,C64, and ZX Spectrum in terms of hardware generations but plenty of people are eager to draw within specific canvas color limitations if someone explains them, some are quite diligent and flourish within the limits others tend to crumble and break within static restrictions but its always interesting.

Even though a blank canvas is not a game program anybody can create within it regardless and even if I become vaguely fluent in coding I don't think I would ever leave the canvas since there is something primal about it that. While it is necessary to break sprite art into its raw native formats when applied to working programs actually mucking about with pixels as a whole is the only way the art aspect comes through for most people.

 

Again thank you for your offer of help, I think your framework sounds great and will help a lot people seeking to learn about the Intellivision. :)

Share this post


Link to post
Share on other sites

Hey, although programming games is hard (sorry, but it is), it is not insurmountable. It may be harder if you are not a programmer, but it doesn't mean you cannot learn. There are many people here willing to help, providing guidance, sample code, and such.

 

There is also an SDK available that provides many utility functions and plenty of samples, including a very simple game. I'm not an expert by any means, but I'll offer any help I can provide.

 

I started creating a game framework to aid in programming Intellivision games, but it is not finished yet. The first release was just a simple state machine that encapsulated various game "states" such as "title screen, "game play," and "game over." It basically put together various functions available in the SDK into a simple framework. It also included automatic controller decoding. However it does not include any facilities for sprite handling.

 

It's actually the core of Christmas Carol devoid of game logic, and without the graphics driver. (The sprite driver of Carol is crap, and is constrained by various design decisions I made long ago when I didn't know what I was doing, that are completely stupid. It does not lend well to a general framework, so I didn't include it.)

 

I posted the framework in this forum, along with various articles on how it works and how to use it. If you're interested, look for "P-Machinery."

 

I started working on the second version that will include a generalized sprite driver to handle sprites and animation but I haven't had a chance to complete it. The idea is to abstract the lower level things and allow the creation of games at a "higher level"--e.g., working with Sprite objects rather than with bitmap registers of the video chip. You'll still need to program in Assembly, and it may not fit every type of game, but for most games, it should be easier with P-Machinery than starting with a blank canvas.

 

-dZ.

Thank you very much for the advice and directions on where to find resources. I may try programming in the future but as of now I've settled on the task of creating a simplified guide of how old school gaming systems function for pixel artists to conform to there limitations. I actually started with the Atari 2600 which was very hard to describe to the pixel art forums in terms they could work with, its been slow going but 2 people had a go at mockups based on the 2600 limits I specified.

Generally speaking the pixel art forums stop somewhere around Nes,C64, and ZX Spectrum in terms of hardware generations but plenty of people are eager to draw within specific canvas color limitations if someone explains them, some are quite diligent and flourish within the limits others tend to crumble and break within static restrictions but its always interesting.

Even though a blank canvas is not a game program anybody can create within it regardless and even if I become vaguely fluent in coding I don't think I would ever leave the canvas since there is something primal about it that. While it is necessary to break sprite art into its raw native formats when applied to working programs actually mucking about with pixels as a whole is the only way the art aspect comes through for most people.

 

Again thank you for your offer of help, I think your framework sounds great and will help a lot people seeking to learn about the Intellivision. :)

 

Oh sure, no problem. Let me know if there's any more information you want to know regarding colour and graphics restrictions on the platform. There's an Intellivision Wiki that contains some technical information that may help. Check out the "pinned" topic on this forum on programming resources.

 

Cheers!

-dZ.

Share this post


Link to post
Share on other sites

Anyway just looking for feedback, also the resemblance is minimal so it could just be a Gauntlet clone which gets us off the hook at arcade accuracy, just a thought. :)

 

It would be truly sweet to see this game come to INTV, especially with intellivoice support. So, how soon can I buy a cart? :ponder:

Share this post


Link to post
Share on other sites

Anyway just looking for feedback, also the resemblance is minimal so it could just be a Gauntlet clone which gets us off the hook at arcade accuracy, just a thought. :)

 

It would be truly sweet to see this game come to INTV, especially with intellivoice support. So, how soon can I buy a cart? :ponder:

I'll tell you what I'll do, if I find the time I'll create a sprite sheet for the game, post it here, and maybe someone savy in Assembler will use it to make INTV Gauntlet. Its the best I can do atm. :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   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...