Newbie with a game idea

[SeaGtGruff]

I still don't fully understand the 48 pixels per scanline limit. Add that to the many functional things I am yet to learn about the 2600.

The 2600 has only 7 or 8 components that can be used to create its graphical displays:

 

(1) The "background"

(2) The "playfield"

(3) The "player 0" sprite

(4) The "player 1" sprite

(5) The "missile 0" sprite

(6) The "missile 1" sprite

(7) The "ball" sprite

( 8 ) The "blanking"

 

The blanking doesn't really count, because you can't really "draw" with it. It can be somewhat useful in certain rare situations, but for the most part it's used strictly to "turn off" the picture (or the TV's scanning beams) between the bottom of one raster frame and the top of the next raster frame-- i.e., it creates the "black border" that surrounds the game screen. We really shouldn't count it as a graphical component.

 

The background has no pixels per se that can be turned on and off-- in a sense, it's like one giant pixel that fills the game screen, serving as the paper or canvas on which you paint the game screen using the other graphical components. But you can change the color of the background from scan line to scan line, or even in the middle of drawing a scan line. Also, the background shows through wherever the pixels of the other graphical components are turned off, so you can use the "off" pixels to draw with the background inside a sprite-- for example, if you draw a round ball with one of the players, you can turn off some of the pixels inside the ball to make the eyes and mouth of a smiley face.

 

The playfield spans the entire game screen, but it has very wide pixels-- 4 color clocks wide (a color clock is the size of the smallest pixel that the 2600 can draw). There are 160 active (or "visible") color clocks on a scan line, so since each playfield pixel is 4 clocks wide, that means there are only 40 playfield pixels on a line (160 / 4 = 40). The playfield and the background work together to create a 2-color foreground/background combination-- if a playfield pixel is on, you get the foreground color (or playfield color); and where a playfield pixel is off, you get the background color. So you basically have a 2-color game screen of 40x192 pixels, where each pixel can be either the playfield color or the background color. Of course, you can change the playfield color from line to line, or in the middle of a line, so you can display a lot more than just 2 colors on the screen.

 

The two player sprites are small-- each one is only 8 pixels wide-- but they're sprites, so you can move them around on the screen. Also, there are some neat things you can do with the two sprites, such as change how wide they are and how many copies of them are drawn on the screen. Since the players are kind of complicated, we'll come back to them in a moment.

 

The two missile sprites are even smaller-- each one is only 1 pixel wide! But again, you can move them around, as well as change how wide they are and how many copies of them are drawn on the screen.

 

The ball is like a missile-- it's also only 1 pixel wide, but you can move it around and change how wide it is. On the other hand, you can't draw multiple copies of it the way you can do with the two missiles and two players.

 

So ignoring the blanking, there are 7 graphical components you can use to draw your game screen. However, there's only 4 colors you can draw with, because missile 0 has the same color as player 0, missile 1 has the same color as player 1, and the ball has the same color as the playfield. It's like you've got 4 paint cans. If you want to use more than 4 colors on your game screen, you have to change the colors in the paint cans.

 

Normally, the pixels of the players, missiles, and ball are only 1 clock wide. If it were possible to fill the screen with them, from left to right, you could have 160 pixels across the screen. But the most you can have are 3 copies of player 0, 3 copies of player 1, 3 copies of missile 0, and 3 copies of missile 1, so you can't fill up the screen with them. If you want to create a "hi-res" bitmap area on the screen, the best you can do is position 3 copies of player 0 and 3 copies of player 1 in such a way that you get an area that's 48 pixels wide (3 x 8 = 24, and 3 x 8 = 24, and 24 + 24 = 48). This is how 2600 programmers create a hi-res 6-digit "score" display, or a hi-res title or logo. So that's what the "48 pixels per scan line" is referring to. Note that this refers to just the players, so if you add the 2 missiles and the ball you could get 51 pixels (48 + 3).

 

If you stick to just 1 copy of a player, you can change its width to make it either 2 times as wide as normal, or 4 times as wide as normal. That doesn't mean you get more pixels-- you still have 8 pixels for the player, but each pixel is wider.

 

As for the missiles, you can make a missile's 1 pixel either 2 times as wide as normal, 4 times as wide as normal, or 8 times as wide as normal. Unlike the players, you can also have multiple copies of a missile even when it's wider than normal, since each missile will be drawn with the same number of copies as the player it goes with-- i.e., if you have 3 copies of player 0, you will/must also have 3 copies of missile 0.

 

Like the missiles, the ball can also be 2 times, 4 times, or 8 times as wide as normal.

 

The graphical components have a certain priority when drawing the screen, as if each one is cut out of construction paper, and you can stack them on top of each other in layers:

 

From top to bottom:

- player 0 and missile 0

- player 1 and missile 1

- the playfield and the ball

- the background

 

So if you turn off a pixel inside player 0, whatever's underneath it will show through-- either the player1/missile1 color, or the playfield/ball color, or the background color, depending on what's "underneath" or "behind" player 0 at that spot.

 

If you want, you can change the priority to put the players and missiles "behind" the playfield and ball:

 

From top to bottom:

- the playfield and the ball

- player 0 and missile 0

- player 1 and missile 1

- the background

 

Another thing you can do is change the playfield so the left half is drawn with player 0's color, and the right half is drawn with player 1's color. This is called "score mode," because some games draw the score in big digits using the playfield pixels instead of with the player sprites, and "score mode" lets you draw a score in player 0's color on the left side, and draw a second score in player 1's color on the right side.

 

Continuing with the playfield for a minute, there are actually only 20 playfield pixels, not 40 as previously stated. The 20 playfield pixels fill up the left half of the screen. Then the right half of the screen is drawn using the same 20 playfield pixels, but you can either "duplicate" them so the right side is a repeat of the left side, or you can "flip" them so the right side is a reflection or mirror image of the left side.

 

Getting back to the players, each player can be drawn in 8 different ways:

 

% 000 or 0 = 1 copy of the player, normal size

% 001 or 1 = 2 copies of the player, normal size, "near" spacing (see below)

% 010 or 2 = 2 copies of the player, normal size, "medium" spacing

% 011 or 3 = 3 copies of the player, normal size, "near" spacing

% 100 or 4 = 2 copies of the player, normal size, "far" spacing

% 101 or 5 = 1 copy of the player, 2 times as wide as normal

% 110 or 6 = 3 copies of the player, normal size, "medium" spacing

% 111 or 7 = 1 copy of the player, 4 times as wide as normal

 

In essence, there are 4 copies of each player, with the following spacing between them:

 

xxxxxxxx________xxxxxxxx________xxxxxxxx________________________xxxxxxxx

main___________near____________medium_________________________far

 

The main copy is always on, but the near, medium, and far copies have to be enabled by setting a control bit in the player's "NUSIZ" (number-size) register. The binary numbers shown above represent the control bits, with bit 0 enabling the near copy, bit 1 enabling the medium copy, and bit 2 enabling the far copy. If you try to turn on more than 1 copy at a time, they must be equally-spaced from each other, otherwise you end up getting just 1 copy, but the size is different. For example, setting the control bits to % 011 tries to enable both the near copy and the medium copy at the same time. Since the space between the main copy and the near copy is the same as the space between the near copy and the medium copy, you get 3 copies in all-- the main copy, near copy, and medium copy. But if you set the control bits to % 101, you'd be trying to enable the near copy and far copy at the same time-- and since the space between the near copy and the far copy is *not* the same as the space between the main copy and the near copy, you get just 1 copy, but it's 2 times as wide as normal.

 

All of the above refers to drawing the screen with the 2600's "standard" features and abilities. But since you can change the graphics control registers while a line is being drawn, you can actually do some "tricks" that stretch the 2600 beyond its standard abilities. For example, we've already noted that you can change the color of any of the graphical components while a line is being drawn. You can also change the graphics or pixel patterns of the components mid-line. This lets you draw a playfield where the left and right sides are completely different-- an "asymmetrical" playfield-- by changing the 20 playfield pixels after the left side's been drawn, so the right side has its own pixel pattern instead of being just a repeat or reflection of the left side. Normally, when you draw multiple copies of a sprite, each copy has the same shape as the main copy-- but you can change the shape of the sprite between the copies, so that each copy has a different shape (which is how you draw the different digits of a score with the sprites). Also, each copy of a sprite is the same color as the main copy-- but you can change the color of the sprite between the copies, so that each copy has a different color. And perhaps even more exciting, you can reposition the main copy of a sprite after it's been drawn, which allows you to draw more than 3 copies of a sprite on a line (but there are some limitations to this).

 

Unfortunately, the 2600 has a slow processing speed, so there's only enough time to do a certain number of updates while you're drawing a line. For example, you can position 3 copies of player 0 and 3 copies of player 1 in such a way that you can draw 6 digits of a score, and update the graphics so that each digit has its own shape, but there's no time to change their colors as well. (For that matter, drawing a 6-digit score requires using the sprites' "delay" feature so that you can make all the changes fast enough to give each digit a different shape.) And if you draw an asymmetrical playfield, it will use up some of the time that would be needed to make other changes. So if you want to do several graphics changes mid-line (or even just from line to line), you have to plan your screen display carefully as far as which changes need to be made when, and how many changes you can squeeze into each line.

 

It can be quite a challenge to achieve the game screen you want to draw, but it can also be a lot of fun-- especially since you usually feel a real sense of accomplishment if you can manage to work it all out so it seems like the 2600 is drawing a game screen that "should" be impossible for it given its "normal" abilities.

 

Michael

Edited November 10, 2010 by SeaGtGruff

[Brian O]

I still don't fully understand the 48 pixels per scanline limit. Add that to the many functional things I am yet to learn about the 2600.

The 2600 has only 7 or 8 components that can be used to create its graphical displays:

 

(1) The "background"

(2) The "playfield"

(3) The "player 0" sprite

(4) The "player 1" sprite

(5) The "missile 0" sprite

(6) The "missile 1" sprite

(7) The "ball" sprite

( 8 ) The "blanking"

 

The blanking doesn't really count, because you can't really "draw" with it. It can be somewhat useful in certain rare situations, but for the most part it's used strictly to "turn off" the picture (or the TV's scanning beams) between the bottom of one raster frame and the top of the next raster frame-- i.e., it creates the "black border" that surrounds the game screen. We really shouldn't count it as a graphical component.

 

The background has no pixels per se that can be turned on and off-- in a sense, it's like one giant pixel that fills the game screen, serving as the paper or canvas on which you paint the game screen using the other graphical components. But you can change the color of the background from scan line to scan line, or even in the middle of drawing a scan line. Also, the background shows through wherever the pixels of the other graphical components are turned off, so you can use the "off" pixels to draw with the background inside a sprite-- for example, if you draw a round ball with one of the players, you can turn off some of the pixels inside the ball to make the eyes and mouth of a smiley face.

 

The playfield spans the entire game screen, but it has very wide pixels-- 4 color clocks wide (a color clock is the size of the smallest pixel that the 2600 can draw). There are 160 active (or "visible") color clocks on a scan line, so since each playfield pixel is 4 clocks wide, that means there are only 40 playfield pixels on a line (160 / 4 = 40). The playfield and the background work together to create a 2-color foreground/background combination-- if a playfield pixel is on, you get the foreground color (or playfield color); and where a playfield pixel is off, you get the background color. So you basically have a 2-color game screen of 40x192 pixels, where each pixel can be either the playfield color or the background color. Of course, you can change the playfield color from line to line, or in the middle of a line, so you can display a lot more than just 2 colors on the screen.

 

The two player sprites are small-- each one is only 8 pixels wide-- but they're sprites, so you can move them around on the screen. Also, there are some neat things you can do with the two sprites, such as change how wide they are and how many copies of them are drawn on the screen. Since the players are kind of complicated, we'll come back to them in a moment.

 

The two missile sprites are even smaller-- each one is only 1 pixel wide! But again, you can move them around, as well as change how wide they are and how many copies of them are drawn on the screen.

 

The ball is like a missile-- it's also only 1 pixel wide, but you can move it around and change how wide it is. On the other hand, you can't draw multiple copies of it the way you can do with the two missiles and two players.

 

So ignoring the blanking, there are 7 graphical components you can use to draw your game screen. However, there's only 4 colors you can draw with, because missile 0 has the same color as player 0, missile 1 has the same color as player 1, and the ball has the same color as the playfield. It's like you've got 4 paint cans. If you want to use more than 4 colors on your game screen, you have to change the colors in the paint cans.

 

Normally, the pixels of the players, missiles, and ball are only 1 clock wide. If it were possible to fill the screen with them, from left to right, you could have 160 pixels across the screen. But the most you can have are 3 copies of player 0, 3 copies of player 1, 3 copies of missile 0, and 3 copies of missile 1, so you can't fill up the screen with them. If you want to create a "hi-res" bitmap area on the screen, the best you can do is position 3 copies of player 0 and 3 copies of player 1 in such a way that you get an area that's 48 pixels wide (3 x 8 = 24, and 3 x 8 = 24, and 24 + 24 = 48). This is how 2600 programmers create a hi-res 6-digit "score" display, or a hi-res title or logo. So that's what the "48 pixels per scan line" is referring to. Note that this refers to just the players, so if you add the 2 missiles and the ball you could get 51 pixels (48 + 3).

 

If you stick to just 1 copy of a player, you can change its width to make it either 2 times as wide as normal, or 4 times as wide as normal. That doesn't mean you get more pixels-- you still have 8 pixels for the player, but each pixel is wider.

 

As for the missiles, you can make a missile's 1 pixel either 2 times as wide as normal, 4 times as wide as normal, or 8 times as wide as normal. Unlike the players, you can also have multiple copies of a missile even when it's wider than normal, since each missile will be drawn with the same number of copies as the player it goes with-- i.e., if you have 3 copies of player 0, you will/must also have 3 copies of missile 0.

 

Like the missiles, the ball can also be 2 times, 4 times, or 8 times as wide as normal.

 

The graphical components have a certain priority when drawing the screen, as if each one is cut out of construction paper, and you can stack them on top of each other in layers:

 

From top to bottom:

- player 0 and missile 0

- player 1 and missile 1

- the playfield and the ball

- the background

 

So if you turn off a pixel inside player 0, whatever's underneath it will show through-- either the player1/missile1 color, or the playfield/ball color, or the background color, depending on what's "underneath" or "behind" player 0 at that spot.

 

If you want, you can change the priority to put the players and missiles "behind" the playfield and ball:

 

From top to bottom:

- the playfield and the ball

- player 0 and missile 0

- player 1 and missile 1

- the background

 

Another thing you can do is change the playfield so the left half is drawn with player 0's color, and the right half is drawn with player 1's color. This is called "score mode," because some games draw the score in big digits using the playfield pixels instead of with the player sprites, and "score mode" lets you draw a score in player 0's color on the left side, and draw a second score in player 1's color on the right side.

 

Continuing with the playfield for a minute, there are actually only 20 playfield pixels, not 40 as previously stated. The 20 playfield pixels fill up the left half of the screen. Then the right half of the screen is drawn using the same 20 playfield pixels, but you can either "duplicate" them so the right side is a repeat of the left side, or you can "flip" them so the right side is a reflection or mirror image of the left side.

 

Getting back to the players, each player can be drawn in 8 different ways:

 

% 000 or 0 = 1 copy of the player, normal size

% 001 or 1 = 2 copies of the player, normal size, "near" spacing (see below)

% 010 or 2 = 2 copies of the player, normal size, "medium" spacing

% 011 or 3 = 3 copies of the player, normal size, "near" spacing

% 100 or 4 = 2 copies of the player, normal size, "far" spacing

% 101 or 5 = 1 copy of the player, 2 times as wide as normal

% 110 or 6 = 3 copies of the player, normal size, "medium" spacing

% 111 or 7 = 1 copy of the player, 4 times as wide as normal

 

In essence, there are 4 copies of each player, with the following spacing between them:

 

xxxxxxxx________xxxxxxxx________xxxxxxxx________________________xxxxxxxx

main___________near____________medium_________________________far

 

The main copy is always on, but the near, medium, and far copies have to be enabled by setting a control bit in the player's "NUSIZ" (number-size) register. The binary numbers shown above represent the control bits, with bit 0 enabling the near copy, bit 1 enabling the medium copy, and bit 2 enabling the far copy. If you try to turn on more than 1 copy at a time, they must be equally-spaced from each other, otherwise you end up getting just 1 copy, but the size is different. For example, setting the control bits to % 011 tries to enable both the near copy and the medium copy at the same time. Since the space between the main copy and the near copy is the same as the space between the near copy and the medium copy, you get 3 copies in all-- the main copy, near copy, and medium copy. But if you set the control bits to % 101, you'd be trying to enable the near copy and far copy at the same time-- and since the space between the near copy and the far copy is *not* the same as the space between the main copy and the near copy, you get just 1 copy, but it's 2 times as wide as normal.

 

All of the above refers to drawing the screen with the 2600's "standard" features and abilities. But since you can change the graphics control registers while a line is being drawn, you can actually do some "tricks" that stretch the 2600 beyond its standard abilities. For example, we've already noted that you can change the color of any of the graphical components while a line is being drawn. You can also change the graphics or pixel patterns of the components mid-line. This lets you draw a playfield where the left and right sides are completely different-- an "asymmetrical" playfield-- by changing the 20 playfield pixels after the left side's been drawn, so the right side has its own pixel pattern instead of being just a repeat or reflection of the left side. Normally, when you draw multiple copies of a sprite, each copy has the same shape as the main copy-- but you can change the shape of the sprite between the copies, so that each copy has a different shape (which is how you draw the different digits of a score with the sprites). Also, each copy of a sprite is the same color as the main copy-- but you can change the color of the sprite between the copies, so that each copy has a different color. And perhaps even more exciting, you can reposition the main copy of a sprite after it's been drawn, which allows you to draw more than 3 copies of a sprite on a line (but there are some limitations to this).

 

Unfortunately, the 2600 has a slow processing speed, so there's only enough time to do a certain number of updates while you're drawing a line. For example, you can position 3 copies of player 0 and 3 copies of player 1 in such a way that you can draw 6 digits of a score, and update the graphics so that each digit has its own shape, but there's no time to change their colors as well. (For that matter, drawing a 6-digit score requires using the sprites' "delay" feature so that you can make all the changes fast enough to give each digit a different shape.) And if you draw an asymmetrical playfield, it will use up some of the time that would be needed to make other changes. So if you want to do several graphics changes mid-line (or even just from line to line), you have to plan your screen display carefully as far as which changes need to be made when, and how many changes you can squeeze into each line.

 

It can be quite a challenge to achieve the game screen you want to draw, but it can also be a lot of fun-- especially since you usually feel a real sense of accomplishment if you can manage to work it all out so it seems like the 2600 is drawing a game screen that "should" be impossible for it given its "normal" abilities.

 

Michael

 

 

Thanks for taking the time to provide some insight into how the 2600 works, Michael. That's some great information.

 

While I understand that the 2600 is limited in the elements that it can display (and when it can display them), I have trouble visualizing how these elements are applied to the actual game. Take the game I have concepted, for instance, I am assuming that the main character that you control would be the Player 0 sprite, right? If that's the case, then are the platforms additional sprites that are redrawn each line scan (controlled by the NUSIZ register), or are these part of the playfield that are continually redrawn? And would the power ups also be sprites as well? In this case, would you leverage the Player 0 or Missle sprites for this? I am more visual than analytical (as you've probably guessed), so for me it helps to see these things applied to a real game.

 

Also, what component of my game would be the playfield? The two black bars at the top and bottom (I am assuming the white background is the background)? Would the pursuing black wall then the another sprite?

 

Even after reading your outline above, I'm not sure if what I am asking is correct. So I apologize if I'm not truly understanding.

 

Thanks,

Brian

[LS_Dracon]

I did one conceptual screen for your game.

 

The playfeld is the black box in the left.

The player 0 is the main character (not displayed here)

Player 1 is the platforms. In order to change the color in black area I use one color trick, I think it's looks cool.

 

The missile and ball are not used. You can use the space between platforms to draw other player 1 (items).

 

The ball can be used for obstacles, sharing the playfield color, the ball will be black. I can use other trick to change the ball color (using playfield "score" type).

 

I think this game can be fun, you should learn about 2600 programming. Give a try.

fotd.bin

Edited November 10, 2010 by LS_Dracon

[Brian O]

I did one conceptual screen for your game.

 

The playfeld is the black box in the left.

The player 0 is the main character (not displayed here)

Player 1 is the platforms. In order to change the color in black area I use one color trick, I think it's looks cool.

 

The missile and ball are not used. You can use the space between platforms to draw other player 1 (items).

 

The ball can be used for obstacles, sharing the playfield color, the ball will be black. I can use other trick to change the ball color (using playfield "score" type).

 

I think this game can be fun, you should learn about 2600 programming. Give a try.

 

Thanks for the info and the concept screen, LS. I don't think learning Atari 2600 programming is an option for me. I've never done any true programming of any sort.

 

As much as I'd love to develop my own Atari 2600 game, I think the actual programming is beyond me. I think with the other side of my brain.

 

But I do agree with you that the game could be fun. I figured I would try and design the screens and outline the game play the best I could, and hope that someone would take up the task of developing it. I would be more than willing to do as much work as necessary to help any developer make it happen. I've already designed the label, box art, manual, and built some preliminary screens pixel by pixel, which I have posted on page 2. Unfortunately, I'm not sure what more I can do given my knowledge of 2600 programming.

 

And believe me, I'm not out to make a buck. If I were, I wouldn't be jonesing to create a 2600 game

 

Oh well, we'll see what happens. I'm going to continue to concept the game the best I can from my end, and create some more screens to keep things moving forward. However, if a developer doesn't pick up the idea and actually develop it, I feel as if this is as far as it'll go.

 

I really do appreciate all of the positive feedback and support that everyone, including you, has shown me, though. I never expected this much of a response when I first posted!

 

-B

[SeaGtGruff]

If I were programming your game idea, I would probably draw the screen as follows:

 

background = the white area that Jumpy moves through, as well as the platforms that have been overtaken by "the dark"

playfield = the black platforms that Jumpy has to land on, as well as "the dark"

player0 = Jumpy

player1 = the various bonus items or powerups, including the "speed decrease" powerup (or "powerdown"?)

missile0 = the red platform that unlocks the door

ball = the walls and doors

 

The background color would be white. The platforms inside the dark" would also be white, rather than gray.

The playfield/ball color would be black. To make the walls and doors look gray, you could turn the ball on and off from line to line, to make a black-and-white stripe pattern.

The player0/missile0 color would be red.

The player1/missile1 color would be green or red (but not the same color red as Jumpy), depending on the type of powerup.

 

Michael

 

 

 

[Brian O]

If I were programming your game idea, I would probably draw the screen as follows:

 

background = the white area that Jumpy moves through, as well as the platforms that have been overtaken by "the dark"

playfield = the black platforms that Jumpy has to land on, as well as "the dark"

player0 = Jumpy

player1 = the various bonus items or powerups, including the "speed decrease" powerup (or "powerdown"?)

missile0 = the red platform that unlocks the door

ball = the walls and doors

 

The background color would be white. The platforms inside the dark" would also be white, rather than gray.

The playfield/ball color would be black. To make the walls and doors look gray, you could turn the ball on and off from line to line, to make a black-and-white stripe pattern.

The player0/missile0 color would be red.

The player1/missile1 color would be green or red (but not the same color red as Jumpy), depending on the type of powerup.

 

Michael

 

Michael, this is some good info. It definitely helps me better visualize what each screen item represents. For the walls and doors, would the black and white stripe pattern look gray? Is there no gray color, or does have to do with not having more than one color per line? Also, why would the red power up need to be a different color than Jumpy?

 

Thanks!

-B

[Brian O]

Here's the revised screenshots, based on SeaGtGruff's comments. I have also attached some GIF animations I made using PAC-MAN-RED's sprites.

 

Feedback, as usual, is welcome

 

-B

[SeaGtGruff]

Michael, this is some good info. It definitely helps me better visualize what each screen item represents. For the walls and doors, would the black and white stripe pattern look gray? Is there no gray color, or does have to do with not having more than one color per line? Also, why would the red power up need to be a different color than Jumpy?

 

Thanks!

-B

The black-and-white stripes would look like stripes, but you could flicker them to make them gray. The 2600 does have gray, of course, but the ball uses the same color as the playfield, so if the playfield (the platforms and "the dark") is black, then the ball would have to be black, too. You could change the playfield color midline to make the ball gray, but that would also make the platforms gray if they were in the same area as the wall or door, so I figured it would be better to just alternate the ball between black ("on") and white ("off") so the doors and wall would look different than the platforms, and have a grayish look overall (especially if flickered, although flickering between black and white makes the flickering more pronounced, and a lot of people don't like flickering).

 

The only reason I suggested that the red powerup (or "slow down") be a different red than Jumpy was to give the screen a little more color variation. They could be the same color red, but it might be more aesthetically pleasing if they were different colors of red. Also, you might want to make the "speed up" and "jump farther" objects different colors, like green for the "speed up" (green = go ) and blue for the "jump farther" (blue = sky?). Again, that would simply be to add a little more color to the game screen.

 

If you use the playfield for the platforms and the dark, keep in mind that playfield pixels are wider-- 4 cells wide (where 1 cell is a light gray or white rectangles on the screen template you posted in another thread). There are only 40 playfield pixels on a line, and they have set positions. For example, the first playfield pixel always spans columns 0, 1, 2, and 3 on the screen (of the 160 columns or screen positions); the second playfield pixel is always in columns 4, 5, 6, and 7; and so on. In other words, you can't draw them so they take up other columns, or move them a single screen position at a time. So that would affect the way the platforms move left and right-- they would "jump" 4 screen positions at a time, and the dark would also advance 4 screen positions at a time. It also means you can't have "beveled" edges on the left and right sides of the platform as drawn in your mockups, just rectangular edges.

 

Since I didn't use missile1 in my description of how I'd do it, you could always use missile1 for the platforms instead of the playfield. That would let you give the platforms beveled edges, and you could also move the platforms more smoothly, 1 screen position left or right at a time. But since missile1 has the same color as player1, and player1 would be green, or red, or maybe even blue (for the bonus objects), you'd have to be careful not to have bonus objects on the same scan lines as the platforms, otherwise you'd have to worry about changing colors midline, and that could get tricky if things are moving around. It's a lot easier to change colors between lines, and it shouldn't be a design problem to keep the platforms and bonus objects on separate lines from each other, so using missile1 for the platforms is definitely a possibility. The only other thing to be aware of, if using missile1 for the platforms, is that it would affect how many platforms you can have on the same line. You can draw up to 3 copies of missile1 on a line, but if you move one of them, they would all move in the same direction at the same time (on that line). So if that would fit in with your design, you might want to go with using missile1 for the platforms instead of using the playfield for them.

 

Michael

 

Edit: Actually, using missile1 for the platforms would *not* let you draw beveled edges on them, but it would let you move the platforms more smoothly.

Edited November 12, 2010 by SeaGtGruff

[Brian O]

Michael, this is some good info. It definitely helps me better visualize what each screen item represents. For the walls and doors, would the black and white stripe pattern look gray? Is there no gray color, or does have to do with not having more than one color per line? Also, why would the red power up need to be a different color than Jumpy?

 

Thanks!

-B

The black-and-white stripes would look like stripes, but you could flicker them to make them gray. The 2600 does have gray, of course, but the ball uses the same color as the playfield, so if the playfield (the platforms and "the dark") is black, then the ball would have to be black, too. You could change the playfield color midline to make the ball gray, but that would also make the platforms gray if they were in the same area as the wall or door, so I figured it would be better to just alternate the ball between black ("on") and white ("off") so the doors and wall would look different than the platforms, and have a grayish look overall (especially if flickered, although flickering between black and white makes the flickering more pronounced, and a lot of people don't like flickering).

 

The only reason I suggested that the red powerup (or "slow down") be a different red than Jumpy was to give the screen a little more color variation. They could be the same color red, but it might be more aesthetically pleasing if they were different colors of red. Also, you might want to make the "speed up" and "jump farther" objects different colors, like green for the "speed up" (green = go ) and blue for the "jump farther" (blue = sky?). Again, that would simply be to add a little more color to the game screen.

 

If you use the playfield for the platforms and the dark, keep in mind that playfield pixels are wider-- 4 cells wide (where 1 cell is a light gray or white rectangles on the screen template you posted in another thread). There are only 40 playfield pixels on a line, and they have set positions. For example, the first playfield pixel always spans columns 0, 1, 2, and 3 on the screen (of the 160 columns or screen positions); the second playfield pixel is always in columns 4, 5, 6, and 7; and so on. In other words, you can't draw them so they take up other columns, or move them a single screen position at a time. So that would affect the way the platforms move left and right-- they would "jump" 4 screen positions at a time, and the dark would also advance 4 screen positions at a time. It also means you can't have "beveled" edges on the left and right sides of the platform as drawn in your mockups, just rectangular edges.

 

Since I didn't use missile1 in my description of how I'd do it, you could always use missile1 for the platforms instead of the playfield. That would let you give the platforms beveled edges, and you could also move the platforms more smoothly, 1 screen position left or right at a time. But since missile1 has the same color as player1, and player1 would be green, or red, or maybe even blue (for the bonus objects), you'd have to be careful not to have bonus objects on the same scan lines as the platforms, otherwise you'd have to worry about changing colors midline, and that could get tricky if things are moving around. It's a lot easier to change colors between lines, and it shouldn't be a design problem to keep the platforms and bonus objects on separate lines from each other, so using missile1 for the platforms is definitely a possibility. The only other thing to be aware of, if using missile1 for the platforms, is that it would affect how many platforms you can have on the same line. You can draw up to 3 copies of missile1 on a line, but if you move one of them, they would all move in the same direction at the same time (on that line). So if that would fit in with your design, you might want to go with using missile1 for the platforms instead of using the playfield for them.

 

Michael

 

Edit: Actually, using missile1 for the platforms would *not* let you draw beveled edges on them, but it would let you move the platforms more smoothly.

 

Thanks, Michael. I appreciate the info. I'm learning new things about how the games for Atari are created every day.

 

If this game were to get developed by someone (most likely not me ), I would prefer the platforms to move smoother, so using the Missle1 object would probably be better. Plus, I'd prefer that the platforms be more random, like how they appear in Splatform. I would imagine there would still need to be some parameters around the platforms' randomness, since I wouldn't want the platforms overlapping the walls or doors. I'd be willing to sacrifice some color for the powerups in order to have the platforms move smoother. That said, how would the black box (the darkness) move. Would that still be part of the playfield, and limited to moving a minimun of 4 spaces per line scan? That seems to me as if it would be clunky, but perhaps I'm not visualizing it correctly.

 

I like your suggestion for the wall color (using the black and white w/ flicker to get a gray color).

 

One quick question -- Does the title screen leverage playfield graphics or sprite graphics (or both)?

 

 

Thanks again for taking the time to provide me with some insights. Really appreciate it!

 

-B

[Thomas Jentzsch]

If this game were to get developed by someone (most likely not me )...,

Chances are very low that this is going to happen. So you better learn to code yourself.

 

...I would prefer the platforms to move smoother, so using the Missle1 object would probably be better.

Splatform uses a player for the platforms since the missile is too small. But then you have not much left for drawing the other objects (except flicker).

 

Plus, I'd prefer that the platforms be more random, like how they appear in Splatform. I would imagine there would still need to be some parameters around the platforms' randomness, since I wouldn't want the platforms overlapping the walls or doors.

IMO it would be easier if you first create the platforms and then insert the other elements where they fit.

 

I'd be willing to sacrifice some color for the powerups in order to have the platforms move smoother.

An early approach of Splatform used PF graphics for the platforms and delayed scrolling (like in Thrust). That way the scrolling looks smooth. I suppose that might be the best compromise here.

 

That said, how would the black box (the darkness) move. Would that still be part of the playfield, and limited to moving a minimun of 4 spaces per line scan? That seems to me as if it would be clunky, but perhaps I'm not visualizing it correctly.

With PF graphics for the platforms and delayed scrolling, everything would move in 4 pixel chunks, but it wouldn't look clunky.

If you use a player for the platforms and real smooth scrolling, using the ball combined with the PF (both set to black) could create the required smoothness here.

Edited November 12, 2010 by Thomas Jentzsch

[Brian O]

Chances are very low that this is going to happen. So you better learn to code yourself.

 

Unfortunately, I am not a programmer and I doubt I could learn enough to create something worth actually playing (if that). In terms of programming, I'd basically have to start from scratch.

 

But thank you for all of the information. I am learning a lot, and even concepting this game has been a very good learning experience for me.

 

 

That said, I've done all that I can do. If anyone wants to take a crack at this game, I'd be more than happy to assist in any way I can.

 

Thanks again, everyone!

[tokumaru]

If I was in charge of programming this game, I would try to do something like this (please forgive my lack of patience to draw more platforms):

 

 

TIA objects are used like this:

 

BACKGROUND: background;

PLAYFIELD: dark/shadow;

BALL: walls and doors;

PLAYER 0: jumpy;

MISSILE 0: free;

PLAYER 1: platforms and items;

MISSILE 1: platforms;

 

I decided to alternate the shadow and the walls/doors, so that they can use different colors, and with the playfield having higher priority than the other objects it will sorta look like the shadow is covering them. Everything is able to move smoothly, except for the shadow, that can only move in 4-pixel steps (personally I would try to smooth out its movement by flickering between two states for a while before completely switching to the new state).

[Brian O]

If I was in charge of programming this game, I would try to do something like this (please forgive my lack of patience to draw more platforms):

 

 

TIA objects are used like this:

 

BACKGROUND: background;

PLAYFIELD: dark/shadow;

BALL: walls and doors;

PLAYER 0: jumpy;

MISSILE 0: free;

PLAYER 1: platforms and items;

MISSILE 1: platforms;

 

I decided to alternate the shadow and the walls/doors, so that they can use different colors, and with the playfield having higher priority than the other objects it will sorta look like the shadow is covering them. Everything is able to move smoothly, except for the shadow, that can only move in 4-pixel steps (personally I would try to smooth out its movement by flickering between two states for a while before completely switching to the new state).

 

 

tokumaru --

 

That screenshot looks great! I like how you've included the shine on Jump's head, too

 

I don't think having the shadow move in 4-pixel increments is a bad thing. I think it lends itself to the lumbering movement of an approaching shadow. I also like how the shadow is not completely solid.

 

Quick question -- The shadow basically chases the player for the entire game. However, during the game, the player could potentially put a good amount of distance between himself and the shadow, causing it to disappear from the screen. Theoretically, if the player were to stop and stay still a few moments, the show would reappear and start approaching again. Is that something that's doable?

 

What would happen if the walls/doors had the same color as the shadow?

 

Seriously, that screenshot looks great.

 

Thanks!

-B

[tokumaru]

That screenshot looks great! I like how you've included the shine on Jump's head, too

Heh, I'm glad you like it. =)

 

I don't think having the shadow move in 4-pixel increments is a bad thing. I think it lends itself to the lumbering movement of an approaching shadow.

Yeah, I agree. Also, when I suggested the flickering to smooth out the movement I was thinking about erratic lights, like from candles, that don't produce perfectly still shadows. I'm not sure it would look good, but it would be something interesting to try.

 

I also like how the shadow is not completely solid.

Technically, it's easier that way, because in the scanlines where there's no shadow its color can be used for other things (like I did with the wall) and you take a break from drawing an asymmetric playfield (a task that can be pretty time-consuming).

 

Quick question -- The shadow basically chases the player for the entire game. However, during the game, the player could potentially put a good amount of distance between himself and the shadow, causing it to disappear from the screen. Theoretically, if the player were to stop and stay still a few moments, the show would reappear and start approaching again. Is that something that's doable?

Sure, perfectly doable. A game is a simulated world, as long as you keep track of the coordinates of the player, the shadow and the camera within this world and update them every frame you should be able to tell what's visible and what's not at any given time (so that you can decide whether to draw them), but everything still "lives" even when off-screen.

 

What would happen if the walls/doors had the same color as the shadow?

No problem. I think the wall looks kinda faint in my mock-up because of the light background, but you could just as well make it always use the same color as the shadow or alternate between it and any other color so that it doesn't look so faint.

[SeaGtGruff]

Everything is able to move smoothly, except for the shadow, that can only move in 4-pixel steps (personally I would try to smooth out its movement by flickering between two states for a while before completely switching to the new state).

I tried that once with a scrolling playfield to see if it would make the motion look smoother, but it turned out that it didn't look so good.

 

Michael

[tokumaru]

I tried that once with a scrolling playfield to see if it would make the motion look smoother, but it turned out that it didn't look so good.

I see... Good to know it has been tried. But that was for solid objects, right? I only considered it in this case because we're talking about light and shadow, and those could naturally flicker depending on how (un)stable the source of light is. If it doesn't work we can always revert back to the regular scrolling. =)

[Brian O]

Thanks for the input, guys.

[Brian O]

Here's a new Title Screen comp. Not sure if this is doable, but I made sure to keep all graphic elements to 48 pixels wide. I ditched the black box and the jump swoosh that I had in a previous iteration.

 

-B

[SeaGtGruff]

I tried that once with a scrolling playfield to see if it would make the motion look smoother, but it turned out that it didn't look so good.

I see... Good to know it has been tried. But that was for solid objects, right? I only considered it in this case because we're talking about light and shadow, and those could naturally flicker depending on how (un)stable the source of light is. If it doesn't work we can always revert back to the regular scrolling. =)

Yes, it was for solid objects, but it doesn't really matter-- a line made out of playfield pixels is solid, too. Anyway, even if you flicker the playfield pixels to try to make it look like the scrolling is smoother, it won't stop the TIA from registering a collision if Jumpy touches the flickering playfield, so it will still *act* as though the dark had already moved forward a full 4 clocks.

 

The only way to make the playfield appear to scroll less than 4 clocks at a time is to use the ball. That could work in this game, but probably not if the ball is being used for the walls and door.

 

Michael

[tokumaru]

Anyway, even if you flicker the playfield pixels to try to make it look like the scrolling is smoother, it won't stop the TIA from registering a collision if Jumpy touches the flickering playfield, so it will still *act* as though the dark had already moved forward a full 4 clocks.

Sure, but being such a simple kind of collision I guess it wouldn't be a problem to check for it in software instead of using the hardware collision flags. But like you said, the effect probably won't even look good, so there's no reason to worry about this.

 

The only way to make the playfield appear to scroll less than 4 clocks at a time is to use the ball. That could work in this game, but probably not if the ball is being used for the walls and door.

Yeah, that was my original idea for the ball too, until I remembered about the walls and doors. Missile 0 is still free, but the fact that it will share Jumpy's colors in the scanlines where both are displayed doesn't help... I just can't think of a way to have it all.

[yuppicide]

You can do a nice titlescreen with RevEng's Titlescreen kernel. They're fairly easy to get incorporated in the game as well.

 

I love the manual. I don't like how the special thanks is in Spanish and the rest is English. Why? Why am I not able to read it too? That's like the Indian people at work talking in half English and then half Indian. They have to repeat everything in English afterwards.

 

I wasn't going to make a Fear of The Dark Joke, but there's two nice parts in the song I thought maybe could be converted into a 2600 tune.

[jd_1138]

I like the artwork for Fear of the Dark. Some of these homebrew games have really cool artwork, like the Crazy Balloon & Gun Fight titles available in the AA store. It doesn't have to try to look like 1981ish. Modern design/packaging for a game for a classic console is cool. If I created a homebrew game, I'd make a CafePress webstore to sell t-shirts and coffee mugs and such with the artwork on it.

 

I hope you get your game made.

[Brian O]

You can do a nice titlescreen with RevEng's Titlescreen kernel. They're fairly easy to get incorporated in the game as well.

 

I love the manual. I don't like how the special thanks is in Spanish and the rest is English. Why? Why am I not able to read it too? That's like the Indian people at work talking in half English and then half Indian. They have to repeat everything in English afterwards.

 

I wasn't going to make a Fear of The Dark Joke, but there's two nice parts in the song I thought maybe could be converted into a 2600 tune.

 

I'll have to look into that. I have been creating everything in Photoshop, since I am not a programmer. Not sure how far I'd get with RevEng's kernel.

 

Thanks for the kind words about the manual. LOL re: the Spanish copy. I was going to set all of the copy in dummy text. That would have sucked for you

 

Fear of the Dark's a great song. It'd be nice to have some snippets of that in the game!

 

-B

[Brian O]

I like the artwork for Fear of the Dark. Some of these homebrew games have really cool artwork, like the Crazy Balloon & Gun Fight titles available in the AA store. It doesn't have to try to look like 1981ish. Modern design/packaging for a game for a classic console is cool. If I created a homebrew game, I'd make a CafePress webstore to sell t-shirts and coffee mugs and such with the artwork on it.

 

I hope you get your game made.

 

Thanks, man. I hope it gets made, too

[tokumaru]

About the title screen, if you decide to use a dedicated kernel instead of a standard one you could do a lot of little tricks and end up with something that looks much more like your original art. something like this:

 

 

The background is white, while the playfield is black. Jumpy's outline is the ball, and his eyes and bright spots are holes that let you see the background color. The platform also uses the players and the ball.

 

EDIT: Minor updates to the picture.

Edited November 15, 2010 by tokumaru