[Seahawk]

This is the first of a series that will explain how game technology works an has evolved over the years, with a focus on the 'video' aspect-after all, a video game is not very functional without a screen to display on!

SPACE INVADERS is a game everyone recognizes as the first real smash arcade hit. It was so big it caused a coin shortage in Japan, and some people opened arcades with nothing but several Space Invaders machines. The game was as simple as it gets: shoot enemies, dodge bullets, and don't let the invaders land.

Two colors of awesome.

Wait a moment, what? This game is only two colors! Is that the best computer hardware at the time (1978) could manage?

Well, yeah actually, without costing a whole lot more to make. We'll even ignore the part where it was made by only one person (Tomohiro Nishikado). Let's see how this game accomplishes it's 'video' part.

What is a framebuffer, anyways?
The way a framebuffer works has changed a lot in the evolution of games. For our purposes here, it is a special section of memory that corresponds with what is directly displayed on the monitor.

Too confusing? Ok, think of it as a sheet of blank graph paper.

Pictured: Space Invaders

Each square is a bit of memory. Like an actual bit, each square has two possible states: empty or filled. The point of any video game (or any modern GPU) is to fill the right squares to give you the visual feedback you need to keep your squares from forming a giant GAME OVER in your face.

Still sounds easy? Fine, let's say I am the CPU of a new game called Space Invader. There is only one tank and one invader. You cannot move, and you can only shoot. My job is to draw everything on the screen. I have done my job and have created a 1:1 scale drawing of some objects in Space Invader on graph paper.

Pfft, who needs computers?

After drawing the picture, I have to decide whether or not that shot from the tank is going to hit the invader. Hmm, based on that trajectory I'm going to say that yes it did hit the invader. So now, I have to erase the picture, and redraw a new picture reflecting what has occurred.

Pew-pew!

And that's the basic flow of my game.

1. Draw the picture.
2. Decide whether the tank shot a bullet.
3. If there is a bullet, move bullet upwards.
4. If there is a bullet, decide if bullet collides with invader.
5. If there is a collision, erase the invader and the bullet and draw explosion.
6. Erase the picture.
7. Go to #1

Wow! You know, the decision making is pretty easy, but drawing and erasing and redrawing pictures is pretty time consuming. I would definitely hate to draw and redraw 5 rows of 11 invaders each, with three different types of invaders, and the invaders' bullets and my bullets and moving invaders and tanks and *gives up and throws paper away*.

You get the idea. This is hard work! And there's not even any color! I sure wish I had a way to speed up this process. But in the 1970s, this was all there was.

HAL: Who's laughing now, human?

This is how many 70s games worked (Gun Fight, Space Invaders + ripoffs/bootlegs, more). Process logic, make a picture of it, and spit it out to the screen. And let's go into numbers now.

Space Invaders has a CPU (Intel 8080) that runs at 1,996,800 Hz. (Some more informed readers may notice that that CPU speed is faster than the freaking NES) The game graphics are 260x224 pixels at 59.54 frames per second. Let's round that up to 60 for simplicity's sake.

260x224 = 58,240 pixels on screen.
58,240 * 60 = 3,494,400 pixels total to be drawn. Per second.

Well, that's more pixels than cycles per second. How on earth can we manage that?

Wait a second......there's a lot of black space at the top and bottom of the screen that doesn't need to be fill or drawn, ever. Let's skip looking at those areas. Hmm....and those words SCORE<1>, HI-SCORE, SCORE<2> don't need to change ever. Let's skip those too. And that lives counter and CREDIT doesn't need to change every frame, so we can skip those too (most of the time)!

Game development back then was all about finding shortcuts like these, anything to reduce the burden on the slow (relatively speaking) CPUs at the time.

But wait Seahawk, there were plenty of computer games before Space Invaders!!!

True, but most of those were run on very large university mainframes by bored computer students, who displayed there games on strange things like oscilloscopes and radar monitors. I don't even want to think about the black magic that went into doing that.

But what about PONG?!And many other earlier arcade games?
All right, fine, you win. I'll tell you some stuff.

Of course, Space Invaders was not the first arcade game ever. The earliest arcade game I can think of that uses a CPU is Gun Fight.

However, there were even earlier games that have no CPU. Games that have stored program ROMs and no digital components. Games that are just a bunch of resistors, capacitors, and wires planked together.

This is Pong. See a CPU there? I don't.

Not impressed? Here, have some schematics of a game called Space Race. Hope you have that degree in electrical engineering handy.

Pictured: Black magic.

See the FULL SCHEMATICS HERE. And while you're at it, here's a self-help guide to get you started on your own analogue game. And here's Atari's guide to servicing machines. More info on analogue games can be found here.


Of course, things didn't stay like this forever. Eventually someone had the brilliant idea of splitting off all graphics duties into a completely different device! And thus the Graphics Processing Unit was born. But that is definitely an article for another day.


So, I hope this article was informative on how the most ancient of games worked. If you learned something today, then it was worth it. Feel free to ask questions =).