Jump to content
  • entries
    106
  • comments
    796
  • views
    140,737

So, you think you have a good idea?


Guest

762 views

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 :)

12 Comments


Recommended Comments

Pretty good, generally. A few things I'd mention:

 

-1- The playfield hardware holds half the screen. If the right half matches the left half (regular or inverted) it can be repeated for several scan lines without needing any more CPU time; if the right half doesn't match, it must be redrawn every line even if the data seems to repeat.

 

-2- CPU time requirements for the playfield can be eased considerably by striping it, or by only using the central 32 columns.

 

-3- It is possible to show different shapes or colors in the different copies of a sprite (this is now most games' score displays work) but it is very CPU intensive. It is generally only practical to do it for objects at fixed horizontal positions (like the chickens in Freeway).

 

-4- Objects may be inexpensively 'nudged' on a per-line basis. One may either nudge all objects -8 to +7 pixels left, or 0 to 15 pixels left. The former mode of nudging will blank the first eight pixels of the next scan line. Nudging may allow sprites to appear to be higher-resolution than they really are, and may also allow missiles to have 'interesting' shapes.

 

-5- When the playfield has its own color, objects will appear, front to back, in one of the following orders:

 

-a- Player 0 and missile 0 in front, then player 1 and missile 1, then the playfield and the Ball, then the background.

 

-b- The playfield and the Ball, then player 0 and missile 0, then player 1 and missile 1, then the background.

 

-6- When the left/right halves of the playfield share colors with the sprites, the object ordering is fixed:

 

-a- Player 0 and missile 0, then player 1 and missile 1, then the Ball, then the playfield, then the background.

 

-7- It is often possible to make tradeoffs between time, code space, and RAM requirements. It can be tricky to predict whether a given effect will turn out to be practical or not without actually coding it.

Link to comment

Hi there!

 

It can be tricky to predict whether a given effect will turn out to be practical or not without actually coding it.

 

Most important part, yes :)

 

Good document and good additions!

 

Greetings,

Manuel

Link to comment

I think this is a great idea! It will be a good place to point newbies when they come up with unrealistic 2600 game ideas (e.g. lemmings), rather than repeating the same arguments over again.

 

My only suggestion would be to make the description of the playfield a bit more detailed. There may be some people who would like to generate PF art for games without actually getting involved with the programming. In particular, I think you should indicate the actual layout of the reflected and repeated playfields, including the bit reversals, and a brief bit about symetric vs asymetric playfields. Also, you could mention that an asymmetrical reflected playfield which ignores PF0 is a very useful configuration!

 

Chris

Link to comment

I'd leave out "Screen Resolution; Base resolution is 160 x 192", because it's very misleading. In fact, I'd focus on the line-based aspect of 2600 graphics. e.g.

 

Each line of the active screen is made up of the following objects:

background colour

40 pixels of playfield

two 8 bit player sprites

two 1 bit missiles (same colour as the players)

one 1 bit ball (same colour as playfield)

 

You've gone into a fair bit of detail about player sprites, i.e. width & duplication, which probably aren't appropriate to the non-programmer. If you're simply trying to give them a flavor of what the 2600 is capable of, I'd leave out anything (other than playfield) which would require a precise mid-line updates.

 

You might want to mention the 48 bit player sprite possibility, although that basically uses the entire line. (No playfield updates.)

 

Oh, and that 192 lines per screen (NTSC) is just a recommended value. The active screen can easily be 200 lines or more, though you risk having some of the graphics offscreen.

Link to comment

Thanks for all the comments and suggestions. I'll try to add some of them in. And thanks for the link, Manuel. :)

You've gone into a fair bit of detail about player sprites, i.e. width & duplication, which probably aren't appropriate to the non-programmer.

I dunno. I think the prospective game designer should know things like that; the duplication especially can be very useful and is used in many high-profile games (i.e., Frogger, Freeway, Pitfall!, Stampede, Space Invaders, etc.) - and I don't think it's that hard to understand.

 

But, on the other hand, going line-by-line is probably a good idea.

 

Also, I'm hoping to add more info about sound, but I need to come up with something non-technical...

Link to comment
-6- When the left/right halves of the playfield share colors with the sprites, the object ordering is fixed:

 

  -a- Player 0 and missile 0, then player 1 and missile 1, then the Ball, then the playfield, then the background.

Is this true? When bit 1 of CTRLPF is set, bit 2 has no effect? Is this documented anywhere, or did you discover this through trial and error?

Link to comment

Updated the main post with a few of the suggestions and added an overview at the beginning. Still trying to think of more sound information to add.

Link to comment
Is this true?  When bit 1 of CTRLPF is set, bit 2 has no effect?  Is this documented anywhere, or did you discover this through trial and error?

 

I discovered it while trying to code a kernel for doing a 16-pixel-wide seven-color screen kernel (usable for puzzle games and such). The game puts player 1, 4x scale, on the left half of the playfield and player 0, 4x scale, on the right half. Using score mode, I can thus independently make each playfield pixel one of three colors. The Ball uses the playfield color register which is unused for anything else, so it gets to be its own color (makes a very nice cursor).

 

One fun little wrinkle is that because the player sprites are in front of the Ball, I have to turn off the pixel where the cursor is sitting or else it will cover up the cursor.

Link to comment
The Ball uses the playfield color register which is unused for anything else, so it gets to be its own color (makes a very nice cursor).

Now that's *very* interesting!

Link to comment
The playfield can appear in front or behind the sprites.

Does this mean that you could control the sprite even though it's not visible? I haven't played a lot of 2600 games, so I'm don't know if there's a game out there that allows you to "hide." That's kind of cool, though. I'm assuming the playfield is opaque.

 

Each distortion has a different range. The tones do NOT conform to the western 12-step scale

You mean 12-note scale. There's 12 HALF steps in the conventional Western scale. You disappoint me. :sad:

 

For this reason, composing music is hard, and playing existing tunes with the Atari is often impossible.

Improbable, not impossible. It just requires some imagination. Remember my idea for "Linus and Lucy?"

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...