csanyk.com

My friend Sam recently asked the internet if there were any books on early arcade game aesthetics. I’m not aware of any books that particularly stand out as being focused on game graphics, so I didn’t have any titles to suggest, although there are starting to be quite a few really good books on the history of the arcade.

To help him out, I brainstormed as much as I could, and since I think this ended up being pretty valuable, I figured I’d turn it into a blog post.

Basically every design principle in the graphics of early 80’s arcade games was governed by the insane limitations of the tiny systems of the day. Memory was SUPER expensive, 16k of RAM was a LOT in the late 70s/early 80s. CPU was 8 or 16 bit and SLOW – 1MHz or so. At the time there often wasn’t a dedicated video processing unit, or even dedicated video memory — everything was handled by the CPU, which often dedicated most of its processing power to simply drawing each frame of video, leaving relatively little processing power left over for handling game logic.

Here’s a list of qualities and factors that fed into creating the early 80’s aesthetic:

• Portrait aspect ratios. Most of the old games, particularly vertical scrolling shooters, had monitors mounted in the cabinet in Portrait orientation (3:4 aspect ratio, as opposed to 4:3 ratio). Portrait gave vertical shooters more range to fire, and enabled manufacturers to build narrower cabinets, which allowed them to store, ship, and display more units in a given area.
• Large pixels. The dot-pitch of those old screens was pretty coarse. You might have had a 15-, 17-, or 19-inch screen displaying 320×240 resolution, or even 240×160. Individual pixels were quite apparent, particularly in the late 70’s. Macro lens photos of the screen would reveal visible gaps between pixels. Early home computer monitors were capable of displaying a mere 40 or 80 characters of text, and the screens were tiny — 13″ or smaller.
• Tiny sprites (usually 16×16 or 32×32 max)
• Animations typically limited to 2-3 frames, though there were sometimes exceptions. Each frame of animation in a sprite cost valuable storage.
• Bright colors and pastels. Here’s a great collection of color palettes available to home consoles and computers.
• Grid-based graphics. Most terrain, characters, etc. were sized to fit within a standard grid size. Terrain, mazes, etc. were generally built out of repeated tiles.
• No alpha channel. I don’t recall seeing any translucency (colors blending when two sprites overlap) in this era. Any transparency would have been all or nothing, provided by a mask. Before masking techniques became widespread, many early games had the background color drawn into the sprite, resulting in artifacts when two sprites would overlap.
• Limited color palette. 2^N colors to pick from, where N <= 8. So, generally 256 or fewer colors on screen. The most common color depths were 1-bit (B&W) and 8-bit (256-colors), although there were a few notable grayscale games, such as Fire Truck. 8-bit color ruled in the arcade until the 16-bit revolution came to the arcade, around 1986-87 — the golden era (roughly, 1978-1984) of the arcade was exclusively B&W, and 8-bit.Oftentimes, computers of the day had a pre-defined color palette and were further limited by the number of distinct colors they could draw on the screen at any one time, such as out of a total of, say, 4096 possible colors, which were baked in to the hardware and could not be changed, and you can only draw 16 (or 64, or 128) of them on the screen (or, in some cases, up to 4 colors in any one sprite) at any one time. If you want to emulate specific hardware, it’s a good idea to research the capabilities and narrow your color selection to match the authentic palette of the original hardware. These limitations often resulted in workarounds such as dithering (drawing two colored pixels closely together to allow the eye to blend them to a middle value). Here’s a fascinating article about the Commodore 64, describing a technique for getting “secret” colors to emerge from the C64’s limited palette by rapidly switching between two colors in the palette to synthesize a new color. It also meant that smoothing your images with anti-aliasing wasn’t possible, because there weren’t enough available colors to do proper tweening. Jaggy pixels ruled the day. Many home computer games of the era did their graphics in Text Mode, which has its own distinct look.See also: MDA, CGA, EGA, VGA
• Palette swapped sprites. Old computers used color palettes, or indexed color. Out of a gamut of, say, 64 or 256 or 1024 or 4096 possible colors, a sprite typically could only use, say, 4 or 16 out of the 256 available colors. These four chosen colors were defined by a “palette”, and each color on the palette had an index value used to refer to it. By changing the colors in the palette to different colors, or in other words swapping one palette for another, the indexes in the sprite would be updated to use the new colors. Re-using and re-coloring the sprite, saved on storage space. A palette swap took a bitmap and re-mapped the values in each pixel to a different color from the new palette. This is why Mario is red and Luigi is green, for example. It was also very common to have different power levels of enemies denoted by using palette swaps.
• Blinking and flashing. Rapidly flashing colors as a cheap, eye-catching form of pseudo-animation.
• Flicker. If the processor couldn’t handle drawing all of the sprites on the screen in every screen refresh, something had to drop. So a sprite might not draw every screen update if there are too many on the screen, or too many in a horizontal scan line.
• Abstract, iconified representations of things, and cartoony drawings, as opposed to realistic drawings.
• Reliance on clichés, tropes, and popular idioms to help make graphics more easily recognizable, and a willingness to extend the idiom in a clever/absurd/zany fashion.
• Fruit and keys and things are canonical bonus items.
• Giant head/face, tiny body/limbs. They tried to fit the entire character into a 32×32 square, and most of the detail needed to go into the face/head to make the character recognizable and memorable.
• High contrast is important for foreground/background.
• Shigeru Miyamoto once gave an interview where he discussed why the original Donkey Kong sprites for Mario…
  • had white skin (the background was black, so they wanted strong contrast),
  • had a mustache (it helped his nose stand out and a mouth and chin were too complicated for the number of pixels left in the region)
  • wore red overalls/blue shirt (the overalls helped with the contrast of his swinging arms, which you otherwise wouldn’t get from a solid colored top.)
  • Wore a hat (his dark hair would have stood out less against a dark background, and presented problems with animation.)

Don’t forget vector!

Notable vector titles of the era:

• Asteroids was the first hugely successful arcade game that used a vector display. Note the intense glow of the UFO and missile in this image, due to the vector display over-drawing those lines many more times than the refresh rate of a raster scan CRT would have allowed.
  I’m not sure what the very first use of a vector monitor was in the arcade, maybe Lunar Lander?
• Battlezone When gamers of the area think about vector games, probably the first two titles they’ll think of are Asteroids and Battlezone.
• Qix Actually, Qix used a raster monitor, but it was primarily line based art, so I’m including it anyway for inspiration. Plus, it gives you an idea of how a line art game would look on a low-res raster display of the period.
• Tempest Tempest was the first color vector game, and was a sensation at the time of its release.
• Space Duel is one of my all time favorite games. It featured innovative 2-player co-op/competitive play, and awesome graphics.
  Note the distinct difference in this photo of an actual vector monitor screen photograph vs. how the game looks when emulated on a modern display:
  
• Star Castle An often overlooked classic, the arcade version Star Castle used a color overlay over a monochrome vector CRT:
  Later cabinets made use of a color vector CRT display, and looked much better:
• Star Wars (really impressive achievement vector graphics, actually — convincing 3D, accurate wireframes of familiar star fighters from the movie, simulated fills, etc.)
  

There might be other notables that I’m forgetting, as well, but these should have you pretty well covered.

Color vector screens were something rare and expensive, most vector games were B/W or monochrome (green or amber). I believe before proper color vector monitors became cheap enough, some vector games may have made use of cellophane overlays attached to the screen which filtered the vector image painted on that part of the screen to make it appear colored.

When you DID have colors, they were very bright colors, almost always primary colors (RGB).

The way the vector monitors worked:

• There are no pixels (not easy to emulate, but maybe the retina display on the new iPhone/iPad can help make this more convincing?) This meant no aliasing or scaling artifacts.
• A->B, not scan lines. The cathode beam was drawing from A to B for each line segment, not drawing scan lines from top to bottom.
• Bright and sharp. As such, a vector display could spend much more time drawing each line segment, far faster refresh rates than the 30Hz that is typical of pre-HDTV raster CRTs. Unlike a raster CRT, there was not a fixed refresh rate; the cathode beams traced over the line segments as quickly as they were able to. This resulted in a very bright, flicker-free vector line (again, not easy to emulate) compared to the brightness of a white pixel on a raster display. There was often some ghosting as the intensely bright phosphor dimmed after the object on the screen moved. This was a hardware artifact, not something programmed in to the graphics routine as a special effect. Vector displays GLOWED and were sharp and gorgeous.
• More stuff to draw means dimmer lines. This also meant that the more stuff being drawn on the screen at once, the overall brightness of each individual line was diminished, ultimately resulting in visible flicker if too many things were being drawn at once.
• Even brighter vertices. Where line segments intersected, or at vertices, the beams additively excited the phosphors resulting in an even brighter point at the corner in relation to the brightness of the rest of the line segment. We’re talking REALLY excited phosphors!
• Geometric shapes and polygons, not curves. Curves would have required far too much computing time to calculate precisely. Curves were always approximated with line segments. Linear functions are way faster than polynomial and trig functions, and the processors of the day didn’t even have dedicated floating point units (FPUs).
• (Usually?) a single line thickness for all graphics. I can’t think of any vector games where the line thickness varied, but it’s possible there may have been some. Typically the lines were quite thin, like pencil lines.
• No fills. Everything is a wireframe — maybe a simulated fill by drawing in a bunch of lines in a pattern. Fancier 3D games would occlude line segments that were “behind” the surface of some other object, but a lot of them just let you have a kind of x-ray vision effect where you could see through the wireframe.
• Black background. You can have any background color you want, as long as it’s black.
• Favorable to 3D. These properties made 3D games much easier to draw in vector than for raster graphic displays of the time. So a lot of the early 3D experiments were done with vector displays, most notably Battlezone.

Further reading

• Designing 2D graphics in the Japanese industry