Search the Community

SO YOU WANNA DESIGN VIDEO GAMES, HUH?There is lots of programmer-oriented documentation for the budding 2600-coder, but not a lot for someone who doesn't want to code for the beast but still wants to know, in a somewhat non-technical way, how it works. Plus, lots of people think they have the bomb idea for an Atari game but they have no clue what will and won't work with the 2600 hardware.So, for them, I presentSo you want to be a game designer? How to design an Atari 2600 game.Updated!Note that this is designed for the NON-programmer, though it might be useful to someone just beginning to program the 2600. It is for all the folks who have a great idea and want to recruit a developer. READ THIS FIRST, make sure your idea is doable, then make some accurate mockups. You will be the recipient of less snickers that way. GraphicsOverviewFirst, the Atari 2600 has one graphics "mode." It has no character or tile modes; if you want characters (letters, numbers) you have to draw them yourself.Second, the Atari 2600 has VERY little video memory. Specifically, it has enough memory for one line of the screen. The Atari will keep drawing whatever is in its memory on every line, forever, until it is told to do something different. This can be helpful; if you want to draw a vertical line, you can tell it to put a dot at the left edge of the screen and it will draw that dot on every line without further instruction, creating your line. But, generally speaking, to get graphics more interesting than lines and rectangles, you have to change video memory on a line-by-line basis. In other words, as soon as the TV is done drawing one line, but before it begins to draw the next line, you change the video memory. As you might imagine, there isn't a lot of time between drawing one line and the next - to be specific, there isn't enough time to change all of the video memory. You can't change the color and shape of all objects every line, you have to pick and choose which to change. That's the tricky part!Colors128 colors, 8 shades of 16 colors. Check out a handy chart.Screen ResolutionBase resolution is 160 x 192* - this is somewhat misleading and kind of useless, since the 2600 doesn't have a bit-mapped display. So if you must know the maximum resolution, there it is, but the really useful thing to know is the resolution and size of the individual graphic objects.*The actual vertical size of the screen can vary depending on many factors, including what TV standard you are using. 192 is kind of the standard, though anything close to 200 (+/- 10) is fine.2600 Graphic ObjectsBackgroundJust what you think it is. Can be any of the 128 colors. That is its only property. The color can be changed on a line-by-line basis.SpritesThere are five:Two 8 x 192 "players"Three 1 x 192 "missiles" (Technically, two missiles and one "ball".)Each player can have any of the 128 colors assigned to each of its horizontal lines (not pixel). Each player has an associated missile, which is the same color as the player on that line.The other missile, called the ball, has its own color, which can be changed on a line-by-line basis.Each player's pixels can be normal width, double width (twice as wide), or quadruple width (four times as wide). This applies to the PIXELs; the players still have dimensions of 8 x 192 no matter the width of the pixels.Each missile is one pixel wide. That pixel can be as wide as one standard pixel, as wide as two standard pixels, as wide as four standard pixels, or as wide as eight standard pixels.Each player-missile combination can also be "duplicated," into these arrangements:Two copies, close The player will have a second copy positioned to his right, with 8 pixels separating the two copies.Two copies, medium The player will have a second copy positioned to his right, with 24 pixels separating the two copies.Two copies, wide The player will have a second copy positioned to his right, with 56 pixels separating the two copies.Three copies, close The player will have a second and a third copy positioned to his right, with 8 pixels separating the 1st copy from the 2nd and 8 pixels separating the 2nd copy from the third.Three copies, medium The player will have a 2nd and a 3rd copy positioned to his right, with 24 pixels separating each copy from his neighbors.Players cannot be double width or quadruple width while they are duplicated.Each player's missile will have the same number of copies and the same spacing as the player. Missiles CAN be duplicated AND widened at the same time.The third missile (the "ball") cannot be duplicated.All width/copy properties can be changed on a line-by-line basisStatic ObjectThe static object, used to draw floors, walls, etc., is called the "playfield."Resolution of playfield: 40 x 192. Each playfield pixel is the width of FOUR standard pixels.Can be any of the 128 colors. That color can be changed on a line-by-line basis (NOT pixel-by-pixel).May be mirrored left-to-right or duplicated left-to-right. Examples:Mirrored Example:123456789987654321Duplicated Example:123456789123456789The playfield can appear in front or behind the sprites. The playfield can forgo an independent color and have its left half take on the color of the first sprite (on that line) and have its right half take on the color of the second sprite (on that line).The third missile, called the "ball", is associated with the playfield and will have the same color as the playfield on a line-by-line basis.All playfield properties can be changed on a line-by-line basis.SoundThere are two channels, each independent of the otherEach channel can play a sound in one of 16 voices (called "distortions").These distortions range from pure tones to sort-of white noise, with several variations in-between, including several that are more-or-less suitable for percussion sounds.Each channel can play one of 32 tones in each distortionThese 32 tones range from too high to hear to too low to hear, with infrequent steps in-between.Each distortion has a different range. The tones do NOT conform to the western 12-step scale. They don't really conform to any scale. For this reason, composing music is hard, and playing existing tunes with the Atari is often impossible.Advanced NotesHow to get more sprites onscreen at onceEach sprite can be resused on the screen, but he CANNOT BE REUSED ON THE SAME HORIZONTAL LINE. In other words, a particular sprite can be used on the top half of the screen and the bottom half.There are many many examples of games that reuse sprites down the screen. Freeway, Go Fish!, and Stampede! are some of the more obvious examples. This can be done more subtly, like in Berzerk.The other way to get more than the stock 5 sprites on the screen is to "flicker." This is where you display one sprite in one place, use the same player to display another sprite in a different place the next time the screen is drawn, and repeat. Games that use flicker: Asteroids, Adventure, and a billion others.Timing Constraints - or, Why You Can't Do Everything At OnceThe 2600 has only enough video memory for one line on the TV screen. To display more than one line of graphics, you have to manually change the contents of the video memory AFTER it is done drawing one line but BEFORE it begins drawing the next line. This is not a long time; you can't change all of the video memory every line.Here's the amount of time it takes to draw each object:Duplicated or mirrored playfield: 1/3 of a lineNon-duplicated/non-mirrored playfield: 2/3 of a linePlayer: 1/3 of a lineMissile: 1/6 of a lineChange color of any object: 1/10 of a lineSo, to draw both players, both missiles, and the ball (the other "missile") that would require 1/3 + 1/3 + 3/6 = 7/6 of a scanline. In other words, you can't do it. Plus, you still don't have time to change the colors of anything or draw the playfield! Is there a solution? Yes, there is.Here it is: if you draw something, the Atari will continue to draw that object, with the same shape and the same color, again on the next line and the next and the next and the next...forever until you tell it to stop.So while it would seem that drawing both players and all three missiles will essentially take the entire line and there will be no time to change colors of anything or draw any playfield, there is a way out!Draw one player on one line, draw the other on the other line, spread the missiles out similarly across two lines and you have two lines in which to get your business done. This will give your objects effective two-line resolution, which will look blocky.Other ways to draw more things at once:With a reflected playfield, not using the outer (left and right) edges will gain a little time. See Donkey Kong, Go Fish! for an example of this.Striping the playfield will also gain you some time. See Crazy Balloon, Thrust+, and Dig Dug for examples of how this looks.BIG spritesWith clever use of sprite duplication and precise timing you can get sprites that are between 9 and 48 pixels wide.These are very CPU-intensive to draw, however, so they usually have to be static and very little else can be displayed on the same line as these large sprites. For examples...see many, many games. Donkey Kong, Bump 'n' Jump, Pitfall!, Venture, and many others use this technique to draw the score. Dig Dug, Defender II, Thrust+, Xenophobe, and many others use this technique to draw a fancy title screen.Special note on reusing spritesRepositioning a sprite (in order to reuse said sprite somewhere on the lower portion of the screen) takes almost an entire line of computing time; only 1 or 2 other objects can be drawn while repositioning. Also, only one object can be repositioned at a time.Special note on soundSpecial techniques exist in order to get sampled sound and 3+ channel sound. These techniques are so CPU-intensive that they generally require that the Atari only be aksed to draw a blank, or very very simple, screen while the special sound/music is being played. They are also very memory intensive, which brings us to...Technical NotesThe Atari 2600 has 128 bytes (no, not KILObytes; no, not MEGAbytes; just plain ol' BYTES) of RAM. If you are planning a baseball simulation and you plan to track every player in the league's batting average, think again. Generally, between 10 and 60 of those bytes are needed to draw the screen, depending on the complexity of the display, leaving between 60 and 100 of those bytes for other use. Keep this in mind!A 2600 cartridge can hold between 2Kb and 32Kb of read-only memory (ROM). Yes, those are KILObytes. Things that chew up ROM very quickly: music (especially samples or other special sounds) and high-resolution graphics.Helpful? Did I make any errors? Thanks for reading

YOU WANT IT? YOU GOT IT. Several people have expressed a desire for a true arcade pong on the 2600, most recently here: http://www.atariage.com/forums/index.php?showtopic=76696 Well...I decided to code it. Sort of. The kernel, anyway.Check it out. apong.bin APONG_source.zip Use paddle 0 and paddle 1 to move the, uh, paddles. I probably won't take this project much further but maybe someone else will. Anyway, that's why I attached the source.

ARKANOID 2600? Next up, my flier for an Arkanoid port to the 2600.Let's see...July 18 2005 looks like the latest source I have.Here's the latest, buggy, binary: It also has a thread in the homebrew forum.Here's a screenshot:Judging from the date on the latest source I have, I last worked on it January 21st of this year.Here's a screenshot:Status of this project:Preliminary, working kernel written, with 15x16 brick playfield, two larger balls, two (flickering) enemies, and a paddle-controlled, uh, paddle. :)Current version supports two kinds of bricks: breakable and unbreakable.I think I have a reasonable way to implement three kinds (unbreakable, breakable with two hits, and breakable with one hit), but it would require rewriting the kernel. And I'm not entirely sure it would work.Collision detection is buggy as hell.Second (and third) ball not moving.Ball-to-brick collision detection, besides not working, takes a LOOOOONG time. Implementing for three balls may not work because it takes so damn long.Needs a TON of work before it even has one playable level, let alone being an actual game. As an example, the (non-working) collision detection is hard-coded for only one level.Reason I stopped working on this:I needed to stop dinking around and focus on getting M-4 completed for the mid-August show.I didn't, and still don't, have a solution for the collision problem (specifically, how to do it faster).Pretty much everybody who commented on the project wanted:1. bigger balls :ponder:2. three balls :ponder: :ponder:3. bricks that took multiple hits to breakI got 1 and 2 mostly implemented, but not 3, though I have since figured out a way to do it that I think would work (involving a 256-byte table).Pros of this project:Judging by the response to the trial balloon I floated in the homebrew forum, lots of people would be very enthusiastic about it.I'm pretty sure I could get a kernel that had three large, breakout-style balls, three types of bricks, two enemies, the floating pills, and a paddle-controlled paddle.I like breakout-style games.Having a screen-designing contest would be very cool.Cons of this project:Having a bunch of people looking over my shoulder and comparing my work to the million other versions of the game might not be the most fun in the world. :)I like Arkanoid, but it isn't my favorite game in the world. And, I really *don't* like the enemies in it - a bunch of twirling geometric shapes? Boring!I like this project, but I just can't seem to muster up a lot of enthusiasm for it right now. Of all my tentative projects, it is and would be by far the most popular. So I dunno.

...AND IN THIS CORNERSo...what to do, what to do? What should be my next project for the 2600?So far, I've completed Go Fish! and Go Fish! 1K. M-4 is essentially completed; mostly I am waiting for an inspired idea to fill up the almost-1K of ROM I have left.I've begun too many projects. They are, in sort of chronological order:Running Man: a horizontally-scrolling platformer. This was my first (probably too-ambitious) 2600 project - I stopped work on it for two reasons: I didn't know how to make a bank-switched binary and I ran into an issue with collision detection that I'm still not sure how to solve.Arkanoid: a port of the arcade original. Stopped work on it because I needed to devote time to finishing some other project...Go Fish!? Or M-4? Also ran into an issue with collision detection that, also, I'm not sure how to solve.Untitled Legend of Zelda Clone: Interestingly enough, a sort-of horror western. Interesting because I picked this theme before reading the thread about underrepresented genres in the 2600 library (which seems to have come to the conclusion that the most underrepresented genre in the 2600 library is the zombie-western ). I'm kind of half-heartedly working on this; I thought I had a kernel that would work, but then I realized that it had some issue that I'm not sure if I can live with. This one is a good candidate for a supercharger game - but unless it can be released on a cartridge, my motivation for doing a SC game is pretty low, despite the prize money. Untitled 1K Minigame: A simple concept. You are trapped in a dark room that has a flickering candle in each corner. It is dark elsewhere in the room. A series of "ghouls" are trying to kill you, one at a time. Each time you kill a ghoul, another one materializes in the corner. You can only see the ghouls when they are in the light (i.e., in the corner). Another complication - you have a projectile weapon with which to kill ghouls but, after throwing it, you have to go pick it up before you can throw it again. I took a 3-day vacation with my family and in-laws over the weekend, during which I didn't work on any code nor, really, think much about 2600 projects at all. Upon returning to normal life, I find that my motivation to continue working on this game is lacking.So, which one should I push through and finish? Or none of them; something else?EDIT: I forgot all about Cosmic Guerilla: A port of the 197x arcade classic. Not really interested in further work on this because: it is in an overloaded genre on the 2600, and is only 1% different from others in the library, IMO.