The Scrolling Map

LESSON 39

Other people can't see your vision; you have to make it happen yourself.

I was busy working on Scram at that time, so progress on the scrolling map was slow. I was also helping outside software developers with their needs for technical support for the Atari hardware. In November of 1980, I was promoted and given the task of setting up a group that would provide technical support for external software developers. I immediately began approaching software developers in the Bay Area, giving them photocopied documentation, software demonstrating how to take advantage of various features of the Atari computers, and so forth. Despite the clear superiority of the HCS, many programmers had a strong emotional attachment to the trusty old Apple II, which they knew inside and out. The scrolling map demo was the most powerful demo I had. Programmers' eyes would bug out when they saw that. Even then, though, some people just wouldn't budge from their loyalties. I especially remember a visit to a wargames company. As the piece de resistance, I dangled the scrolling map demo in front of their eyes, and enticingly suggested all the new possibilities this could open up for wargaming. But no, they were too wedded to the Apple II. They were building real wargames, not childish videogames.

I was deeply disappointed by their rejection; it seemed that nobody was willing to develop this wonderful technology into a game. Very well, I decided, if nobody else will accept this challenge, then I shall have to do it myself. I would build a wargame using scrolling map technology.

During December 1980, I began serious design work. I refrained from putting fingers to keyboard or pencil to paper; I wanted to get a clear vision of the game before I plunged in. I took many long walks alone at night, considering the fundamental properties of the game. Above all, I concentrated on the player's experience. What should it feel like to play the game? Would it be a complex logical problem? A matter of recognizing weak spots in the enemy line and exploiting them? What should the pace be like: fast and clean, or slower and more deliberate? All through December I mused over the game, and then in early January, I put my ideas down on paper in a single-page design document.

Eastfront Game Preliminary Description

Map: 64x64 squares

Unit count: 32 German corps, up to 64 Russian armies

Time scale: "Semi-time" of one week/turn. German enters moves for the next week (meanwhile, computer figures Russian move). When player is ready, play proceeds in real time.

Human interface: Map window on screen. Joystick input scrolls map and players. Putting unit under crosshairs activates it and orders arrows show. Then holding down button while twiddling joystick enters next order. Arrows (player-missile graphics) pop onto screen showing orders. Space bar clears orders. Releasing button resumes scrolling.

START button starts turn.

Colors:

Background:	Brown
PF0:	Green (forests)
PF1:	Blue (rivers, lakes, seas)
PF2:	Grey (German units, cities)
PF3:	Red (Russian units)
P0 P3:	Pink (orders arrows)

[Not enough color! Use DLI's or time-multiplexed color.]

I worked on my game at home on nights and weekends; I enjoyed the work because my work at Atari involved less and less programming and more and more management issues. It was pleasant to concentrate on the simpler problems of programming rather than the messy personnel issues that crowded my days at work.

The end result of this work was a beautiful scrolling map (see Figure 18.1).

18.1. Eastern Front (1941) screen display.

Once I had a scrolling map, I needed some military units that could move around on the map, so I went to work on those. After a month's time, I had units that I could select with the joystick and give orders to; not much later they were executing those orders, marching all over the map.

I had all the mechanics necessary for a wargame, but this program was by no means a wargame yet. It needed two major components: a combat system and AI for the computer player.