Brian O

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

Hi everyone. Just "officially" joined Atari Age a couple of weeks ago. Figured I would create a blog to post some of my homebrew concepts, among other things. Here's my first game idea: "Fear of the Dark". I have created a few screenshots, as well as some box, label, and cartridge art for the game as well. Keep in mind, I'm no programmer, so the screenshots are just JPEG comps. Here's a screen example: The basic premise of the game is you control a red, bouncy alien named Jumpy. You need to jump from platform to platform, and keep moving forward, so that the black square on the left side (the "darkness") does not catch you. Along the way, there are walls that block your path, platforms that move side to side, and doors that can only be opened by stepping on red-colored platforms. There's also some scattered power ups that make you run faster and jump farther. Your objective is to stay alive as long as possible, which means not being caught by the darkness or falling off the bottom of the screen. You can see the full thread, including some game play concept sketches and manual, label and box art here. Let me know your thoughts Also, if there's any developers out there with nothing to do who would be interested in working on this with me, shoot me a note. I am currently concepting another game and will post some concept screens and/or label art once they are ready (probably next week). Thanks, all. -B

Silver Surfer is $$$.

Good to know, thanks!

Might as well put Rubik's Cube on there, too. This is a terrible list.

You're welcome. I've got some more Metroid sprites done, and I should be posting them later on today. I'm trying to do them in larger batches so that the thread doesn't get too long lol... ya it's a bit late for that, but I'm gonna try. Can't wait to see the Metroid sprites. I may download VBB and see what I can create. It might be fun. PS -- The av not animating was because of the size. You were right. Made the animation 120x120 and it worked. Thanks! -B

I created the animation in InDesign, so not sure what the issue is. It must be the dimensions. I'll try resizing before exporting it to see if that works. Thanks for your help! When are we going to see some new sprites? - B

Thank you. I appreciate your kind words, and from everyone. I created a simple walking and jumping GIF with the sprites you created. Looks pretty cool. Hey that looks great! Although, it looks different as your avatar. I think it is because it's a GIF picture being shrunk to fit as the avatar. If it's converted to PNG it should keep it looking the same. Thanks! Actually, I saved my avatar as a GIF image of the animation, but it won't play. I noticed your av is animated. How did you get it to animate? Am I doing something incorrect? The file I uploaded as my av animates if I drag into a browser... -B

Thanks. Makes sense seeing all of the work/pieces that goes into it. -B

That's a pretty wide range. Is this a one-time set up cost, or a per-cartridge cost? Considering that most sell for $25, I can imagine taking a loss of 50 bucks on each cartridge...

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!

Hi all -- I was just wondering: once a 2600 homebrew or hack game is completed, what are the costs/time to manufacture the cartridges? I searched the forums, but could not find anything that spoke specifically to cartridge manufacturing costs. Thanks! Brian

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

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

Thank you. I appreciate your kind words, and from everyone. I created a simple walking and jumping GIF with the sprites you created. Looks pretty cool.

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

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

Awesome. Nice job.

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

Thanks, LS_Dracon. I have played Man Goes Down many times. One of my favorite Atari games. Too bad it was never finished 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. I revised my screenshots and moved the score to the top right. Not sure if that solves the problem. Here's what I've attached: Screenshot 1 (FOD_NEW_Screenshots_1.jpg) -- Shows Jumpy picking up a Super Jump bonus item. A wall hangs from the ceiling, blocking his way. On the left, the black box (the "darkness") moves towards him. Screenshot 2 (FOD_NEW_Screenshots_2.jpg) -- Shows Jumpy jumping towards the RED platform that will unlock the door (the gray, striped bar that spans the height of the screen). In this comp, the black bar is close. When the black bar passes over the platforms, they turn gray, to show that they are in the dark. Screenshot 3 (FOD_NEW_Screenshots_3.jpg) -- Jummpy collides with the black box. His eyes turn to an "X" a halo can be seen over his head. Hopefully, this gives you a good idea of gameplay. I can't show moving platforms, but there would also be platforms that move back and forth horizontally and, possibly, vertically. Any feedback is welcome! Thanks, Brian.

Thank you! That's actually a better template than the one I've been using. My solution was to draw a grid of lines (see attached pic), and then I fill in the cells with the color I want for that pixel-- but then I still have the grid of lines overlaid on the mockup! With your template, you can fill each as desired pixel without having to worry about a grid. (Although sometimes the grid comes in handy, since it makes it easy to identify the individual pixels when there's a bunch of same-colored pixels together in an area. Michael Anytime! I tried using the grid in Photoshop, but it only allows grid quadrants that are equally sized. So I just created a checkered pattern and applied to the entire screen. The only drawback is that you can snap the pixels to the grid, but I can live without that. Just be careful to fill in big areas. Having too many layers will kill your Photoshop after a while.

Thanks, Michael. I've set up a new template that uses your Width, Height, and Pixel sizes. I've attached my template, in case you need it. -B I also re-created my game screenshot using your measurements. Check it out here.

Created a revised screenshot based on the size SeaGtGruff provided (thanks again!). The screenshot shows Jumpy, a Jump PowerUp, and a wall, as well as small, medium and large sized platforms. I also included the name of the game and the score along the bottom. Again, not sure if what I have created is feasible, so any feedback/thoughts are welcome . If this is doable, I will create some more screenshots showing a door and unlock platform. -B

Thanks, Michael. I've set up a new template that uses your Width, Height, and Pixel sizes. I've attached my template, in case you need it. -B

I am looking to comp up some screens using Photoshop for a game idea I had, and was wondering if there was a standard width and height (in pixels) that should be used. I know there's no accurate translation, since the 2600 leverages scanlines and color clocks, but I have seen 192 x 160 pixels thrown around. If I could use the 192 x 160 resolution, would it be okay to double that while doubling the pixel sizes as well? Again, these are just for comps, but I want to try and make them as true to life as possible. Thanks in advance Brian