by Joel Gluck
by Joel Gluck
Welcome, once again, to Our Game, the only monthly column that brings you extra-large doses of both insight and insanity. Many readers have asked the question: "Joel, why do you seem so out of touch?" Well, I'll tell you: I write this column two months before it is published. For example, even though you are reading the July issue of ANALOG (which appears in June), I'm writing this column in April. Such a time delay can make things extremely difficult ...
For example, there's the Our Game Special Election Year Game Idea Vote, which I initiated last month (the June issue, which appeared in May). This is an election to determine which game idea you, the reader, most want to see developed in Our Game (see last issue for voting instructions and descriptions of the four nominees). All votes must be mailed by August 1st, 1984. The problem is, since I have to wait until August for all the votes to be in, development of "our game" has to wait until an issue two months after that, due to the delay factor. So, "our game" can't be started until the October issue.
What this means is that I have four months of Our Game (July, August, September, and October) to do what I want! After careful consideration, I decided that the best thing to do would be to present a detailed treatise on the subtle relationship between ice cream consumption in Boston and the likelihood of global thermonuclear war. When I mentioned this idea to my closest friends, they laughed at me and began to abuse my priceless collection of eighteenth century floppy disks. I was ashamed and agreed that the only honorable thing to write about in the coming issues would be the development of a game ...
But before we proceed on to such trivialities as writing a game, let's take care of something really important: viewer mail! The amount of mail we're receiving these days is growing by leaps and, uh, bigger leaps, but that doesn't mean the quality is improving any ... If you're going to write to Our Game, please stick to English (or, if you must, Mandarin Chinese or Swahili), and please use standard writing instruments -- I'd like to remind a few of our readers that salad dressing just doesn't make very good ink. Please keep this in mind.
Our first letter this month comes from Matthew J.W. Ratcliff of St. Louis, Missouri. He has some useful additions to last month's tutorial on playtesting:
The less the playtester knows about your program, or programming in general, the better. This will immediately tell you several things, like how well you trap errors. A person who seldom computes will quickly find any major and, quite often, subtle bugs. If it's a utility program which requests a filename, for instance, what if the person types KEEP for a load file, instead of D:KEEP? Does the computer sit there, dumb as a rock with no error codes? Does a CTRL-3 get out of the problem (keyboard-forced end of file)? What about other expected keyboard inputs; does CTRL-3 crash the program? Does the code disallow inverse video, shift clear, and the break key? I could go on and on about the trials and tribulations faced with expected keyboard inputs. Let a novice "fat-finger" the keyboard for a while, and you will find them quickly enough.
Thanks for the good tips, Matthew. Handling keyboard input is sometimes so frustrating that programmers often avoid it entirely, checking only for values from the joystick or the console keys (START, SELECT and OPTION). Actually, for most games or educational programs, keyboard input can be an unnecessary complication -- working off only the joystick, for example, can make a program more user-friendly.
Cecil C. Alton, of Dumfries, Virginia, writes:
I would like a game I could play with my two-year-old. He is fascinated with the computer and especially likes BASIC where he keys in letters, both singly and with repeat feature. Other games I have interest him, and he grips the joystick with eager anticipation, but he does not interact with the game. One wild idea is to build a game with a simple "press any key" response being elicited from the player. This game would have to be easy to learn -- i.e., no difficult instructions required -- and could be developed around a learning-curve concept (learn from mistakes or from player's responses).
That's an excellent idea for a game, Cecil, and I believe someone's already done it! Monarch Data Systems, Inc., has just such a game it is called SofToy. The game consists of nine cute little animated pictures on the screen, which are activated by pressing a key. In the easiest version, any key pressed will activate a picture. But the game can also be made harder, so that only certain numbers or letters will make the pictures move. At its toughest, SofToy presents a child with sequences which he or she must duplicate by hitting the correct keys, very similar to the electronic game called Simon. This program may be just what you're looking for, Cecil.
Tom Hull, of Wakefield, Rhode Island, has some strong feelings about Our Game, not to mention a very unusual game idea:
In my opinion, I think you're setting up too many rules. My dreams of sending you "dream game" ideas were shattered when I couldn't fit in simultaneous, multiplayers and no violence, period! Some of the requirements seem ridiculous to me because of how easily they could be solved. So here are my words of wisdom on each of your requirements.
- Violence: I agree; the wrong type of violence could be harmful to the young minds of children. The "kill or be killed" theme should be avoided, but what about the "survive or be killed" theme? I don't see how saving your own skin would be harmful to kids' minds. Say the only objective is to run away from falling buildings or escape from a forest fire. How harmful can that be?
- Simultaneous play: Once again, I agree. It is fun when you either play against or in cooperation with a friend, but what if none of your friends like the game? This is why one should have the option for either single or simultaneous play.
- Sex Difference: This is the ridiculous one, because just a bit of good programming can solve the whole problem. Consider the following:
10 ? "Do you want to be a boy or a gir l";:INPUT A$ 20 IF A$="BOY" THEN PLAYER$="!#$":REM !#$ would be the character for a male player when redefined. 30 IF A$="GIRL" THEN PLAYER$="@%&":REM @%& would be the character for a fema le player when redefined.This could be modified to use P/M graphics or whatever you'd want to use. Another method would be to use an animal to portray the player, say a turtle. That way, no one could accuse the turtle of being male or female, as long as you don't call the game Mr. Turtle, or Turtle Man.
Now that that's off my chest, let's get to the game idea, which I call The Punkarium Wave. The setting is in a one-story mall. The player is an everyday person who just came out of the arcade and is about to go to the north end of the mall, where the person (you) has parked the car. Then you realize that, while you were in the arcade, the whole mall was taken over by punks, a class of people who all have mohawk haircuts, wear sun glasses and carry around "boxes" that are all blaring out the same punky tune (that sounds like someone trying to play a synthesizer like a bagpipe)!
Their "lifestyles" are contagious, so you must avoid any contact with them or you will become one of them! You run along a scrolling mall, trying to reach the north end, where the only remaining unlocked exit awaits. This would be impossible, if it wasn't for your only defense. Somewhere in the mall is Marvin's House of Metal. If you can find it and get inside, you can turn on the mall's speakers and blare some heavy metal to drown out the punks' boxes. All of the punks will stop dead in their tracks and cover their ears, letting you skip on by them. In ten seconds, the punks will have turned off the speakers. If you are not out of the mall by then, the punks will rush to block the north exit and all hope will be lost.
Well, Torn, I think your Punkarium Wave wins Our Game's "Weird Idea of the Month" award (your prize, a peanut butter and avocado sandwich, is in the mail). As for your complaint about Our Game, having "too many rules," let me say that there are no "rules" as to what you can send to Our Game. I like to see all kinds of game ideas, whether they be violent or non-violent, one or two-player, or whatever. The reason I've expressed a preference for non-violent games is simply that there have been so many violent video games that I am rather bored with the concept. It takes creativity and imagination to come up with something really new, and it is my challenge to the readers to submit non-violent games. It doesn't mean they have to.
As for your quick solution to the question of games that are biased toward one sex, I'm not so sure that changing the graphics is all that is needed. I believe that the general subject matter of most video/computer games tends to attract males more than females. Again, it's a challenge to the readers to come up with something different.
The task is not impossible. Last month, to kick off Our Game Special Election-Year Game Idea Vote, I nominated four game ideas, all of which were based on reader input, and all of which were essentially non-violent, two- or multi-player, and none of which seemed sexually biased (except maybe for Idea #1, which has a husband and his "huge wife," but that can be modified).
Our last letter this month comes from Greg Rizzo of Chicago, Illinois:
The truck that delivers peanuts to the zoo is late. You, the elephant, become very hungry. When the truck finally arrives, it is in such a hurry that it crashes and spills peanuts all over the zoo. You become so hungry that you break out of your cage and travel all around the zoo, shown on the TV screen as a maze, looking for and eating peanuts. But be careful, because there are mice wandering around the zoo. If they touch you, they will scare you to death. Also, there is a zookeeper who will appear on the screen looking for you. But, for your protection, there are mousetraps set at random spots in the zoo. You get points for eating peanuts and for catching mice in mousetraps. But you will lose a life for getting scared to death by a mouse.
I must admit it wasn't really my idea. It was really my brother's and his friend's. I just expanded on the idea.
Greg! How could you? Stealing your brother's game idea like that! Tsk, tsk. It's a nice game idea (I like the story behind the game, especially), but the game play itself sounds suspiciously like Pac-Man. What if, instead of being the elephant, you were the zookeeper? The elephant is loose in the zoo, eating spilled peanuts. Your aim is to get the elephant back into his cage as fast as possible. You do this by closing and opening gates in the zoo/maze, and by moving many of the peanuts so that they make a trail leading back to the elephant cage. To make the game more interesting, the maze could be different every time.
Well, that's it for viewer mail this month. Even though the Our Game Special Election-Year Game Idea Vote is in progress, don't hesitate to send in any new idea you have. If it's any good, it'll probably appear in these pages -- which means that people all over the U.S.A., not to mention the entire world, will see your name and read your idea!
This month, and the next three months of Our Game, will be devoted to a discussion of the creation and development of a simple computer game.
The working name for this game is Clues, and the first prototype version, CLUES.A, appears in Listing 1.
The idea behind Clues is very simple, and not entirely new. When playing, you are presented with a grid underneath which there is a buried treasure. To find the treasure, you move your man (whom I call the Seeker) to a likely spot and hit the trigger. If you were correct, you win. If not, the computer gives you a clue as to where the treasure is.
The clue is either an arrow or a number. An arrow points in the general direction of the treasure. A number gives the approximate distance of the treasure from your current spot.
This is not a new idea. I believe that there was a game of this type for the Atari 2600 (way back when it was called the Video Computer System). In that game, you were looking for a flag, not a treasure. Big difference ... !
Of course, the CLUES.A is a simple one-player game. More later about how we can improve and expand it.
Unlike the dreaded FLW listing from issue 16, Listing 1 is fairly clear. There is no mysterious string manipulation or brain-damaged program logic, and everything is simple and well documented with plenty of REMarks. Note: When typing the listing in, do not omit REM's that appear alone on a line. These are frequently accessed by GOTO's and GOSUB'S.
And now, an Our Game first ... a detailed explanation of the program:
Lines 200-260 are the top level of the program. The way it is organized, into five GOSUB's (with REMarks), makes the program very easy to read and follow, and makes finding specific parts of the program simple (for example, if you want to change something in the screen setup, Line 220 informs you that the screen initialization code begins at Line 3000). I usually begin all large BASIC programs with a series of GOSUBs like this.
Notice that Line 250 assumes that a variable called PLAYAGAIN was given a value at some point, probably in the subroutine starting at Line 5000. If PLAYAGAIN=1 (1 meaning "yes" or "true"), then the game branches back to the screen initialization routine.
The routine starting at Line 1000 prints the instructions and waits for the user to press the START key (Line 1200 handles that). The subroutine is called "Intro/Options," because if there were any game options they would appear at this point.
Starting at Line 2000 is the initialization procedure. Lines 2100-2250 handle the joystick data. The problem with the Atari joystick is this: what you'd like to have is the horizontal and vertical direction of the joystick (indicated by -1, 0, or 1 for each. For example, a vertical direction of -1 means "up," and a horizontal direction of 1 means "right." Zero means there is no movement along that component), but what the joystick gives you is a value from 5 to 15 that stands for one of the eight directions. To convert from this value to the horizontal (X) and vertical (Y), I READ -1's, 0's, and 1's into 2 arrays (XS() and YS()) indexed off the joystick value. For example, if the joystick reads "6" (up and to the right), the value given by YS(6) is -1 (up) and the value given by XS(6) is 1 (right).
The different characters used for "arrows" in the game are in DATA on Line 2360 (in future versions of the game, we'll redefine the character set to have better-looking arrows). The ASCII codes of these are read into the array ARROW() in the loop starting on Line 2320. Notice that I have to READ each arrow using the small string called CH$, before storing the ASCII value of CH$ (plus 128 to make it reverse field -- the "negative" image of the character) into the ARROW() array.
The ASCII codes for other characters that will appear on the screen are stored in aptly named variables starting on Line 2400. The GRID character, for example, is a period (.) and the SEEKER character is the solid ball graphic (CTRL-T). These characters, too, will be modified in future versions.
Screen initialization begins on Line 3000. The game itself is in graphics zero, the normal text mode, so, to make it look a little different, the screen and border colors are changed on Line 3110. Line 3120 uses a nifty POKE 752,1 which hides the cursor.
Starting on Line 3200, we see something interesting: COLOR WALL. Now we know that the variable WALL was defined as the ASCII code of a reverse field space (a solid white block) on Line 2410. We also know that COLOR is ordinarily used in plotting modes like 3, 5, and 7 to select a color register to draw with. Well, it so happens that invoking COLOR with the ASCII code in a character mode lets you draw with that character using PLOT's and DRAWTO's. This is exactly what happens on Line 3210, which draws a wall using the WALL character around the screen.
Lines 3250-3280 use a similar technique to draw the grid. COLOR GRID selects the appropriate character, and the loop does the rest. Lines 3300-3310 set up the starting coordinates of the Seeker (the approximate middle of the screen) and plot it. There is also a variable called UNDER, to store the value of what is under the Seeker (initially, plain old grid character), in case the player moves the Seeker over some of the clues he has dug up.
Lines 3400-3420 set up the treasure, and make sure its position is not equal to the Seeker's starting position.
The operating code for the game itself begins on Line 4000. Right before it begins, the timer is set to zero on Line 4100 (the Atari has a real-time clock measured in sixtieths of seconds jiffies at memory locations 18, 19, and 20), and the number of GUESSES is set to zero at Line 4110. This is so we can tell the player how long and how many guesses he or she took to find the treasure when the game is over.
Lines 4200-4240 are the nucleus of the game. All actions stem from these lines. The stick and trigger values are stored. If the trigger is being pressed and the stick is still (Line 4220), it means the player wants to venture a guess, so the program branches to the "take a guess" subroutine. If the joystick isn't idle (Line 4230), then the Seeker must be moved, so the program branches to 4300. If neither of these conditions are met, then the program does nothing and loops back to get new values for the joystick and trigger.
The routine for moving the Seeker (starting on Line 4300) contains a POKE 77,0. This is to prevent the computer from going into "attract mode" (color flipping), which occurs if the keyboard isn't used for about nine minutes. This poke is in the movement routine, so that if the player has stopped playing the game, the poke won't be executed, and after nine minutes the computer will go into attract mode.
Line 4310 uses the joystick direction arrays we created (you remember, way back in the initialization routine!) to convert the joystick value (S) to horizontal direction (XD) and vertical direction (YD). Line 4320 looks one spot ahead of the Seeker in the current direction, and stores the ASCII value of what's there into the variable G (that's how the LOCATE command works -- consult your BASIC Reference Manual for details). If G is equal to the value of WALL (Line 4330), that means there is wall ahead of the Seeker. The Seeker isn't supposed to move through walls, so the program goes back to the game loop.
To move the Seeker, we erase it, update its position, and redraw it. This happens quite clearly on Lines 4350 to 4370. The only trick is, instead of erasing the Seeker with a blank space, we are erasing it with what's underneath it (Line 4350), whether it be a grid or an old clue. Then, on Line 4380, the variable UNDER is given the value of G, which is what's under the Seeker now.
The "take a guess" routine, starting on Line 4500, is a bit more complex. First, it increments the number of guesses (Line 4502) and then proceeds along the following logic:
That's the whole clue-making process. The computation of distance or of the proper arrow index may seem complex, but after puzzling them out, they begin to make sense.
When the game ends, it branches to Line 5000 for the "End" routine. The elapsed time is computed using two of the time locations, and then is printed out, along with the number of guesses the player took.
If elapsed time was less than fifteen seconds, a little congratulatory sequence occurs on Line 5130. Lines 5140 to 5200 handle the option of playing again. The PLAYAGAIN variable is set to "one" if the START key is hit; if anything else is hit, it is set to "zero."
Why am I rehashing old game ideas (you may ask yourself)? Well, it so happens that this particular game idea is ideal to program simply and to expand upon creatively. With it, we can start small and think big.
For example, CLUES.A is only a one-player game. What happens when you make it two-player? I had a few ideas along those lines the other day, and I wrote them down in the following cryptic form:
These notes may seem a bit mangled, but there are some interesting ideas in there. Of course, we don't have to develop all these possibilities at once. We can write various prototypes to try out different ideas. As a matter of fact, that's the subject of the next Our Game. Keep your booties on and stay tuned!
I want mail so badly I can taste it (no, that's just an expression; I don't eat the letters you send me). More importantly, I want YOU to vote in Our Game Special Election-Year Game Idea Vote! Remember, if you don't vote soon, Victor the Frightening Vote-Counting Robot will get angry -- and you wouldn't want that to happen, would you? For details, take a look at last month's ANALOG (issue 19).
Of course, if there's anything you want to flame about, or any game idea you think is up to scratch, send it along, too. I promise you I'll read your letter.
Send your letters (and your favorite recipe for onion dip) to:
Our GameNext month: more CLUES!
100 DATA 244,235,824,330,529,922,868,5
98,273,700,46,202,45,918,124,6858
1120 DATA 408,447,457,107,985,441,461,
135,606,407,787,905,98,178,471,6893
2220 DATA 389,546,19,800,336,280,500,9
70,550,838,925,160,479,253,441,7486
2440 DATA 19,796,550,49,388,142,115,32
2,121,446,769,547,23,344,778,5409
3400 DATA 838,822,418,798,56,979,900,7
33,345,583,196,745,955,683,896,9947
4310 DATA 344,925,529,199,196,763,352,
875,222,797,679,377,345,267,67,6937
4530 DATA 790,670,331,739,441,962,556,
276,807,671,167,54,396,528,893,8281
5140 DATA 3,720,944,867,845,737,4116