IAN'S QUEST

by Ian Chadwick

Ian Chadwick is a technical writer and editor living in Toronto. He is the author of Mapping the Atari, the 8-bit reference guide, published by Compute! Books. He is currently writing a computer simulation to "put his money where his mouth is." He can be reached on DELPHI by sending mail to username CHADWICK.

The other day I was sharing a few pints of home brew with a couple of old friends, both of whom have been computer users since the late 1970s. We were reminiscing about the "good old days" back when we first got our machines. Tom and I began with the TRS-80, back in 1978. Bill and I went on to Atari 400s, then 800s in 1983; Tom went for the Apple II about the same time.

Today, Bill and I have STs and PCs, Tom an Atari XE. We three bought our computers for much the same reason: to play and eventually design intellectually challenging games.

Tom and I started with 16K of RAM—considered to be an enormous amount of memory, since the computer had only recently evolved from 4K. The competition, the Commodore PET, had only 8K at the time. There was also a built-in BASIC which meant all of this memory was available for programming. A lot of amazing software was designed to run in a mere 16K, a lot of which has not been improved upon in megabyte-size systems. I was among the first users in my neighborhood to purchase the notoriously unreliable TRS-80 expansion box, which added another 48K RAM; 64K was simply staggering. Why, you could put a whole universe in there!

Aside from learning to program, we played a lot of games in those days. There weren't many arcade-style games around, although a company called Big Five Software produced some truly delightful efforts, especially given the limited graphics capability of the TRS-80. Most of what we played was written in BASIC, which meant we could usually break into the program and hack away at the code when we wanted to tinker. And we tinkered a lot. We whiled away hours discussing the effect of changing a particular variable, of adding subroutines and of altering code. Some of our proposed changes sent us to the library for days of research just to prove a point. We had access to the program source code, so we applied ourselves to mastering it. In the process, we learned a lot about programming, simulations and games. There were few games we didn't alter in one way or another.

By far, the majority of the games that we played and enjoyed were simulations, more or less, in game form. Most made little, if any, effort to include graphics or sound and were generally text-only display and input. And they occupied us for hours and hours of competition, play and enjoyment. Among these were Santa Para-via, a game about ruling a medieval kingdom; Taipan, a trading game in the 19th Century Orient; and Colony Omega, about building and running a space colony. There were games about running businesses, managing a sawmill, guiding tankers through the straits of Valdez, simulations about pest control, rat populations and buffalo herds. I loved them all. I used to subscribe to a magazine called, Softside, which printed the BASIC listings of these and similar games or simulations. For years, it was my favorite magazine. It was also one of the first publications where I got an article printed.

By today's standards, they appear boring, even simplistic. We've come to expect slick mouse or joystick input, fanciful sound effects, stunning graphics. The thought of a simple, text-only game with limited keyboard input fails to stir the imagination of many users who were introduced to computers through more state-of-the-art designs. Sure, they were stripped down to the bare essentials, but a lot of these games were more involving and enjoyable than many of the more recent efforts I've encountered. They demanded thought, planning and strategy.

Graphics and sound effects are chrome. Many developers and designers use them to mask an essentially dull game. Take a look at Defender of the Crown: lots of amazing graphics, nice sound, but essentially a pretty skimpy game underneath. The joust sequence consists solely of attempting to position the cursor (the tip of your lance) in the middle of a moving target (the opponent's shield). Ho-hum. The sword-fight sequence, when you attempt to rescue a maiden from her kidnapper, is a push-me-pull-you game requiring less skill or talent than perseverance in the mouse-clicking department. The economic sub-system is limited solely to buying and allocating weapons or soldiers. The strategic game consists of plodding about the country trying to grab the few territories before the computer grabs them all, something I've failed to do. Somehow, with about the same number of territories, the computer manages to field an army of some hundreds of men to my 20 or 30. Of course, I get beaten every time.

The idea of Defender of the Crown and the equally uninteresting game, SDI, is to create games with movielike scenarios which culminate in a defined plot ending. Sounds good, but they put a lot more effort into the chrome than the meat of the game. The marginally connected segments are too simple and too limited to provide long-term appeal. Instead of a coherent game, you get a hodge-podge of bits and pieces, none of which is particularly interesting.

Not to say, of course, that every game needs to be an intellectual roustabout, but its longevity depends on being able to provide continuing levels of interest and challenge. Straightforward arcade games may sell well initially, but like TV sitcoms, they quickly lose their audience. How many people would buy Asteroids again? Or Lunar Lander? Frogger? Missile Command?

Okay, sure, when the first two were combined and dressed up again in Oids, a lot of us bought it. But would you have bought them by themselves without the enhancements Oids gives them? Didn't think so. Think about all those shoot-em-up games you bought in the 8-bit world that nowadays you only feel disdain for.

The challenge of racking up just another 1,000 points in Goldrunner, or reaching just another level in Sentry, fades after a while. It's not much of an accomplishment to engrave your name in the high-scores list on your disk. Unless you're a serious couch potato, you can't play these games indefinitely. They are, in the long run, boring. They don't teach and you don't learn from them.

A few hours entertainment is a low return for the price: Up here in Canada, the average game sells for about $50. Even at $30, it's hard to justify buying a lot of variations on the same cosmic-froggy-space-zapper theme. The market has only a certain capacity. On the other hand, a game like Empire offers a lot of bang for the buck, so to speak. I've probably spent more hours playing Empire than any other game for the ST Bill, who bought the game on my recommendation, has become an Empire addict, and it's become difficult to pry him from the computer when he's playing it. It's not really a simulation in the same sense as those I mentioned, but it does make the gray matter work.

The simulations we played in the old days were usually written by people like us; hackers, tinkerers, self-taught programmers. It seemed that, if you had a computer, you learned to program. Maybe you didn't write programs, but you learned to change other people's code. Today, despite an abundance of languages, including some excellent offerings like GFA BASIC, there seem to be fewer hackers. The percentage of users who program appears much smaller than it once did. More people seem to be passive users than active. In discussions in computer stores, my question "Do you program?" creates a response similar to that as if I asked, "Do you dive for pearls?" especially among the younger users who see the machine as a toy rather than a tool. There is a disturbing perception among a lot of people of the ST as a game machine. I'd rather see it as a learning tool.

That's too bad, really. BASIC is an easy language to learn and very satisfying to work in because an interpreted language provides instant user-gratification: The results of your efforts are seen immediately. A two-step language like C or Pascal demands that you write code using a text editor, then compile and link it before you see anything. I personally dislike this process. Besides, GFA's compiler adds the advantage of being able to create fast, machine-language code from your finished efforts.

So what's the point? It's a call for submissions, for more effort in the area of simulation. I'd like to see a lot more of this sort of game grace the pages of ST-Log. I think readers learn a lot more by hacking away at a simulation than they do trying to alter an arcade-style effort that has little, if any, real leeway for change. Adding a single variable to simulate the effects of a disease on a stand of trees to Timber Baron had a wide-ranging impact that altered play completely. You just can't make that sort of impact in Droid or something similar. And the impetus to hack—and therefore learn—is lessened knowing you can't make significant alterations without seriously rewriting the code.

Back in the Jurassic period, around the time when I was learning to use my new Atari 800, I worked for Canadian Press, selling a high-level online historical news database You could search through news as recent as yesterday for specific topics of interest, for people, for companies, for words that might appear in a story.

I learned that an enormous volume of news never sees the light of print, due to restrictions on space or interest. Who cares about the government of Andorra? Or about a new dinosaur find in Montana? About the fiscal deficit in Zaire? The development of a new type of copy-proof gambling chip? I did and still do. It was fascinating to read the hitherto unknown news from all over the world. Since it all interested me, I spent hours on the system, which sold in those days for an online fee of $90 an hour. As the salesman, it was free to me, of course, and I took advantage of it to increase my knowledge, whenever possible. But the system was a trifle rich for my blood once I left the company.

Now, a similar system is available in ST XPress. XPress is a data feed with news, sports, finance, stocks, weather, recipes, quizzes, gossip, lifestyles and other material, transmitted over your television cable. A lot of this material is never printed in your local newspaper or gets airtime on the abysmally truncated news the radio and TV present.

A special decoder hooks up to your ST's serial port. You must subscribe to the data service and either buy or lease the decoder in order to use XPress. The rates are very reasonable for the value received. The software to capture the data and select material from the feed was written by Alan Page, co-author of Flash, my favorite telecommunications program.

Press software was originally available for the IBM PC, but when Alan took on the job of writing the ST version, he decided to make several improvements. As a result, ST XPress is considerably more flexible and powerful than its PC cousin.

XPress isn't a historical system: It presents the up-to-the-minute news, with stock and commodity data, from the Standard and Poor's Portfolio, delayed by a mere 15 minutes. Stories are saved in memory and can be recalled or saved to disk. There's a lot of news that comes through and many stories are duplicated in a day, so Alan's software provides the ability to selectively limit what you receive by selecting only certain categories to save. There's also a keyword search through stories in memory, to help further in finding items of interest from stories in the chosen categories.

By far, the most powerful feature is the clipping folders. These permit saving stories using Boolean logic operators, OR, AND and NOT. The default is OR, but you can specify stories in which only certain words appear together (AND) or in which words do not appear. Clipping folders even work on incoming stories outside your chosen categories.

You can save stories in memory or clipping folders to disk as ASCII files; you can print stories or even load clipping folders from disk. Unfortunately, there is no Autosave feature.

Securities—stocks, commodities, exchange indexes—don't automatically display in ticker-tape fashion. You'd soon overload on data. Instead, you enter the security symbol you want to monitor, say ATC for Atari Corp., AAPL for Apple Corp. and CBU for Commodore (the symbol legend is provided regularly through the feed or hardcopy can be obtained from Standard and Poor's). You can add various suffixes, such as C for Canadian or X for mutual funds, where applicable Only data for those symbols you enter are displayed.

Alan, being one of the rare breed of programmers who understands the need for keyboard commands to supplement the GEM-mouse structure, provides a wide range of Alt-key combinations which perform most of the functions in the menus.

Finally, XPress can work in background mode, so you can be capturing news stories while you're using another program. Alan tested several programs and found that many—including DEGAS, A-Calc, Thunder, Fleet Street Publisher, ST Writer and WordPerfect—work with ST XPress. Programs that demand most of memory or use the serial port won't work.

The value of ST XPress should be immediately apparent to anyone interested in current events, sports or stocks. It should also interest researchers, teachers and parents. What a gold mine it is for kids needing background material for a school project! I urge you to look into ST XPress—it's a new and different application, to my mind the most important new use for a computer to come along in several years.