by Joel Gluck
by Joel Gluck
Yow! Vacation's over, and it's time for Our Game, the only column in which you, the reader, get to influence the course of history! Yes, merely by sending in your ideas, criticisms, and comments, you can have your say as to what "our game" (the game we are writing together) will be like! In fact, if you send in some really interesting thoughts, they may well be printed in these very pages!
Enough hype. Let's get down to the nitty-gritty. Last time I promised that we would soon start the development of "our game" itself. Well, I haven't broken my promise. Read on and you'll see how to participate in Our Game's Special Election Year Game Idea Vote! But before we get on to this new business, let's first take care of some old business...
What would Our Game be without reader mail? Not very exciting, for starters. It's no fun to hear only one point of view (specifically, mine). But, thanks to a few brave souls who had the courage to take the dreaded leap off the eyebrows of anonymity, and into the far-seeing and all-encompassing Atarian public eye, the great tradition of reader mail goes on! (If you found that last metaphor a bit overdone, call the Ridiculous Metaphor Hotline at 1-800-5551234).
Allen Harberg of Glastonbury, Connecticut, writes:
"Here's a
game for the entire family: Diaper Panic. Two doting
grandparents rush to return an infant to its parents before time
runs out."
Thanks, Allen, for your, uh, game idea...
Larry Friemel, of Fullerton, California, has a gripe for the software industry:
"I feel time and care must be spent on writing software-embedded instructions and accompanying documentation. It should be of a quality that anyone reading it can understand and can feel satisfied that they have control over their program. Most software documentation today is like Chinese food, i.e., you may feet satisfied at first, but as you get deeper into it you find it says less and less, leaving your appetite unsatisfied often to the point of frustration. You get the feeling that, just maybe, someone spent a whole day describing a piece of software which took months to create, refine and make marketable. We should deplore such works which are written as adventure games, leaving it up to the user to hunt for clues about how to use them."
I agree with your views on documentation, Larry, although I do feel that the situation is improving, and that most software companies today spend quite a bit of effort and money on good documentation. As for Our Game; a discussion of the ingredients of good documentation is in the works -- and "our game" itself will certainly have decent internal and external documentation.
In general, the question of documentation will become less important as systems become easier and friendlier to use. Apple's Macintosh is an excellent example of this: its operating environment is extremely friendly and does not hide features, making documentation practically unnecessary. (Of course, Apple does supply excellent documentation with the Mac.)
And one more thing, Larry: I don't appreciate the comparison of poor documentation to Chinese food. Aside from sleeping and listening to music, Chinese food is one of the chief pleasures of life. Please keep your analogies to yourself.
Jason Leigh, of Kowloon, Hong Kong, sent me a letter (by air mail) with the most gorgeous stamp I've received since Our Game began. It's a 30-cent stamp called "Hong Kong by Night." Jason's game idea isn't bad either. He writes:
"Why always be the good guys? You could have a game where you hold up a bank. The first level begins as you have to plant sticks of dynamite on the vault, while shooting bank tellers trying to get to the alarm bell. Every time you shoot a teller, he returns to his counter and his sequence of migrations to the bell re-starts. When you've attached enough dynamite to the vault, it blows up and you can rush inside to grab a bar of gold. You can carry one bar at a time and you must carry it back to your get-away car each time. When you have your hands full you cannot shoot, so there is a danger of the bank teller's reaching the alarm bell. When your attempt is successful, your computer figure grins happily out of the screen and you begin robbing the next bank until you're eventually caught."
Sounds like you've got the makings of a coin-op game hit, Jason: action, violence, skill, and suspense (when the alarm bell goes off, it's risky to stay because the police will show up; on the other hand, there's more gold to be had in the vault).
David Plotkin, of Walnut Creek, California, makes several intelligent points in his letter:
"You made the statement that the game will be written in BASIC, and ruled out machine language and BASIC Compilers for worthwhile reasons. But what about machine language subroutines, either on the Vertical Blank or called via USR calls? You don't need to know machine language to include these; many very good ones are available "canned" -- you just include the DATA statements in your program and call the routines as needed. These routines have tremendous potential to increase the number of "moving objects" from one to four or five, especially if VBI routines for Player/Missile objects are used. Another excellent routine which comes to mind is Tom Hudson's "Graphic Violence," (ANALOG Computing no. 8) which puts multiple animated explosions on the screen. Too long? How about the flickering starfield on the Display List Interrupt provided by Joe Trem in ANALOG no. 6. Or background music on the VBI provided by Mark Chasin in ANALOG no 7.
Tom Hudson's Player and Missile mover routines (ANALOG Computing no.'s 10 and 11) are excellent. The list goes on - scrolling, character movement, etc. The point is that these routines already exist; all we have to do is include them...
"Finally, you made a comment in your January column which is not strictly true. You said that BASIC doesn't let you use names for procedures, and that instead you have to use line numbers. What you can do, since you can call named subroutines, is equate your line numbers to a name, giving you something like this:
900 PREPARETUB=2000:CATCHROVER=3000:RO VERINTUB=4000:CLEANROVER=5000:DRYROVER =6000:THANKROVER=7000 1200 GOSUB PREPARETUB 1210 GOSUB CATCHROVER 1220 GOSUB ROVERINTUB 1230 GOSUB CLEANROVER 1240 GOSUB DRYROVER 1250 GOSUB THANKROVER"Pretty descriptive, no? Unfortunately, the disadvantage to this system is that it's hard to trace the program logic, because you keep forgetting what names are equated to which line number. Oh, well."
Other readers have mentioned the idea of incorporating machine language subroutines into our game, David, but none have seemed as well-versed on the subject as you. My own opinion on using machine language subroutines for our game is this: we will use them only if they are necessary to make our game enjoyable.
If it sounds like I'm hesitant to plan on using such a subroutine in Our Game, you are correct; I would prefer it if Our Game were written in such a style as to make its operation clear to all readers, even those with an elementary understanding of Atari computers and BASIC. All too often, machine language subroutines are complex black boxes -- which is fine if your sole aim is to improve a program's performance. Our Game's purpose, however, is not to produce the best possible game but rather to produce a good game in a manner understandable and reproducible by novices.
As for your point about named subroutines -- you are absolutely right; I had neglected that possibility. There is another disadvantage, however, to your named-line-number scheme: the program cannot be renumbered by a standard line-renumbering program, because the values of the names wouldn't be changed.
That's it for reader mail this month (except for some special mail -- read on!). For those of you who have sent mail and haven't seen it in these pages, please be assured that I read every word that you send me; it's just that I can't possibly include all of it -- at least not if ANALOG is going to have room for anything else! Don't be discouraged -- all of your ideas and comments help shape the content of this column. Keep those letters coming!
As sole author of Our Game (the column, not the game), I believed, until recently, that it was up to me to choose which idea, among all of your ideas, would be the basis for "our game."
But then I had a horrible thought. What if, after deliberating over various game ideas, choosing one, and presenting it in the column... what if the readers didn't like it? The dreadful consequences aren't difficult to predict: reader interest would decline, I would receive fewer and fewer letters, and Our Game would bite the dust.
But, just in the nick of time, I came up with a solution: The Ultimate Wimp-Out. You guessed it! I won't decide! You'll decide! You (the readers) will vote on it!
Yes, this column marks the commencement of the soon-to-be-forgotten Our Game Special Edition Year Game Idea Vote. To participate, all you have to do is send in a letter or postcard with your vote for best game idea (of the four described below) and a simple suggestion for the improvement or embellishment of that game. All votes must be in by August 1, 1984. Void where prohibited by law. The decision of the judges (me) will be final.
Now that we've gotten the rules out of the way, let's proceed to our four beautiful nominees:
Game Idea #1 comes to us all the way from sunny Milton Keynes, England. Trevor Skeggs (I love that name!) writes:
"Please don't mention that they're also struck down with Atari Fever in little ol' England (sorry, Trevor), but, if you must, my shoe size is 9, and I doubt if you've heard of my brand of toothpaste (comments directed at the January issue).
"I agree that violence is definitely 'passe' in video games, but it's awfully hard to substitute for the excitetnent of trying to hit something.
"Therefore, in my game's scenario, the player is seated in a rowing boat on a take. Opposite him is his huge wife, and in his hands is a black box (camera).
"The object is to prove that the Loch Ness Monster (Nessie) exists by taking a photo. Under the boat swims a dark, ill-defined shape, which occasionally breaks surface with a long-neck and insidious smile, played for laughs.
"The joystick controls the man's arms as you quickly spin round and take a picture. The top corner of the screen shows the developed photograph, which more often than not shows a foot, his wife's ugly face, a dead fish, a tin can, etc."
If you liked Trevor's idea, write a big number one on a piece of paper (so that Victor, our Robot Vote-Counter, won't misread it), along with your thoughts about how the game could be made even better, and mail it to Our Game!
Game Idea #2 is a combination of several reader's ideas. Charles D. Ybarra of Long Beach, California, mentioned in a letter that a game about food and nutrition would be interesting. Several readers recommended the idea of a computer board-game, including Del Rice, of West Pittsburg, Pennsylvania (who sent me an hilarious letter explaining why nobody reads Our Game), and Eric Hansotte of Glenshaw, Penn., as well as George Lentz of Toms River, New Jersey, who writes:
"Video games are based mostly on skill with little or no luck involved. If you don't have good hand-eye coordination you can pack it in for most of today's video games! If Our Game used a graphic roll of the dice or spin of the wheel, I feel it would be more likely to relate to young, old, male and female alike.
"Another thought is that a video game is always restricted to the TV screen (no physical involvement). We could consider combining the TV screen with a board game. This would give another dimension to the game and a very pleasant one, I feel. It might be nice not to be restricted to the TV screen."
Great ideas, George. I especially like the "separate game board" idea, because it gives readers something else to do besides typing in programs -- they get to construct their own game boards! The computer, of course, can keep track of what's happening on the game board, and handle -- on the screen -- any game action and player confrontation that need take place.
What does all this have to do with Charles Ybarra's food and nutrition idea? Well, Game Idea #2 is a board game based on the four food groups, with any number of players competing to eat well-balanced meals while progressing toward "Dessert," the center of the game board. Special squares to land on include "Fast Food," which pits player against player in a food eating/zapping race, and "Fortune Cookie," which contains surprises similar in nature to the "Chance" cards on a Monopoly board. There is not much space to describe the details of the game this month, so I'll try to fit it in next time.
Anyway, to vote for Game Idea #2, you don't even have to register -- just write to Our Game and Victor will add your vote to the already growing mandate (and don't forget to include an idea for improving the game).
Game Idea #3 is from a letter by Dale Curtis of Wenatchee, Washington. Dale writes:
"The idea is this: A two-player game that starts each player on opposite sides of the screen with the object to construct a road, railroad track, pipes, wall, etc. to the center and connect with the other's road, etc.
"There can be many levels, since when you complete one level the next level can be harder (more points to connect up, for instance). Of course, there could be things to prevent straight line-constructing (for instance, in constructing a road, there could be trees and houses to go around, angry land owners protesting certain routes, bad weather, or whatever). Also, the scoring can be of any sort: first to make the center, fastest time for both to complete (you might be able to make what one person does dependent on what the other does), which one uses the least amount of track, etc.
"This could be a very interactive game that is nondestructive and that anybody would want to play with speed of play being relative to the action."
The best thing about Dale's game idea is that it leaves possibilities for new ideas wide open. For example, I recently had the idea that players would have to search the board to find the materials to build their tracks (or walls or roads). You may have other, better ideas. If so, vote for Game Idea #3 and send those ideas in!
Last, but possibly not least, is Game Idea #4. Patty Wilson, of Lansdale, Pennsylvania, writes:
"I can't truly say that I'm the world's biggest video game fan, but I think a few of them are worthwhile enough to play until you can manage a half-decent score. My biggest complaints about video games are: 1) They move too fast, and.2) What good will it do me tomorrow if I kill 3 million aliens today? Allow me to explain.
"First of all, I could be described as 'laid back.' Sometimes I find it all too difficult (and no fun) to work up the nervous energy required to play many games. Everything happens so fast; you really have to concentrate to keep up, and enjoying the game while I'm playing becomes nearly impossible. I would like to see a game that moves at the pace I want it to, so I can really look at the graphics, recover from disasters, and take a breather after a victory. Secondly, I'm a great supporter of educational games that improve the mind, not just hand-eye coordination. No one is ever too old to learn; there must be a fun way to learn how to balance a checkbook or prepare a gourmet meal. Over-cooking a goose in Graphics 7 wouldn't have the unfortunate effect of sending smoke swirling through the house. And miscalculating a few numbers in a game called "Budget Warrior" wouldn't really cost you $97 in bounced checks. I think people are more likely to acquire a new ability if it's presented in an interesting, unique way instead of being learned the hard way."
Hmmm. Didn't see a game idea in there, did you? Well, that's because there's only the name of one: "Budget Warrior." When you vote for Game Idea #4 you are voting for an entertaining video game about the trials and tribulations of household economics and "low" finance! And, since Game Idea #4 hasn't really been invented yet, you get a chance to tell Our Game what "Budget Warrior" means to you! One hopes Patty will write back and tell us what she meant...
To sum it all up, here are our four nominees:
Send your vote in today (to the address printed below), with an accompanying suggestion for improvement of the game idea (or in the case of Game Idea #4, the idea itself). If you don't send your vote in soon, Victor our Terrifying Vote-Tallying Robot will have to visit your home to collect it from you (and he certainly gets grumpy when he has to make house calls).
In the past, Our Game has presented tutorials on Developing a Game Idea, Structured Programming, and Debugging. This month we continue the description of the golden path to a finished game by discussing the necessary and, yes, fun (!) practice of playtesting.
For starters, when do I know it is time to playtest my game? Ideally, you should playtest your game as soon as you aren't afraid to show it to people. The sooner you playtest the game, the sooner you'll be aware of changes that should or must be made in your program.
Who should I use to playtest the game? Anyone you can get your hands on! Go out of your way to find people of different ages, sexes, levels of intelligence, and backgrounds. Don't rule out a possible playtester -- even a five-year-old can teach you something about your game.
What do I do during the playtesting? Well, this may sound strange, but the best way to treat your playtesters is to keep your mouth shut. Players should be able to run and play the game without any coaching from you. If they really need help or are confused, there are shortcomings in your game.
This all sounds very harsh, but it stems from one basic philosophy: any game should be figure-outable without any written documentation. All necessary information and explanation should be accessable within the game itself.
There are practical reasons behind this philosophy. Let's say you are a salesman in a computer/ software store demonstrating new games to potential customers. A typical customer, Mr. Impatient, sees a couple of games he wants to try. Game A is a simple, fun game. Game B looks more complex; as a matter of fact, it's so complex that you have to look at the documentation to demonstrate the game. Mr. Impatient gets impatient while you are trying to figure it all out, and decides to buy Game A.
This little scenario is typical of video game sales in computer stores. I ought to know -- I spent a summer selling software in just this way. What it comes down to is this: people hate to look at written instructions, and prefer games that are simple and clear. Your playtesting will help to show you whether your game is a Game A or a Game B. But if you really want to find out, you have to be silent during playtesting, and watch your playtesters very closely.
What should I tell my playtesters? Encourage your playtesters to make verbal comments, complaints, and suggestions during play and after. You may also want to elicit comments about specific elements of your game that you are unsure about.
Your task during the playtest is to write down everything they say, including what they do like. Also take notes on difficulties they have or unexpected actions they take. Writing all of this down may seem like work -- that's because it is. Playtesting is by far the most valuable method of improving a game, but is entirely worthless if you don't get it all down on paper. Some programmers are a bit lazy and try to remember it all (like I used to do), only to say the next day: "Gosh, I'm sure that Michael recommended three things for me to change, but I can only remember two..."
One of the DON'Ts of playtesting, mentioned above, was to explain things or give coaching to your playtesters. (Remember: there won't be a copy of you sold with every game!) Another DON'T is arguing with playtesters. Never argue with a playtester! There are good reasons for this:
Now don't get me wrong. It's tough not to argue with someone who says: "I don't like the spaceship."
"Why not?" you reply.
"It's uglier than a frog in a blender," says the playtester. At this point it's very difficult not to rejoin:
"Are you kidding? I spent a week designing that space ship! It's the best you can do in 16 by 7 pixels! Why that ship looks just like the Millenium..." etc., etc.
But what you ought to say is: "Ugly, you say? Well, how could I improve it?" Or, better yet, "Draw me a sketch of how you think it ought to look."
It's evident that this approach does more for the both of you than arguing. Remember, you're not out to prove anything to your playtesters; save all the hype for Electronic Arts, Atari, Synapse, or whoever you're trying to sell your game to.
Once the playtesters have playtested the game to their hearts' content it is time to turn on the high-intensity lights, get out the whip and the black leather gloves, and ask a few questions... heh, heh! Questions like:
As before, write down the answers to all these questions. You may consider your playtesters inexperienced or lacking in taste or judgement, but, like it or not, they represent realistic opinions that differ from yours -- opinions that may happen to coincide with whoever screens out incoming games at the Atari Program Exchange, for example. Also, apparently minor comments made by playtesters often inspire game designers to turn an ordinary game into a great game.
Of course, playtesting sometimes isn't all it's cracked up to be. For example, I recently wrote a simple two-player maze game and had some friends of mine try it out. The first playtester, Dan, enjoyed the game immensely. As a matter of fact, we played the game together for three hours. However, I didn't learn much from Dan. Later that night, though, Crazy Bob and I had a go at it. Crazy Bob is not as good at video games as Dan is, and just by watching him I saw faults in my game, especially in the user interface. The next day I made significant improvements in the game. It just goes to show that the less likely a person is as a playtester, the better a playtester they'll be.
What do I do with all of the stuff I've written down? One of the best ways of using it is to look through and find similar comments that were made by more than one playtester. Add to this special list any suggestions that you think are especially good.
Then it's time to go back to the ol' keyboard and make the changes in your program recommended by the list. You may not agree with some of the suggestions, but it is worthwhile to at least try out other people's ideas. Of course, it is wise to keep a copy of the original game, as well as copies of the program made after each major change. Do not change things in your program that your playtesters liked; try to add more of similar things to your game.
Once you've made the changes (and debugged everything), it's time for a whole new round of playtesting! This time, though, you'll have copies of the program containing different versions of certain features, so that playtesters can make a "side-by-side" comparison.
One more question. How do I know when I've got a finished game? This is a difficult question faced by all game programmers. The only proper answer is to use your best judgement. If the complaints of your playtesters are down to a minimum, and they seem to actually be enjoying themselves while playing the game, if new play-testers have little trouble understanding the game, then you're on the way to having a finished product.
On the way? Well, it's not finished yet. You still have documentation to write... which, coincidentally, is the subject of our next Our Game tutorial. Stay tuned!
Yes, Victor our Ferocious Vote-Tallying Robot is waiting for you to send in your vote for best game idea in Our Game's Special Election Year Game Idea Vote! Just write us a letter or postcard with the number of one of our four wonderful nominees, along with a suggestion for the improvement of the idea. Our address is:
Our Game
Don't be bashful! If you have something. to say about the state of computer/video games in general, or even if you just want to flame about chocolate cupcakes, hyperlipidemia, or Ronald Reagan, don't be afraid to drop us a line!
Next month: gee, even I don't know what's going to be in Our Game next month... so get ready for a total surprise! And keep those votes pouring in!
Original text copyright 1984 by ANALOG Computing. Reprinted with permission by the Digital ANALOG Archive.