sponsors gamedev.net search:

Building the Map While I was doing all this reading, I kept myself busy with a simple project that consumed plenty of time. I needed a map of the world that I could fit into the Mac's 512x342 screen. Nowadays we'd just scan something in, doctor it a bit, and voila!—there's our map! Unfortunately, we didn't have scanners back then, nor did we have photo manipulation programs. Besides, I needed more than just an image; I needed a digitized map with individually addressable countries. In other words, I needed a data structure for each country that defined its boundaries. I had to have graphics of each and every country in the game. My solution was simple and straightforward. I placed a wall map of the world onto the floor and taped semi-transparent graph paper over it. I then traced the borders of the countries onto the graph paper, conforming my tracing lines to the gridwork of the graph paper. Then I pulled out my tape recorder and set to work. "Germany," I would announce. "Starting coordinates 189 X and 118 Y." Then I would launch into a long monologue tracing the border in directional steps: "One north, two west, one north, three west, two north, one west, four north..." and so on until my tracing of the border had completed the circuit of the country. Then I would move to the next country. When I had finished all the countries, I sat down at the computer and entered the data as strings. I'd type in the name of the country and the coordinates of the point of origin. Then I'd listen to the tape recording, typing in the steps: N2WN3W2NW4N.... As you might imagine, it was a slow and tedious process. This became the source data for my country images. During program initialization, the code read in all that data and converted it into manipulatable graphics objects. All in all, it took me about a week to create the map this way. In each project, do at least one special task by hand. I'm sure this primitive technique leaves you agog, half-expecting me to follow up with tales of walking five miles through the snow each day to get to school. But there's an important lesson here. The tool shapes the hand of the user; or, to use the more common expression, "If you've got a big enough hammer, everything starts to look like a nail." Nowadays we've got tools up the wazoo, tools to handle every aspect of game development. Many times, when a team starts working on a completely new project, the first thing they do is set to work building tools for the project. This is good, but it is possible to go too far with tools, as I pointed out in Chapter 8, "Common Mistakes." Memory Headaches In 1984, when I was working on Balance of Power, the Macintosh had just been released and was equipped with 128KB of RAM. This was twice what most computers had in those days, but I couldn't seem to fit the game into the available space. The graphics weren't the primary factor: they cost only about 15K. Part of the problem lay in the number of countries and the vast amounts of information I maintained about each country: the text strings for the country name, capital, leader, insurgency, and so forth. The code itself was also sizable, and of course, some of the RAM was taken up by the operating system. Before the Macintosh, programmers simply took over the machine and all its RAM. The operating system was really nothing more than a set of utilities. But the Mac changed all that. We cowboy programmers had to learn to live under the operating system, abiding by its rules and using its systems. It was hard on us; the same mentality that enabled us to succeed in the Wild West atmosphere of early personal computers now chafed under the rules and regulations of the Mac operating system. Many of the cowboy hotshots of the 8-bit era couldn't adjust to the new regime and dropped away. Fortunately, I was blessed with the intellectual and psychological agility to adjust to the New Order. Take no pride in facts memorized, but in ideas grasped. An important lesson lies buried in this experience. My advantage lay in an unorthodox approach to technology. Most technical people take a shotgun approach to technology, memorizing mountains of technical details. That huge heap of knowledge constitutes the expertise on which they build their careers. Since that expertise is their basis of competitive advantage, technical people, and especially programmers, take much pride in the size of the pile of facts that they have stuffed into their heads. This has the pernicious effect of rendering programmers insensitive to the demands that technology makes upon its users. Programmers revel in the arcana that torture users. But what goes around comes around; the mind that is stuffed with bucketsful of technological trivia becomes bloated and slow-moving; the inertia created by all that expertise retards further learning. Programmers are mostly young because they reach their mental capacity sometime after their 30th birthday, after which they ossify. My advantage I owe to my physics professors, who ground into my stubborn skull the single question, "What is the essence of the problem?" Always dive down into a problem and get your hands on the deepest issue behind the problem. All other considerations are to dismissed as "engineering details"; they can be sorted out after the basic problem has been solved. And so I have equipped myself with a bloodthirsty drive to purge all facts from my mind. If it's a principle, I want to understand it; if it's a fact, I want to forget it. Facts clutter the mind; ideas organize it. If I can fit a fact into the larger structure of my understanding, then I can retain it; otherwise, it slips from my mind like water from a steel cage. I can't remember names, faces, or telephone numbers, but I can absorb new ideas even into my fifties (although I'm starting to slip). © Copyright Pearson Education. All rights reserved. Making It a Game

Contents   Introduction   Early Efforts   Thank You, National Enquirer   Building the Map   Making It a Game   Printable version   Discuss this article