Once the games were developed and reviewed for the gaming magazines, the next step in the journey to the customer was the retail store. In those days, most places that sold computer games were independent businesses, each with its own layout and personality. Kevin Hollingshead ran a branch of the Program Store, which was one of the first of these places to become a chain. They sold games for the Amiga and Atari ST as well as other platforms. One afternoon, Trip Hawkins (the founder of Electronic Arts) showed up in his store, after his records showed that the branch was selling more EA games than any other retail outlet. Trip told Kevin about his favorite games, as well as his master plan to make the Amiga a larger success and justify all the investment and enthusiasm that he had personally put into the platform. He had arranged tentative agreements from Japanese companies to make game consoles based on the Amiga chipset, as well as an "Amiga-on-a-card" for the IBM PC. It's difficult to predict what would have happened to the Amiga game scene had these plans become reality, but in the end it didn't matter as Commodore shot down both ideas.
Still, the Amiga game industry thrived as the 1980s turned into the 1990s. As developers learned more and more about the platform, the Amiga began to be known as the computer with the best games. Publishers would often put the Amiga screenshots on the back of the retail game box, even on the Atari, Commodore 64, and IBM PC releases, with the text "Amiga version shown" in tiny print below.
Uncovering the mysteries of game development
The tips and techniques required to make great Amiga games were not taught in any schools. Developers often started playing with the built-in BASIC on computers like the Commodore 64 and moved on to playing with assembly language. By the time the Amiga was released, magazines such as Commodore Gazette and MC MicroComputer contained articles that delved into the innards of the hardware.
Still, to really understand the power of the Amiga's chipset, there was only one reference guide that really mattered: Commodore's own Amiga Hardware Reference Manual. This was the Bible for Amiga game developers. It let dedicated explorers discover how the Blitter chip blasted graphics directly from memory to the screen, how the Copper let the programmer jump in and change the way the display worked even in the middle of scanning a line on the screen, how the audio chip offloaded sound processing, and how the CPU synchronized all these activities together.
The first thing developers would typically do when starting to write a game was to gently cut off the operating system in order to gain complete control of the hardware, including memory. This was done to save memory and so that games could squeeze every last amount of power from the custom chips. When the game ran, however, the developer was running without a safety net. There was no integrated development environment or debugger that could execute at this point. Clever developers would use the hardware itself as a monitor, sending signals to the Copper to change the background color at key points in the program.
When things went wrong, they went wrong spectacularly. There was no memory protection, so if one part of the program started to overwrite another, the screen could erupt in random fireworks before the system locked up. The only way to make sure the whole thing would work was to build and test specific routines for each small component of the game before starting on another.
Amiga game developers used many different tools in their work. To save on development time, many used high-level languages, mostly C. Popular compilers were Lattice C from SAS, Manx C, and DICE.
Still, for raw speed and power, you couldn't beat 68000 Assembly language. On early Amigas, memory was at a premium: the market consisted of machines like the Amiga 500 with 512 KB (that's kilobytes, not megabytes!) of RAM, split between "chip" (memory dedicated to the display and custom chips) and "fast" RAM. Getting everything to work smoothly, without flickering and at high frame rates, took a lot of mental juggling.
Consider the task of Cesare Di Mauro, developer of USA Racing. He wanted a target of 50 frames per second to retain a smooth experience, but this, combined with RAM constraints, meant that it was impossible to use double-buffering (a technique where a second screen with the next frame of action is stored behind the scenes in memory). Using a single screen saved execution time and memory, but made the task of scrolling the background and updating the BOBs (blitter objects, similar to sprites) much more difficult.
His solution consisted of a 352 x 272 virtual screen, with only 320 x 240 pixels viewable at any time. The area was divided into two vertical slices, combined to show a single view. The background consisted of 32 x 32 pixel tiles, arranged in a large map of 4096 x 65536 pixels (coders everywhere will recognize those numbers).
Juggling the number of tiles, the BOBs displayed on top, the music and sound effects, and collision detection with walls and other cars was a huge challenge. Cesare ended up writing a tool in assembly language that handled all of these at 50 frames per second, sorting drawable objects into a display list to maximize performance. The program would first display all BOBs in-order on the list, then update hidden areas to handle scrolling (horizontal scrolling was handled by the graphics chipset by setting a scroll register value, while vertical scrolling was similar but more complicated), then waited for the monitor's display beam to reach the bottom position of each BOB to restore the background they had "stained." He wrote custom routines for sound and even disk access to maximize speed and minimize RAM usage.
This sort of careful balancing was typical of game programmers who wanted to push the envelope. Many of the concepts they came up with would be recreated as part of industry standard libraries much later—display lists, for example, are a crucial element of Direct3D.
reader comments
136