CD Actual 15

home *** CD-ROM | disk | FTP | other *** search

/ CD Actual 15 / CDACTUAL15.iso / cdactual / program / pascal / P_ROBOTS.ZIP / P-ROBT21.ZOO / p-robots.doc < prev next >

Wrap

Text File | 1989-10-30 | 106.9 KB | 2,736 lines

P-ROBOTS A Game For PASCAL Programmers Version 2.0 -- December 1989 By David Malmberg Distributed by Softworks 43064 Via Moraga Mission San Jose, California 94539 (415) 659-0533 _______ ____|__ | (tm) --| | |------------------- | ____|__ | Association of | | |_| Shareware |__| o | Professionals -----| | |--------------------- |___|___| MEMBER Copyrighted 1989 -- All Rights Reserved By David Malmberg JUST WHAT IS P-ROBOTS? P-ROBOTS ("pee-robots") is a game based on computer programming in PASCAL. The objective of the game is to design and program a "robot" that can triumph over similar robots designed and programmed by others in a real-time battle of wits and flying missiles. You control your robot by writing a procedure in PASCAL to specify your robot's behavior and strategy in its efforts to vanquish up to three other robots in a battle to the death. A variety of pre-defined P-ROBOTS PASCAL functions and procedures allow your robot to track its position on the battlefield, monitor its health or damage condition, and calculate the distance and angle to opponents from its current battlefield position. Each robot is equipped with a cannon to fire missiles, and a motorized drive mechanism to either close in for the kill of a hapless opponent or flee from a fierce foe. P-ROBOTS is an excellent way for the novice programmer to sharpen his/her PASCAL skills and have fun at the same time. However, P-ROBOTS does assumes that the robot designer/programmer already knows the fundamentals of programming in PASCAL. For the experienced programmer, P-ROBOTS offers a chance to see just how well you program in a programming environment where "bad" code can lead to graphic and ignoble defeat and "brilliant" code can bring triumph and glory. In addition to being enjoyed in thousands of homes, P-ROBOTS has been successfully used in a number of classroom settings -- from high school PASCAL programming classes to graduate level courses in Artificial Intelligence. "The competitive environment that P-ROBOTS creates has really sparked my students' desire to learn. Our weekly robot contests are great fun and enjoyed by all -- including me", said one high school PASCAL teacher. Another teacher has challenged his PASCAL students by offering a unique reward: any student that can design and program a robot that can beat the teacher's robot consistently does not have to take the final exam. i TABLE OF CONTENTS JUST WHAT IS P-ROBOTS? . . . . . . . . . . . . . . . . . . . . . . . i TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . ii P-ROBOTS REGISTRATION/ORDER FORM . . . . . . . . . . . . . . . . . .iii LICENSE TERMS (Shareware Rules) . . . . . . . . . . . . . . . . . . . iv DISTRIBUTION OF P-ROBOTS BY DISK VENDORS . . . . . . . . . . . . . . v P-ROBOTS PRODUCT/TECHNICAL SUPPORT . . . . . . . . . . . . . . . . . vi ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . .vii INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 HARDWARE AND SOFTWARE REQUIREMENTS . . . . . . . . . . . . . . . . . 1 FILES ON THE DISK . . . . . . . . . . . . . . . . . . . . . . . . . . 1 GETTING STARTED . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 INVOKING A CONTEST . . . . . . . . . . . . . . . . . . . . . . . . . 3 CONTROLLING YOUR ROBOT'S MOVEMENT . . . . . . . . . . . . . . . . . . 4 ATTACKING OTHER ROBOTS . . . . . . . . . . . . . . . . . . . . . . . 5 OTHER SPECIAL P-ROBOTS FUNCTIONS AND PROCEDURES . . . . . . . . . . . 7 TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 DISTANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ANGLE_TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 RANDOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 TRIG FUNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 8 INFLICTING DAMAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 9 PUTTING IT ALL TOGETHER . . . . . . . . . . . . . . . . . . . . . . . 9 ROBOT PROGRAMMING RULES . . . . . . . . . . . . . . . . . . . . . . . 12 ADVANCED P-ROBOT FEATURES . . . . . . . . . . . . . . . . . . . . . . 13 CONTROLLING THE ANIMATION SPEED . . . . . . . . . . . . . . . . 13 PROTECTIVE SHIELDS . . . . . . . . . . . . . . . . . . . . . . . 13 FUEL CONSTRAINTS . . . . . . . . . . . . . . . . . . . . . . . . 14 RUNNING OUT OF FUEL . . . . . . . . . . . . . . . . . . . . . . 15 AN EXAMPLE USING A SHIELD AND FUEL . . . . . . . . . . . . . . . 15 ROBOT TEAMS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 AN EXAMPLE OF A ROBOT TEAM . . . . . . . . . . . . . . . . . . . 19 OBSTRUCTIONS ON THE BATTLEFIELD . . . . . . . . . . . . . . . . 22 AN EXAMPLE DEALING WITH OBSTRUCTIONS . . . . . . . . . . . . . . 22 INTELLIGENCE OPTIONS . . . . . . . . . . . . . . . . . . . . . . 26 APPENDIX I: COMPILER ERRORS . . . . . . . . . . . . . . . . . . . . . 27 APPENDIX II: RUN-TIME ERRORS . . . . . . . . . . . . . . . . . . . . 29 APPENDIX III: COMMON PROBLEMS . . . . . . . . . . . . . . . . . . . . 31 APPENDIX IV: THE P-ROBOTS PASCAL LANGUAGE . . . . . . . . . . . . . . 32 APPENDIX V: A BLATANT "PLUG" FOR ANOTHER SOFTWORKS PRODUCT . . . . . 35 APPENDIX VI: ABOUT THE AUTHOR . . . . . . . . . . . . . . . . . . . . 39 ii P-ROBOTS REGISTRATION/ORDER FORM Remit to: Softworks 43064 Via Moraga Mission San Jose, California 94539 You can also order by phone using your Mastercard or VISA by dialing (415) 659-0533, 12:00 noon to 9:00 p.m., PST ONLY, Monday to Friday. P-ROBOTS Registration ..............................@ $ 25.00 ea $ ______ Registration entitles you to the following: (1) Notice of all future P-ROBOTS upgrades. (2) Latest version of the program, with a collection of the most recent and best robots, and a printed manual. (3) Turbo or Quick Pascal source code for P-ROBOTS. (4) Turbo or Quick Pascal source code for the multi-tasking PASCAL compiler used as the basis for developing P-ROBOTS. (5) Telephone support from 7:00 to 9:00 PST (M-F). (6) A warm glow from having supported at least one of the many Shareware products you probably use. (7) The P-ROBOTS author's eternal gratitude. Orders are normally shipped by US mail at no additional charge. For UPS shipment, please add $4.00...............@ $ 4.00 ea $ ______ For shipments outside the United States, add.....@ $ 5.00 ea $ ______ Subtotal $ ______ (California residents please add 7 1/4% sales tax) Tax $ ______ TOTAL $ ______ Payment by: ( ) Check ( ) MasterCard ( ) VISA ( ) Cash Name: _______________________________________________________________ Address: _______________________________________________________________ : _______________________________________________________________ State: ______________________________ Zip:____________________________ Day Phone: ____________________________ Eve: _____________________________ Card #: _________________________________ Exp. Date: __________________ Signature of cardholder: _________________________________________________ Disk Version Desired: _____ IBM 5 1/4 _____ IBM 3 1/2 iii LICENSE TERMS (Shareware Rules) P-ROBOTS is NOT public domain or free software, but is being distributed as "Shareware". This means that if you are a regular user of P-ROBOTS, you should pay for your copy and become a registered user. Only from the income from your registration fees can the author continue to provide product support, make enhancements to P-ROBOTS, and stay in business. Non-registered users of this software are granted a limited license to make an evaluation copy for trial use on a private non-commercial basis, for the express purpose of determining whether P-ROBOTS is suitable for their needs. At the end of this trial period, the user should either register his/her copy of P-ROBOTS or discontinue using it. Registered users of P-ROBOTS may use P-ROBOTS on any computer, provided that P-ROBOTS is used on only one computer at a time, and that the copy is not routinely used on that computer by other people. If other people use the copy of P-ROBOTS routinely, they should become registered users themselves. Registered P-ROBOTS users may make archival and working copies of the P-ROBOTS program disk to back up their software and protect their investment. They may also make evaluation copies of P-ROBOTS for trial use by non-registered users, subject to the terms outlined above. Operators of electronic bulletin boards (Sysops) are encouraged to post P-ROBOTS and related ROBOT game files for downloading by their users. This license to use P-ROBOTS does NOT include the right to distribute or sell P-ROBOTS. Distribution terms are detailed below. P-ROBOTS may be uploaded to and downloaded from commercial systems such as CompuServe, GENIE, and BIX, so long as the only charge paid by the subscriber is for on-line time and there is no charge for the program. Those copying, sharing, and/or electronically transmitting the program are required not to delete or modify the copyright notice and restrictive notices from the program or documentation; anyone doing so will be treated as a contributory copyright violator. The P-ROBOTS documentation may not be modified by users. The program may not be separated from the documentation when distributed. Printed or "Xeroxed" copies of the P-ROBOTS documentation (i.e., this manual) may not be distributed or sold without the written permission of Softworks. NOTE: This program is produced by a member of the Association of Shareware Professionals (ASP). ASP wants to make sure that the shareware principle works for you. If you are unable to resolve a shareware-related problem with an ASP member by contacting the member directly, ASP may be able to help. The ASP Ombudsman can help you resolve a dispute with an ASP member, but does not provide technical support for members' products. Please write to the ASP Ombudsman at P.O. Box 5786, Bellevue, WA 98006 or send a CompuServe message via EasyPlex to ASP Ombudsman 70007,3536. iv DISTRIBUTION OF P-ROBOTS BY DISK VENDORS Distributors of "public domain" or user-supported software libraries must obtain written permission to distribute copies of P-ROBOTS and related robot game files. No one may use P-ROBOTS as a promotion for any commercial venture or as an enticement for the user to pay for any program, product, or service unless they have received the express written permission of the program's author. In order to distribute P-ROBOTS, a dealer or disk vendor must comply with the following conditions: (1) You must obtain written permission from Softworks to distribute P-ROBOTS. If you receive no reply, write again: our silence does NOT constitute permission, and you may not distribute "pending" receipt of permission. (2) A fee of not more than $7 may be charged for each disk sold. P-ROBOTS may not be included on any disk sold for more than $7, including CD-ROM or optical disks, without express written permission from Softworks. (3) Vendors may not modify or delete ANY files on the disk. Vendors may add a "GO" program, and/or a reasonable number of small text files designed to assist or provide a service to the user, but these added files must be easily identifiable and end-users must be allowed to delete the added files. (4) Vendors must make a reasonable effort to distribute only the most recent versions of P-ROBOTS. All vendors who have requested and received written permission to distribute P-ROBOTS will be notified of updates as they are released. (5) All disk vendors must comply with any and all vendor guidelines or vendor requirements set forth by the Association of Shareware Professionals (ASP); for more information about ASP, contact its chairman, Jim Button, at Buttonware in Seattle. Violation of any ASP guideline or requirement automatically revokes permission to distribute P-ROBOTS. Until formal requirements are adopted by the ASP, you must comply with the following guidelines: Vendors must make an attempt to educate users on the nature of Shareware. Catalogs, advertisements, order forms, and all disks sold should contain ASP-approved or recommended wording describing the nature of shareware, and should explicitly state that no part of disk sale revenues are paid to the programs' authors. When vendor catalogs or advertisements carry both Shareware and PD programs, the Shareware programs must be differentiated from the public domain programs in some way (in the description, with an asterisk, by listing the registration fee, etc.). v P-ROBOTS PRODUCT/TECHNICAL SUPPORT Softworks will make every reasonable effort to fix P-ROBOTS bugs, and help registered users by answering technical and other P-ROBOTS related questions. This Product/Technical support for P-ROBOTS is available to registered users (only) in several forms: (1) By leaving a message in the 'Softworks' forum on BIX (the BYTE Information Exchange). (2) By telephone to David Malmberg at Softworks, Monday through Friday from 7:00 PM to 9:00 PM (Pacific Coast Time) at (415) 659-0533. Please respect these hours! (3) By CompuServe E-Mail to David Malmberg, CompuServe ID 73435,1277. (4) By letter to: Softworks 43064 Via Moraga Mission San Jose, California 94539 If you send disks or listings that you wish returned, be sure to enclosed a self-addressed, stamped envelope (SASE) with sufficient postage. If you do not enclose a SASE, your material will not be returned. Regardless of the method you use to solicit P-ROBOTS support, if you are having a problem and you can not get P-ROBOTS to do what you think it should do, please provide background information on the following: (1) The version of P-ROBOTS you are using. (2) The computer system you are using. (3) Your system's configuration, i.e., amount of RAM, number and type of disk drives, the type of monitor you are using. (4) Any memory resident programs you have installed at the same time you are using P-ROBOTS and a "rough idea" of what they do and how much memory they take. (5) Your problem, i.e., what is happening vs. what you think should be happening. vi ACKNOWLEDGEMENTS P-ROBOTS owes a great deal to many people and to several previous programs. The P-Code PASCAL compiler that was used in P-ROBOTS has a long history. It was originally developed and published in 1976 by Nicklaus Wirth, the "father" of PASCAL. In 1982, M. Ben-Ari developed and published a book describing how to make the compiler capable of multi-tasking. Over the years, this compiler has been converted to many, many different computers and to many different dialects of PASCAL. In 1986, Charles Schoening converted the compiler to Turbo Pascal version 2.0 on the IBM and released his version to the public domain. I have enhanced and converted the compiler to the most recent releases of Turbo Pascal (versions 4.0, 5.0 and 5.5 for the IBM and compatibles), as well as, to Microsoft's QuickPascal. This version was then adapted to be the compiler "engine" for P-ROBOTS. The inspiration for P-ROBOTS and the initial design of the program came from a similar program called C-ROBOTS by Tom Poindexter, which was first published in 1985. As might be expected from the name, C-ROBOTS allows the programmer to design and program his/her robots in the C language, rather than PASCAL. If you are interested in C-ROBOTS, Tom is selling it as Shareware for a $20 registration fee. The registration fee entitles you to the latest version of the program, a large collection of excellent robots, and the source code for the C-ROBOTS (written in C -- of course). C-ROBOTS can be ordered from Tom at the following address: Tom Poindexter 6864 Amherst Court Highlands Ranch, CO 80126 C-ROBOTS can NOT be ordered from Softworks; it must be ordered from Tom directly at the above address. In addition, I would especially like to thank Professor B.J. Gleason of Upsala College and his students. Version 2.0 of P- ROBOTS benefited greatly from their suggestions. Professor Gleason and his students also donated some truly awesome Robots that are included on the current P-ROBOTS disk. vii INTRODUCTION P-ROBOTS ("pee-robots") is a game based on computer programming in PASCAL. The objective of the game is to design and program a "robot" that can triumph over similar robots designed and programmed by others in a real-time battle of wits and flying missiles. You control your robot by writing a procedure in PASCAL to specify your robot's behavior and strategy in its efforts to vanquish up to three other robots in a battle to the death. A variety of pre-defined P-ROBOTS PASCAL functions and procedures allow your robot to track its position on the battlefield, monitor its health or damage condition, and calculate the distance and angle to opponents from its current battlefield position. Each robot is equipped with a cannon to fire missiles, and a motorized drive mechanism to either close in for the kill of a hapless opponent or flee from a fierce foe. P-ROBOTS is an excellent way for the novice programmer to sharpen his/her PASCAL skills and have fun at the same time. However, P-ROBOTS does assumes that the robot designer/programmer already knows the fundamentals of programming in PASCAL. For the experienced programmer, P-ROBOTS offers a chance to see just how well you program in a programming environment where "bad" code can lead to graphic and ignoble defeat and "brilliant" code can bring triumph and glory. In addition to being enjoyed in thousands of homes, P-ROBOTS has been successfully used in a number of classroom settings -- from high school PASCAL programming classes to graduate level courses in Artificial Intelligence. "The competitive environment that P-ROBOTS creates has really sparked my students' desire to learn. Our weekly robot contests are great fun and enjoyed by all -- including me", said one high school PASCAL teacher. Another teacher has challenged his PASCAL students by offering a unique reward: any student that can design and program a robot that can beat the teacher's robot consistently does not have to take the final exam. HARDWARE AND SOFTWARE REQUIREMENTS If you intend to run P-ROBOTS on an IBM or compatible computer, you will need at least 384K of memory and DOS 2.1 or later. Either a color or monochrome monitor may be used. If you are using a color monitor, P-ROBOTS will automatically detect it and use different colors for each robot. If you are using a monochrome monitor, P-ROBOTS will display your robots accordingly. FILES ON THE DISK You should have the following files on your P-ROBOTS disk: P-ROBOTS.EXE The is the main program that is executed whenever you hold a P-ROBOTS contest. 1 P-ROBOTS.DOC This file contains the documentation for P-ROBOTS. It is a text file and can be printed by giving the command at the DOS prompt: TYPE P-ROBOTS.DOC > PRN PR-DEMO.BAT This is a file that gives a demonstration of a typical P-ROBOTS contest between three robots. ????????.PR These are other PASCAL source code files for other robots. All P-ROBOTS robots MUST have .PR file extensions. Without this .PR extension, P-ROBOTS will not compile the robot and enter it in any robot contests. GETTING STARTED To see a typical P-ROBOTS contest, just execute the batch file PR-DEMO. What you will see will be the PASCAL source code for three robots being read from the disk and compiled by P-ROBOTS. After being compiled successfully (without any errors), you will then see a battle between these three robots. The battle will last between one and four minutes and you will be able to see the individual robots move around the battlefield, fire their missiles and get hit when the missiles explode too near them on the screen. The screen and the battlefield will look something like the following: (x=0,y=999) (x=999,y=999) +------------------------------------+ 1 CHASER | | D% 015 Sc 218 | 1 | Sp 000 Hd 090 | \^/ | X= 902 Y= 890 ^ | (missile exploding) <-#-> | ------------------ | | /v\ | 2 M66 | | D% 050 Sc 275 Y | + (missiles | Sp 100 Hd 180 | + flying) | X= 89 Y= 534 a | | ------------------ x | 2 | 3 NINJA i | | D% 000 Sc 045 s | | Sp 000 Hd 000 | 3 | X= 423 Y= 350 | / | ------------------ | (robots) | | | | | | | | | | | CPU +------------------------------------+ Cycles: 34512 (x=0,y=0) X axis --> (x=999,y=0) 2 The battlefield is 1000 meters by 1000 meters with the coordinates 0,0 in the lower left hand corner of the screen. The border of the battlefield has a "fence" or "wall" around it which will cause the robots damage if they run into it. Hitting a border of the battlefield will also cause your robot to come crashing to a halt. On the battlefield, each robot is represented by a number from 1 to 4. (There can be at most four robots in any one contest.) Flying missiles will be represented on the screen by + symbols, and explosions by a flurry of lines and corners -- as can be seen above. Beside the battlefield are several "status" areas where information about each robot is displayed. The number that precedes the robot's name is its symbol on the screen. For example, the number 2 represents the robot M66 in the above display. The "D%" field shows the percentage of damage that the robot has incurred so far. When the damage percentage gets to 100% the robot dies. The "Sc" field shows the direction in degrees (from 0 to 359) that the robot's scanner is currently pointed. The scanner is used to detect the presence of enemy robots and to aim missiles at them. The "Sp" field show the robot's current speed. A speed of zero means the robot is standing still and the maximum speed is 100. The "Hd" field show the robot's current heading, i.e., the direction it is moving. Like the scanner field, the heading is shown in degrees from 0 to 359. The "X=" and "Y=" fields show the robot's current X and Y coordinates on the battlefield, respectively. The X-axis runs from 0 on the left to 999 on the right side of the battlefield. The Y-axis runs from 0 at the bottom on the screen to 999 at the top. All angles/directions in P-ROBOTS are calculated in degrees from 0 to 359 using the traditional compass directions you undoubted learned in Geometry. Due east is zero degrees, north is 90 degrees, etc.: 135 90 45 \ | / \ | / 180 --- x --- 0 / | \ / | \ 225 270 315 INVOKING A CONTEST Sooner or later, you are going to get tired just watching the DEMO match and will want to see contests between other robots - perhaps, even your own robot creations. There are two types of contests: single games or matches. In single game mode, the game is played with animated "graphics" where the progress of the battle can be watched on the screen. Match play is when you want to run a series of contests (maybe as many as 100) between the same group of robots to see what the winning percentages are for each contestant. Match play does not display the actual battles, but just shows the summary of wins and loses as each individual game is played. Match play is ideal for playing overnight. If you want to stop a P-ROBOTS game (either single game or match), just hit Control-Break. 3 To run a single game, just give a command at the DOS prompt like: P-ROBOTS Robot1 Robot2 .. Robot3 For example, to run a single game between the robots: NINJA, HOTSHOT, WIMP and BLASTER you would enter the command: P-ROBOTS NINJA HOTSHOT WIMP BLASTER Or to run a single game between HOTSHOT and WIMP you would enter the command: P-ROBOTS HOTSHOT WIMP It is also possible to test your robot against a "default" robot, named TARGET, that is built into the P-ROBOTS program. TARGET just sits in the center of the battlefield waiting to get shot at. However, TARGET does shoot back -- so be warned that beating TARGET is not totally a trivial exercise. TARGET is an excellent opponent for testing new robots. For example, to test a robot named FRED against TARGET, just give the command: P-ROBOTS FRED To invoke a series of contest, i.e., match play, append a "/MNNN" behind the normal single play command, where NNN represents the number of games you wish to play in the match. For example, "/M50" would cause 50 games to be played in the match and "/M100" would cause 100 games to be played. HOTSHOT, WIMP and BLASTER you would enter the command: P-ROBOTS NINJA HOTSHOT WIMP BLASTER /M20 Or to run a series of 10 games between HOTSHOT and WIMP you would enter the command: P-ROBOTS HOTSHOT WIMP /M10 IMPORTANT NOTE: The actual files on the disk containing the source code for the various robots MUST have a .PR file extension. However, when the game is invoked, the use of this extension is optional. CONTROLLING YOUR ROBOT'S MOVEMENT To move your robot in P-ROBOTS you must use the special procedure "Drive" that is built into the P-ROBOTS version of the PASCAL language. The Drive procedure would be used in your program as: Drive (degree,speed); This would cause your robot to move in the direction specified by "degree" and at the speed indicated by the second parameter, "speed". The direction will be forced by the Drive procedure to be between 0 and 359 (i.e., degree := degree MOD 360;) and the speed will be restricted to between 0 and the maximum of 100. Calling the Drive procedure with a speed of zero, will cause your robot to stop. 4 For example: Drive(90,100); (* drive north at top speed *) Drive(heading,0); (* slow down and stop *) In an attempt to simulate some degree of reality, a robot's speed does not change instantly, but rather has to go through periods of acceleration and deceleration. For example, to stop a robot traveling at a maximum speed of 100 will take between 100 and 200 meters. Conversely, to get up to a speed of 100 from a standing stop will also take between 100 and 200 meters. Also, your robot will not be able to "turn on a dime". You must be moving at a speed of 50 or less to change directions. Attempting to turn while going over 50 will cause your robot's drive motor to "over heat" and your robot will just coast to a stop on its current heading. To monitor the status of your movement on the battlefield, the P-ROBOTS version of PASCAL has several special built-in functions. The built-in "Speed" function returns the current speed of your robot (from 0 to 100). Remember that the value returned by Speed may not always be the same as the last parameter used in the last call to Drive, because of acceleration and deceleration. An example of how the Speed function might be used is as follows: Drive(270,100); (* start driving, due south *) ; ; ; (* other instructions *) IF Speed = 0 (* check if stopped, i.e., current speed = 0 *) THEN Drive(90,20); (* Probably, ran into the south border *) (* Go north at speed of 20 *) The built-in "Loc_X" and "Loc_Y" functions return your robots X and Y coordinates on the battlefield, respectively. The following shows how these functions might be used: Drive (45,50); (* start driving in north-easterly direction *) WHILE (Loc_X < 900) AND (Loc_Y < 900) DO Drive(45,50); (* i.e., just keep driving until we are close to a border *) Drive (45,0); (* slow down and stop *) ATTACKING OTHER ROBOTS The main offensive weapons available to your robot are its scanner and its cannon. Both of these weapons are controlled by using special built-in capabilities of the P-ROBOTS PASCAL language. The scanner is an "electronic eye" that enables your robot to look for enemy robots in any chosen direction from 0 to 359 degrees. The scanner has a maximum resolution of +/- 10 degrees. This allows your robot to quickly scan the battlefield at a low resolution, then use finer resolution to pinpoint a foe's precise position. The scanner would be accessed by a reference to the "Scan" function, as follows: Scan(degree,resolution) 5 This function invokes the robot's scanner, at the specified degree and resolution. This function returns an integer value of 0 if no enemy robots are within the scan range or a integer value (greater than 0) representing the distance to the nearest robot in the scan area. The value passed as the parameter "degree" will be forced to be in the range 0 to 359. Likewise, the "resolution" will be forced to be in the range of +/- 10 degrees. Some examples: Enemy := Scan(180,10); (* scans the area from 170 to 190 degrees *) Dist_To_Foe := Scan(180,2); (* scans from 178 to 182 degrees *) Target_Range := Scan(90,0); (* scan 90 degrees, with no variance *) Once an enemy robot is found with the scanner, you would use your robot's cannon to fire a missile at the enemy. This is done by using P-ROBOTS special "Cannon" procedure: Cannon(degree,range); This will fire a missile in the direction specified by the parameter "degree" and for a distance specified by the value of "range". Your robot's cannon has a maximum range of 700 meters. There are an unlimited number of missiles -- so you need not worry about running out. However, it will take some time to reload between firing missiles; so that, the number of missiles in the air at any one time to limited to two. The cannon is mounted on an independent turret, and therefore can fire in any direction, regardless of the robot's current movement direction. For example, the following "chunk" of code will cause your robot to constantly scan for enemies and blast away at them as long as they are in sight. When they are no longer in sight (or in range), the scanner will move to the next 20 degree segment of the circle: Angle := 0; (* initialize to east *) REPEAT Enemy_Range := Scan(Angle,10); (* Get range to target -- if any *) WHILE (Enemy_Range > 40) AND (Enemy_Range <= 700) DO BEGIN (* Enemy in sight and in range *) Cannon(Angle,Enemy_Range); (* Blast it! *) Enemy_Range := Scan(Angle,10); (* Still there? *) END; Angle := Angle + 20; (* move search to next segment *) UNTIL Dead or Winner; The "Dead" and the "Winner" in the UNTIL statement are special pre-defined Boolean functions in P-ROBOTS. Dead will have a value of FALSE while your robot is still alive (i.e., its damage is less than 100%) and TRUE when it finally dies. Similarly, Winner will be TRUE if your robot is the last survivor of the battle and FALSE otherwise. 6 If your robot utilized the basic "Sitting Duck" strategy given above, its opponents would undoubtedly make short work of it. To make the strategy a little smarter, we need some way to determine if we are under attack. Fortunately (and not surprisingly), P-ROBOTS has another special function that can assist us -- the "Damage" function. Whenever you use this function in your code, it will return an integer value of your robot's current damage percentage. If this value changes, then we know the robot is under attack and it probably should run for safety. As an example, let's see how the Damage function could be used to make the above code a little smarter: Old_Damage := Damage; (* Get initial value of damage *) Angle := 0; (* initialize to east *) REPEAT Enemy_Range := Scan(Angle,10); (* Get range to target -- if any *) WHILE (Enemy_Range > 40) AND (Enemy_Range <= 700) DO BEGIN (* Enemy in sight and in range *) Cannon(Angle,Enemy_Range); (* Blast it! *) Enemy_Range := Scan(Angle,10); (* Still there? *) END; Angle := Angle + 20; (* move search to next segment *) IF Damage > Old_Damage THEN BEGIN (* Under attack *) Old_Damage := Damage; (* Get latest Damage value *) Move; (* Get out of here!! *) END; UNTIL Dead or Winner; The "Move" reference above would call a separate procedure that would move the robot to another position on the battlefield where it will hopefully be safer. This procedure will be given a little latter as another example. OTHER SPECIAL P-ROBOTS FUNCTIONS AND PROCEDURES TIME The built-in Time function returns the current time as measures by the P-ROBOTS' CPU cycles. By using this function, you should be able to calculate the speed of your enemies. The value returned by this function is restricted to being in the range 0 to 32767 and when it gets to 32767 it starts again at zero. An example of how you might get this value is as follows: Start_Time := Time; DISTANCE Since your robot will frequently find it useful to be able to calculate distances from one point on the battlefield to another, P-ROBOTS provides a built-in function to do it: Distance(X1,Y1,X2,Y2) 7 would return the integer distance from the point X1,Y1 to the point X2,Y2. ANGLE_TO The Angle_To function will return the angle to a point on the battlefield from your robot's current position. The value returned will be an integer in degrees from 0 to 359. As an example of how both the Distance and Angle_To functions might be used, consider the following procedure that will move your robot to the point X,Y on the battlefield: PROCEDURE GoTo(X, Y : Integer);(* Go to location X,Y *) VAR Heading : Integer; BEGIN (* Find the heading we need to get to the desired spot. *) Heading := Angle_To(X, Y); (* Keep traveling at top speed until we are within 150 meters. *) WHILE (Distance(Loc_X, Loc_Y, X, Y) > 150) DO Drive(Heading, 100); (* Cut speed, and creep the rest of the way. *) WHILE (Distance(Loc_X, Loc_Y, X, Y) > 20) DO Drive(Heading, 20); (* Stop driving, should coast to a stop. *) Drive(Heading, 0); (* I.E., Stop *) END; (* GoTo(X,Y) *) RANDOM The function Random(limit) returns a random integer between 0 and limit. As an example, the following procedure will cause your robot to move to a random spot on the battlefield: PROCEDURE Move; (* Move to a random spot on the playing field. *) VAR x, y : Integer; BEGIN x := Random(900) + 50; y := Random(900) + 50; GoTo(x, y); END; (* Move *) Notice that the Move procedure makes use of the GoTo(X,Y) procedure developed in the previous example. TRIG FUNCTIONS P-ROBOTS has several standard Trig functions that will be of value to a clever robot, specifically: Sin(degree) 8 will return the real value of the Sin of an angle of degree where degree is an integer from 0 to 359. Cos(degree) will return the real value of the Cos of an angle of degree where degree is an integer from 0 to 359. ArcTan(ratio) will the angle in integer degrees that has a Tan of ratio. INFLICTING DAMAGE Your robot can be damaged by only two things: collisions and missiles. The level of damage is given by the following table: 2% -- A collision with another robot (both robots in a collision receive damage) or one of the battlefield walls. A collision also causes the robot to stop cold, i.e., its speed is reduced instantly to 0. 3% -- A missile explodes within a 40 meter radius. 5% -- A missile explodes within a 20 meter radius. 10% -- A missile explodes within a 5 meter radius. Damage is inflicted on ALL robots within these distances. That means that if one of your own missiles explodes within 40 meters of your robot, it causes damage. Using sloppy programming logic, it is possible for your robot to commit suicide by firing missiles too close to itself. For example, your robot would not last long with this code: Drive(Angle,100); WHILE (Loc_X < 999) DO Cannon(Angle,Scan(Angle,10)); Damage is cumulative, and cannot be repaired. However, a robot does not loose any mobility, fire potential, etc. at high damage levels. In other words, a robot at 99% damage performs equally as well as a robot with no damage. However, when the damage level gets to 100% your robot is dead and it is out of the current competition. PUTTING IT ALL TOGETHER Here is a complete sample robot named HotShot: 9 PROCEDURE HotShot; (* Author: David Malmberg Strategy: Stay in one place. Find a foe. Take a shot. Keep improving aim and shooting until foe is lost from sights. Then move sights (scanning) to adjacent target area. If hit, then move to another random position on playing field. If the Robot scans two complete circles (720 degrees) without finding a foe in shooting range, move to another spot on the field. (This will avoid "stand-offs" where opponents stay just out of range of one another.) This Robot should be VERY effective against foes which are stopped or are moving slowly. It will be less effective against Robots traveling at high speeds. *) VAR (* HotShot "Global" variables *) Angle, (* Scanning angle *) Last_Damage, (* Robot's last damage value *) Range, (* Range/Distance to foe *) Sweep, (* "Sweep count" when = 36, have scanned 720 degrees *) Delta (* Scanning arc *) : Integer; PROCEDURE GoTo(X, Y : Integer); (* Go to location X,Y on playing field. *) VAR Heading : Integer; BEGIN (* Find the heading we need to get to the desired spot. *) Heading := Angle_To(X, Y); (* Keep traveling at top speed until we are within 150 meters. *) WHILE (Distance(Loc_X, Loc_Y, X, Y) > 150) DO Drive(Heading, 100); (* Cut speed, and creep the rest of the way. *) WHILE (Distance(Loc_X, Loc_Y, X, Y) > 20) DO Drive(Heading, 20); (* Stop driving, should coast to a stop. *) Drive(Heading, 0); (* I.E., Stop *) END; (* GoTo(X,Y) *) FUNCTION Hurt : Boolean; (* Checks if Robot has incurred any new damage. *) VAR Curr_Damage : Integer; Answer : Boolean; BEGIN Curr_Damage := Damage; Answer := (Curr_Damage > Last_Damage); Last_Damage := Curr_Damage; Hurt := Answer; END; (* Hurt *) 10 PROCEDURE Move; (* Move to a random spot on the playing field. *) VAR x, y : Integer; BEGIN Sweep := 0; (* Reset Sweep counter to zero. *) x := Random(900) + 50; y := Random(900) + 50; GoTo(x, y); END; (* Move *) PROCEDURE Aim( VAR Ang : Integer; VAR Arc : Integer); (* Improve aim by doing a binary search of the target area. I.E., divide the target area in two equal pieces and redefine the target area to be the piece where the foe is found. If the foe is not found, expand the search area to the maximum arc of plus or minus 10 degrees. *) BEGIN (* Divide search area in two. *) Arc := Arc DIV 2; (* Check piece "below" target angle. *) IF Scan(Ang - Arc, Arc) <> 0 (* If foe found, redefine target angle. *) THEN Ang := Ang - Arc (* If not found, then check piece "above" target angle. *) ELSE IF Scan(Ang + Arc, Arc) <> 0 (* If foe found, redefine target angle. *) THEN Ang := Ang + Arc ELSE Arc := 10; (* If foe not found in either piece, expand search arc to +/- 10 *) END; (* Aim *) BEGIN (* HotShot Main *) (* Start scanning for foes in center of field. *) Angle := Angle_To(500, 500); Sweep := 0; (* Initialize Sweep counter to zero. *) REPEAT (* Until Dead or Winner *) Delta := 10; (* Start with widest scanning arc. *) Range := Scan(Angle, Delta); WHILE (Range > 40) AND (Range < 701) DO (* Must be far enough away to avoid self-damage. *) BEGIN Sweep := 0; (* Found foe, so reset Sweep to zero *) Aim(Angle, Delta); (* Improve aim. *) Cannon(Angle, Range); (* Fire!! *) Range := Scan(Angle, Delta); (* Is foe still in sights? *) END; Angle := Angle + 20; (* Look in adjacent target area. *) Sweep := Sweep + 1; IF Hurt OR (Sweep = 36) THEN Move; (* If hit or have scanned two full circles, move elsewhere. *) UNTIL Dead OR Winner; END; (* HotShot Main *) 11 ROBOT PROGRAMMING RULES There are several things in the above example the you should think of as rules that your robots should ALWAYS observe. 1. Your robot should be in a "self-contained" PROCEDURE with the following basic structure: PROCEDURE RoboName; {"Global" Variables} FUNCTION A; .... PROCEDURE B; .... FUNCTION Z; BEGIN {RoboName Main} .... END; {RoboName Main} Failure to follow this basic structure will cause the P-ROBOTS program and your robot to both meet a fiery death. 2. A robot should have its PROCEDURE named exactly the same name as the file with the code for the robot (except for the .PR extension). I.E., the HotShot robot procedure should be in a file named HOTSHOT.PR. Again, failure to follow this rule will cause your robot program to crash. 3. In the "main" routine for your robot, you need to have some kind of "infinite" loop that is repeat endlessly. In the sample robot, HOTSHOT, this loop is the REPEAT ... UNTIL structure: REPEAT (* Until Dead or Winner *) .... UNTIL Dead OR Winner; Another "infinite" loop that would works equally well is: WHILE (NOT Dead) AND (NOT Winner) DO BEGIN .... END; 4. Your robot source code should be very well documented with comments. 12 ADVANCED P-ROBOT FEATURES All of the robot programming ground rules and robot-specific language presented up to this point correspond to features found in C-ROBOTS by Tom Poindexter -- which was the inspiration for P-ROBOTS. After P-ROBOTS had been released for several months, users had made a number of suggestions for improvements and new features. In version 2.0 (first released in December 1989), I tried to incorporate the best suggestions. Specifically, version 2.0 adds the following improvements and new features: * Animation Speed Options * Protective Shields * Fuel Constraints * Robot Teams * Obstructions on the Battlefield * Intelligence Options NOTE: All of these new features are optional. Your old version 1.0 robots can still be used just as they have always been used. CONTROLLING THE ANIMATION SPEED Since not all computers operate at the same speed, it is very desireable to be able to control the animation speed of the robot contest. This can be done by using another command line parameter, the "/SN" parameter, where N can be either 1, 2, 3 or 4. A value of 1 corresponds to the slowest animation speed and 4 is the fastest. The normal default setting is 4 or the fastest speed. A value of 4 will normally look fine on an 8086 or 80286 computer. If you are using a 386 machine, you will probably want to use one of the slower animation speeds. For example, to run a single game between the robots: NINJA, HOTSHOT, WIMP and BLASTER at a moderately slow animation speed (i.e., a speed of 2) you would enter the command: P-ROBOTS NINJA HOTSHOT WIMP BLASTER /S2 If you are playing a series of contests (i.e., match play), you should not slow down the speed since these games are not displayed/animated anyway. PROTECTIVE SHIELDS In version 2.0 of P-ROBOTS, your robot can use a protective shield by using the command "RaiseShield". When your robot's shield is up, your robot will not incur any damage from collisions or cannon explosions. The shield may be lowered by using the command "LowerShield". The status of your robot's shield can be determined by using the built-in Boolean function, "ShieldRaised" which will return a value of TRUE or FALSE based on your robot's shield condition. For example, you might want to use the following statement in a robot program: IF NOT ShieldRaised THEN RaiseShield; Of course, there must be a "catch" to using your Shield -- or there would not be any real challenge to a robot contest. The catch is that your Shield MUST use scarce fuel resources as explained in the next section. 13 NOTE: Unlike the Starship Enterprise, your robot has only one Shield (i.e., singular) not multiple Shields (plural). If you use "Shields" (plural) in your robot programs, you will get a compiler error for an "UNKNOWN IDENTIFIER". FUEL CONSTRAINTS Many people have commented that P-ROBOTS (and C-ROBOTS before it) seemed to favor robots that used "brute force" rather than "raw cunning" -- i.e., all other things being equal, robots that fired often seem to beat robots that fired accurately. In an effort to create a little more level playing field for smart robots, I added fuel constraints to version 2.0. Under these constraints, robots that fire indiscriminately will waste valuable fuel and will ultimately run out of fuel and find themselves defenseless and at the mercy of their wiser and more fuel efficient opponents. When having a robot battle that has fuel constraints, each robot begins the contest with 1000 "jiggers" of fuel. Then during the contest, fuel is used up at the following rates: * Firing a missile takes 3 jiggers * Traveling 100 meters takes 5 jigger * Having a shield up for 200 CPU cycles takes 1 jigger In addition, if your robot's Shield is up, whenever your robot would have incurred damage from a missile or a collision, it uses twice the number of jiggers of fuel to absorb the damage as it would have incurred in damage had its Shield been down. For example, when your robot's Shield is up, absorbing a direct missile hit uses 20 jiggers of fuel; absorbing the impact of a collision with another robot uses 4 jiggers of fuel, etc. So, it is prudent for your robot to take care to avoid missiles and collisions even if its Shield is raised. The number of jiggers of each robot's fuel is displayed continuously next to the robot's name on the screen. This value may be accessed from within a robot program by using the built-in function "Fuel". For example, you might want to use the following logic in a robot program to begin a special "End-Game" strategy when your fuel gets low: IF Fuel < 200 THEN End_Game; There are several other built-in P-ROBOTS functions that may be useful when you have fuel constraints. Specifically, "LimitedFuel" will return a TRUE or FALSE based upon whether the contest your robot is playing in has fuel constraints or not. The built-in function "Meters" is like an Odometer on a car -- only it returns the number of meters your robot has traveled since the beginning of the contest. For example, you might wish to use the following command in your robot's program to invoke your "End-Game" strategy: IF LimitedFuel THEN IF (Meters > 20000) OR (Fuel < 200) THEN End_Game; 14 To have a robot contest with fuel constraints, you must use a "/F" command line parameter when you invoke your contest. For example, to run a single game between the robots: NINJA, WIMP and BLASTER with fuel constraints, you would enter the following command at the DOS prompt: P-ROBOTS NINJA WIMP BLASTER /F If you wish to have a series of 50 matches with fuel constraints between the same group of robots, you would add a "/M50" parameter to the command as follows: P-ROBOTS NINJA WIMP BLASTER /F /M50 RUNNING OUT OF FUEL When you robot runs out of fuel it does everything you might expect: it stops cold and can no longer move; it can no longer fire its cannon; and it can no longer maintain a raised shield. In other words, it is totally and absolutely defenseless. Other robots which still have fuel will make quick work of any robot that is unfortunate enough to become a "sitting duck" by running out of fuel. If all of the robots in the game run out of fuel, the game is over and the robot with the least damage (i.e., the strongest of the survivors) is declared the winner. AN EXAMPLE USING A SHIELD AND FUEL Here is an example of how the previous example robot, HOTSHOT, might be modified to use its Shield and consider Fuel constraints: PROCEDURE HotShot2; { Author: David Malmberg Strategy: Stay in one place. Find a foe. Take a shot. Keep improving aim and shooting until foe is lost from sights. Then move sights (scanning) to adjacent target area. If the Robot scans a complete circle (360 degrees) without finding a foe in shooting range, move to another spot on the field. (This will avoid "stand-offs" where opponents stay just out of range of one another.) RaiseShield when standing still and lower them when moving. When damage gets to 70 (or more) or fuel (if using fuel) gets below 200 adopt an "End-Game" strategy of moving to the lower left corner, lower shield, and continue to scan and shoot in the corner's 90 degree range. This Robot should be VERY effective against foes which are stopped or are moving slowly. It will be less effective against Robots traveling at high speeds. 15 This Robot has been designed to utilize Fuel (if it is available) to power its Shield. However, it has NOT been designed to deal effectively with Obstructions. } VAR { HotShot2 "Global" variables } Angle, { Scanning angle } Range, { Range/Distance to foe } Sweep, { "Sweep count" -- when = 18, Robot has scanned 360 degrees } Delta : Integer; { Scanning arc } PROCEDURE GOTO(x, y : Integer); { Go to location X,Y on playing field. } VAR Heading : Integer; BEGIN { Find the heading we need to get to the desired spot. } Heading := Angle_To(x, y); { Keep traveling at top speed until we are within 150 meters } WHILE (distance(loc_x, loc_y, x, y) > 150) DO drive(Heading, 100); { Cut speed, and creep the rest of the way. } WHILE (distance(loc_x, loc_y, x, y) > 20) DO drive(Heading, 20); { Stop driving, should coast to a stop. } drive(Heading, 0); {I.E., Stop} END; {GoTo(X,Y)} PROCEDURE Move; { Move to a random spot on the playing field. } VAR x, y : Integer; BEGIN Sweep := 0; { Reset Sweep counter to zero. } x := Random(900)+50; y := Random(900)+50; GOTO(x, y); END; {Move} PROCEDURE Aim( VAR Ang : Integer; VAR Arc : Integer); (* Improve aim by doing a binary search of the target area. I.E., divide the target area in two equal pieces and redefine the target area to be the piece where the foe is found. If the foe is not found, expand the search area to the maximum arc of plus or minus 10 degrees. *) BEGIN (* Divide search area in two. *) Arc := Arc DIV 2; (* Check piece "below" target angle. *) IF Scan(Ang - Arc, Arc) <> 0 (* If foe found, redefine target angle. *) THEN Ang := Ang - Arc (* If not found, then check piece "above" target angle. *) ELSE IF Scan(Ang + Arc, Arc) <> 0 (* If foe found, redefine target angle. *) THEN Ang := Ang + Arc ELSE Arc := 10; (* If foe not found in either piece, expand search arc to +/- 10 *) END; (* Aim *) 16 PROCEDURE End_Game; { Special strategy for "End Game" } BEGIN {End_Game} GoTo(0,0); {Lower Left Corner} Angle := 10; {Sweep arc from 0 to 90 degrees only} REPEAT Delta := 10; { Start with widest scanning arc. } Range := scan(Angle, Delta); WHILE (Range > 40) AND (Range < 700) DO { Must be far enough away to avoid self-damage. } BEGIN Aim(Angle, Delta); { Improve aim. } cannon(Angle, Range); { Fire!! } Range := scan(Angle, Delta); { Is foe still in sights? } END; Angle := Angle+20; { Look in adjacent target area. } IF Angle > 90 THEN Angle := 10; UNTIL Dead OR Winner; END; {End_Game} BEGIN {HotShot2 Main} RaiseShield; Angle := 0; GoTo(500, 500); { Move to center of field. } Sweep := 0; { Initialize Sweep counter to zero. } REPEAT { Until Dead or Winner } Delta := 10; { Start with widest scanning arc. } Range := scan(Angle, Delta); WHILE (Range > 40) AND (Range < 700) DO { Must be far enough away to avoid self-damage. } BEGIN Sweep := 0; { Found foe, so reset Sweep to zero } Aim(Angle, Delta); { Improve aim. } cannon(Angle, Range); { Fire!! } Range := scan(Angle, Delta); { Is foe still in sights? } END; Angle := Angle+20; { Look in adjacent target area. } Sweep := Sweep+1; IF Sweep >= 18 THEN BEGIN { If robot has scanned a full circle, move elsewhere. } LowerShield; {Don't need shield (as much) when moving} Move; END; RaiseShield; {Standing still so use shield} {"End" game strategy} IF (Fuel < 200) OR (Damage > 70) THEN End_Game; UNTIL Dead OR Winner; END; {HotShot2 Main} 17 ROBOT TEAMS One of the most intriguing suggestions that I received from version 1.0 users of P-ROBOTS was the idea of allowing two robots to act as members of the same team and to communicate with each other during the course of the battle. This option has been added to version 2.0. NOTE: For consistency and better understanding, if your robot is a member of a two robot team, the other team member is referred to as your robot's "Ally". Similarly, within your Ally's robot program, your robot would be referred to as its Ally. Robot teams may use the following special built-in P-ROBOTS functions: AllyLoc_X -- returns the current X coordinate of your Ally AllyLoc_Y -- returns the current Y coordinate of your Ally AllyDamage -- returns your Ally's current Damage level AllySpeed -- returns your Ally's current Speed AllyHeading -- returns your Ally's current Heading AllyMeters -- returns your Ally's current Meters AllyFuel -- returns your Ally's current Fuel level AllyShieldRaised -- returns TRUE or FALSE depending upon whether your Ally's shield is raised or not AllyDead -- returns TRUE or FALSE depending upon whether your Ally is Dead or not AllyAlive -- returns TRUE or FALSE depending upon whether your Ally is Alive or not In addition to using these built-in functions to learn about your Ally's status, it is also possible in version 2.0 for robots to exchange information by access the "global" array COMM[1..20]. All robots may access this array and both retrieve and store values to any of its 20 elements. Be warned however, that stuffing "garbage" into COMM's elements to sabotage the communication between opposing team members is NOT considered to be fair play!! One other piece of information is necessary in order for two robots to work together effectively as a team -- there must be some way to tell if a robot is friend or foe. The way this is done is to define a special function called "ObjectScanned" which is reset whenever your robot scans the battlefield. The value returned by ObjectScanned will be one of four specially defined values/constants: Nothing, Ally, Enemy or Obstruction. For example, to make sure that you only fire your cannon at enemy robots when you are part of a team, you might want to use statements like the following: 18 Dist := Scan(Angle, Delta); IF ObjectScanned = Enemy THEN Cannon(Angle, Dist); {Blast 'Em!!} To tell the P-ROBOTS compiler that you have an Ally and are part of a team, you need to include a statement within your robot's program that looks like: TeamAlly = "TagTeam2"; This statement tells the P-ROBOTS compiler that your Ally is named "TagTeam2". To work correctly, the robot "TagTeam2" must have a similar statement within its program that identifies your robot's name as its Ally. AN EXAMPLE OF A ROBOT TEAM Here is an example of one member of a robot team. Notice, that this robot and its Ally (named "TagTeam2") communicate by passing information through COMM[10] and COMM[11]. PROCEDURE TagTeam1; TeamAlly = "TagTeam2"; (* This statement MUST be included for teams!! *) { Author: David Malmberg Strategy: Go to a random corner, raise shield, and blast away at any robot in range. Improve aim after every successful scan. If the robot scans 20 times unsuccessfully, move to another random corner. Lower shields when moving; raise them when stopped. This robot can act individually or as part of a team with another robot that follows an identical strategy, i.e., TagTeam2. If operating as a team, the two robots communicate their corners to each other by setting COMM[10] to TagTeam1's corner and COMM[11] to TagTeam2's corner. They try to always pick different random corners. Operating from different corners, the two robots should be able to cover most of the battlefield very well. WARNING: This Robot has NOT been designed to deal with Obstructions effectively. However, it has been designed to use its Shield (if possible). } CONST NW_Corner = 1; NE_Corner = 2; SW_Corner = 3; SE_Corner = 4; 19 VAR { TagTeam1 "Global" variables } CornerX : ARRAY[1..4] OF Integer; {X coordinate of Corners} CornerY : ARRAY[1..4] OF Integer; {Y coordinate of Corners} StartAngle : ARRAY[1..4] OF Integer; {Starting scan angles for Corners} Corner, { Current Corner } Times, { Number of times robot has scanned without success for enemy } Angle, { Scanning angle } Delta, { Scanning angle width } Range { Range/Distance to foe } : Integer; PROCEDURE Initialize; { Set up Corner data } BEGIN CornerX[NW_Corner] := 10; CornerY[NW_Corner] := 990; StartAngle[NW_Corner] := 270; CornerX[NE_Corner] := 990; CornerY[NE_Corner] := 990; StartAngle[NE_Corner] := 180; CornerX[SW_Corner] := 10; CornerY[SW_Corner] := 10; StartAngle[SW_Corner] := 0; CornerX[SE_Corner] := 990; CornerY[SE_Corner] := 10; StartAngle[SE_Corner] := 90; END; {Initialize} PROCEDURE GOTO(x, y : Integer); { Go to location X,Y on playing field. } VAR Heading : Integer; BEGIN LowerShield; {Moving target is hard to hit - so lower shield} { Find the heading we need to get to the desired spot. } Heading := Angle_To(x, y); { Keep traveling at top speed until we are within 150 meters } WHILE (distance(loc_x, loc_y, x, y) > 150) DO Drive(Heading, 100); { Cut speed, and creep the rest of the way. } WHILE (distance(loc_x, loc_y, x, y) > 20) DO Drive(Heading, 20); { Stop driving, should coast to a stop. } Drive(Heading, 0); {I.E., Stop} RaiseShield; {Still target is easy to hit - so raise shield} END; {GoTo(X,Y)} 20 PROCEDURE Aim( VAR Ang : Integer; VAR Arc : Integer); (* Improve aim by doing a binary search of the target area. I.E., divide the target area in two equal pieces and redefine the target area to be the piece where the foe is found. If the foe is not found, expand the search area to the maximum arc of plus or minus 10 degrees. *) BEGIN Arc := Arc DIV 2; (* Divide search area in two. *) (* Check piece "below" target angle. *) IF Scan(Ang - Arc, Arc) <> 0 (* If foe found, redefine target angle. *) THEN Ang := Ang - Arc (* If not found, then check piece "above" target angle. *) ELSE IF Scan(Ang + Arc, Arc) <> 0 (* If foe found, redefine target angle. *) THEN Ang := Ang + Arc ELSE Arc := 10; (* If foe not found in either piece, expand search arc to +/- 10 *) END; (* Aim *) PROCEDURE Do_Corner; { Scan and shoot from corner } BEGIN {Do_Corner} Times := 0; {Count of unsuccessful scans} Angle := StartAngle[Corner] + 10; {Starting angle for scanning} REPEAT Delta := 10; { Start with widest scanning arc. } Range := scan(Angle, Delta); WHILE (Range > 40) AND (Range < 700) DO { Must be far enough away to avoid self-damage. } BEGIN Aim(Angle, Delta); { Improve aim. } IF ObjectScanned = Enemy THEN cannon(Angle, Range); { Fire!! } Range := scan(Angle, Delta); { Is foe still in sights? } END; Angle := Angle + 20; { Look in adjacent target area. } IF (Angle > (StartAngle[Corner] + 90)) THEN Angle := StartAngle[Corner] + 10; Times := Times + 1; UNTIL Times > 20; { Leave after 20 unsuccessful scans } END; {Do_Corner} BEGIN {TagTeam1 Main} Initialize; COMM[11] := 0; {Set Ally's corner (if any) to zero} COMM[10] := 0; {Communicate my corner to Ally} REPEAT REPEAT Corner := Random(3) + 1; {Pick a corner} UNTIL Corner <> COMM[11]; {Need different corner than Ally} COMM[10] := Corner; {Communicate my corner to Ally (if any)} GoTo(CornerX[Corner], CornerY[Corner]); { Move to selected corner. } Do_Corner; UNTIL Dead OR Winner; END; {TagTeam1 Main} 21 OBSTRUCTIONS ON THE BATTLEFIELD Another new feature added in version 2.0 of P-ROBOTS is the possibility of randomly placed Obstructions on the battlefield. This option is selected by using the "/ON" command line parameter, where N can be 1, 2 or 3 -- corresponding to 1, 2 or 3 Obstructions. Each Obstruction will be a randomly sized and placed rectangle. Be warned however, that using Obstructions in your battles will s..l..o..w.. down the speed of the battle considerably. The logic required for P-ROBOTS to deal with Obstructions is fairly extensive and very computationally intense. So the more Obstructions your battle has, the slower it will run. If your robot runs into one of these Obstructions, it will be stopped cold and incur Damage (if its Shield is down) -- just as if it ran into one of the battlefield walls. A scanner will not be able to see beyond an Obstruction; nor will it be possible to shoot a missile past an Obstruction. Therefore, it will be possible for a robot to "hide" from enemy scanners and missile by "hugging" the walls of an Obstruction. More often than not, a scanner will only "see" the Obstruction and not the robot. Obstructions add a whole new dimension to the possible problems and opportunities that a robot may face!! Your robot will be able to determine where the Obstructions are by scanning and then checking the value returned by the function "ObjectScanned". For example, you might use the following Boolean function to determine if the direction your robot is traveling (denoted below by the variable "Heading") is clear of Obstructions for the next 100 meters: FUNCTION ClearAhead : Boolean; BEGIN ClearAhead := (Scan(Heading,2) > 100) OR (ObjectScanned <> Obstruction); END; {ClearAhead} AN EXAMPLE DEALING WITH OBSTRUCTIONS Below is our old friend, HOTSHOT, adapted to deal with the problem of Obstructions by using logic to move around them. Notice, that we can no longer use the same routine we have been using to go to a point X, Y on the battlefield -- because that point might be inside an Obstruction -- in which case our robot would commit suicide by repeatedly "banging its head" against the wall of the Obstruction. To see how this problem is overcome, see the Procedure "Ramble" in the listing. 22 PROCEDURE HotShot3; { Author: David Malmberg Strategy: Stay in one place. Find a foe. Take a shot. Keep improving aim and shooting until foe is lost from sights. Then move sights (scanning) to adjacent target area. If the Robot scans a complete circle (360 degrees) without finding a foe in shooting range, move to another spot on the field. (This will avoid "stand-offs" where opponents stay just out of range of one another.) RaiseShield (if available) when standing still and lower them when moving. When damage gets to 70 (or more) or fuel (if using fuel) gets below 200 adopt an "End-Game" strategy of moving to the lower left corner, lower shield, and continue to scan and shoot in the corner's 90 degree range. This Robot should be VERY effective against foes which are stopped or are moving slowly. It will be less effective against Robots traveling at high speeds. This Robot has been designed to utilize Fuel (if it is available) to power its Shield. It has also been designed to deal with Obstructions (if any) by moving around them. } VAR { HotShot3 "Global" variables } Angle, { Scanning angle } Range, { Range/Distance to foe } Sweep, { "Sweep count" -- when = 18, Robot has scanned 360 degrees } Delta : Integer; { Scanning arc } PROCEDURE GOTO(X, Y : Integer); { Go to location X,Y on playing field. } VAR Heading : Integer; BEGIN { WARNING: If the point X,Y is inside an Obstruction then } { executing this routine will cause the Robot to commit } { suicide by repeatedly running into the wall of the Obstruction. } { Find the heading we need to get to the desired spot. } Heading := Angle_To(x, y); { Keep traveling at top speed until we are within 150 meters } WHILE (distance(loc_x, loc_y, x, y) > 150) DO drive(Heading, 100); { Cut speed, and creep the rest of the way. } WHILE (distance(loc_x, loc_y, x, y) > 20) DO drive(Heading, 20); { Stop driving, should coast to a stop. } drive(Heading, 0); {I.E., Stop} END; {GoTo(X,Y)} 23 PROCEDURE Ramble(X, Y : Integer); { Move to X, Y (if possible) on the playing field } { by avoiding Obstructions - if any. } VAR Heading, Tries, Dist : Integer; BEGIN Tries := 0; Heading := Angle_To(X, Y); Drive(Heading, 50); {Start off toward X,Y} Dist := Scan(Heading, 5); REPEAT IF ObjectScanned = Obstruction THEN BEGIN REPEAT Heading := Heading + 10; Dist := Scan(Heading, 5); UNTIL ObjectScanned <> Obstruction; Drive(Heading, 50); {Minimum speed to turn freely} END; Heading := Angle_To(X, Y); Dist := Scan(Heading, 5); Tries := Tries + 1; UNTIL (ObjectScanned <> Obstruction) OR (Tries > 20); IF (ObjectScanned <> Obstruction) THEN GOTO(X,Y); END; {Ramble} PROCEDURE Move; { Move to a random spot on the playing field. } VAR x, y : Integer; BEGIN Sweep := 0; { Reset Sweep counter to zero. } x := Random(900)+50; y := Random(900)+50; Ramble(x, y); END; {Move} PROCEDURE Aim(VAR Ang : Integer; VAR Arc : Integer); { Improve aim by doing a binary search of the target area. I.E., divide the target area in two equal pieces and redefine the target area to be the piece where the foe is found. If the foe is not found, expand the search area to the maximum arc of plus or minus 10 degrees. } BEGIN IF ObjectScanned = Enemy THEN BEGIN Arc := Arc DIV 2; { Divide search area in two. } IF scan(Ang-Arc, Arc) <> 0 { Check piece "below" target angle. } THEN Ang := Ang-Arc { If foe found, redefine target angle. } ELSE IF scan(Ang+Arc, Arc) <> 0 { Check piece "above" Ang. } THEN Ang := Ang+Arc { If foe found, redefine target angle. } ELSE Arc := 10; { Foe not found in either piece, expand search area to max arc. } END ELSE Arc := 10; END; {Aim} 24 PROCEDURE End_Game; { Special strategy for the "End Game" } BEGIN {End_Game} Ramble(0,0); {Lower Left Corner} Angle := 10; {Sweep arc from 0 to 90 degrees only} REPEAT Delta := 10; { Start with widest scanning arc. } Range := scan(Angle, Delta); WHILE (Range > 40) AND (Range < 700) AND (ObjectScanned = Enemy) DO { Must be far enough away to avoid self-damage. } BEGIN Aim(Angle, Delta); { Improve aim. } IF ObjectScanned = Enemy THEN cannon(Angle, Range); { Fire!! } Range := scan(Angle, Delta); { Is foe still in sights? } END; Angle := Angle+20; { Look in adjacent target area. } IF Angle > 90 THEN Angle := 10; UNTIL Dead OR Winner; END; {End_Game} BEGIN {HotShot3 Main} RaiseShield; Angle := 0; Ramble(500, 500); { Move to center of field -- if possible. } Sweep := 0; { Initialize Sweep counter to zero. } REPEAT { Until Dead or Winner } Delta := 10; { Start with widest scanning arc. } Range := scan(Angle, Delta); WHILE (Range > 40) AND (Range < 700) AND (ObjectScanned = Enemy) DO { Must be far enough away to avoid self-damage. } BEGIN Sweep := 0; { Found foe, so reset Sweep to zero } Aim(Angle, Delta); { Improve aim. } IF ObjectScanned = Enemy THEN cannon(Angle, Range); { Fire!! } Range := scan(Angle, Delta); { Is foe still in sights? } END; Angle := Angle+20; { Look in adjacent target area. } Sweep := Sweep+1; IF Sweep = 18 THEN BEGIN { If robot has scanned a full circle, move elsewhere. } LowerShield; {Don't need shield (as much) when moving} Move; END; RaiseShield; {Standing still so use shield} {"End" game strategy} IF (Fuel < 200) OR (Damage > 70) THEN End_Game; UNTIL Dead OR Winner; END; {HotShot3 Main} 25 INTELLIGENCE OPTIONS The final new feature added in version 2.0 of P-ROBOTS is the possibility of varying the intelligence of your robots' "on-board" computers. This option is selected by using the "/IN" command line parameter, where N can be 1, 2, 3 up to 10. What this option really does is vary the number of instructions your robots' "on-board" computers can execute in any given amount of "time" during the game. For example, with the lowest intelligence setting (i.e., a value of 1), your robots' "on-board" computer might execute 10 instructions during the time it travels 10 meters; while at the highest intelligence setting (of 10), 100 instructions might be executed during the same 10 meter travel period. Obviously, at higher intelligence settings your robot will be able to perform more calculations and make more effective use of complex strategies and algorithms. For example, to run a single game between the robots: NINJA, WIMP and BLASTER with an intelligence setting of 5 (i.e., very smart robots), you would enter the following command at the DOS prompt: P-ROBOTS NINJA WIMP BLASTER /I5 If you wish to have a series of 50 matches with the same intelligence setting between the same group of robots, you would add a "/M50" parameter to the command as follows: P-ROBOTS NINJA WIMP BLASTER /I5 /M50 The default intelligence setting is 1 -- the lowest value and the standard setting used in version 1.0 of P-ROBOTS. You should not think of this lowest setting as having "dumb" or "stupid" robots. Robots operating at an intelligence level of 1 are still quite smart. To use an analogy from personal computing, you might think of an intelligence setting of 1 as having each robot in the game equipped with an Intel 8088 microprocessor, running at 4.77 megahertz -- i.e., the same speed and processor used in the original IBM PC back in 1981. By comparison, using an intelligence setting of 10 is like putting a 33 megahertz 80386 in your robot. Be warned however -- there is a price to be paid for increased robot intelligence -- it slows down the apparent speed of the game. At higher intelligence settings, the computer you will be running P-ROBOTS on will have to execute more instructions (on your robot's behalf) while the robot travels 10 meters, and the game will appear to take longer for your robot to travel that same 10 meters. This may or may not be a problem for you depending upon the speed of the computer you are using to play P-ROBOTS. There is one other potential problem with using various intelligence settings in P- ROBOTS. This is the problem of inconsistent performance of your robots. For example, you may have a robot that beats everything in sight at higher intelligence levels and gets beat by everything in sight at lower levels -- or vice versa. Unfortunately, you can not have it both ways. My advice to you is to select an intelligence level that plays at an acceptable display/animation speed on your computer and stick to it. 26 APPENDIX I: COMPILER ERRORS The PASCAL compiler in P-ROBOTS will report any syntax or logic errors that it encounters during the compilation process. Then the program will terminate without playing the game. A listing of the robot(s) source code with the errors marked in the source will then be found in a file named LISTING.TXT on the disk/directory where P-ROBOTS is being run. Because P-ROBOTS is going to write to the disk, you must NOT have a "write-protect" tab on the disk or you will get a fatal error whenever you try to run the program. This file should be printed out and studied and your corrections made to your robot source files. Do NOT make your corrections on the LISTING.TXT file! The compiler only compiles robot files (i.e., files with a ".PR" extension). If your robot(s) source code did not have any errors (that the compiler could detect) there will not be a LISTING.TXT file created and the P-ROBOTS program will execute normally and the contest between the various robots will be played. The compiler will report the following errors by number: 0. UNDEFINED IDENTIFIER 1. MULTIPLE DEFINITION OF THIS IDENTIFIER 2. EXPECTED AN IDENTIFIER 3. PROGRAM MUST BEGIN WITH "PROGRAM" 4. EXPECTED CLOSING PARENTHESIS ")" 5. EXPECTED A COLON ":" 6. INCORRECTLY USED SYMBOL 7. EXPECTED IDENTIFIER OR THE SYMBOL "VAR" 8. EXPECTED THE SYMBOL "OF" 9. EXPECTED AN OPENING PARENTHESIS "(" 10. EXPECTED IDENTIFIER, "ARRAY" OR "RECORD" 11. EXPECTED AN OPENING BRACKET "[" 12. EXPECTED A CLOSING BRACKET "]" 13. EXPECTED ".." WITHOUT INTERVENING BLANKS 14. EXPECTED A SEMICOLON ";" 15. BAD RESULT TYPE FOR A FUNCTION 16. EXPECTED AN EQUAL SIGN "=" 17. EXPECTED BOOLEAN EXPRESSION 18. CONTROL VARIABLE OF THE WRONG TYPE 19. MUST BE MATCHING TYPES 20. "OUTPUT" IS REQUIRED IN PROGRAM HEADING 21. THE NUMBER IS TOO LARGE 22. EXPECT PERIOD ".", CHECK BEGIN-END PAIRS 23. BAD TYPE FOR A CASE STATEMENT 24. ILLEGAL CHARACTER 25. ILLEGAL CONSTANT OR CONSTANT IDENTIFIER 26. ILLEGAL ARRAY SUBSCRIPT (CHECK TYPE) 27. ILLEGAL BOUNDS FOR AN ARRAY INDEX 28. INDEXED VARIABLE MUST BE AN ARRAY 29. EXPECTED A TYPE IDENTIFIER 30. UNDEFINED TYPE 31. VAR WITH FIELD SELECTOR MUST BE RECORD 32. EXPECTED TYPE "BOOLEAN" 33. ILLEGAL TYPE FOR ARITHMETIC EXPRESSION 27 34. EXPECTED INTEGER FOR "DIV" OR "MOD" 35. INCOMPATIBLE TYPES FOR COMPARISON 36. PARAMETER TYPES DO NOT MATCH 37. EXPECTED A VARIABLE 38. A STRING MUST HAVE ONE OR MORE CHAR 39. NUMBER OF PARAMETERS DO NOT MATCH 40. INVALID "TeamAlly" NAME FORMAT 41. ILLEGAL PARAMETERS TO "WRITE" 42. PARAMETER MUST BE OF TYPE "REAL" 43. PARAMETER MUST BE OF TYPE "INTEGER" 44. EXPECTED VARIABLE OR CONSTANT 45. EXPECTED A VARIABLE OR PROCEDURE 46. TYPES MUST MATCH IN AN ASSIGNMENT 47. CASE LABEL NOT SAME TYPE AS CASE CLAUSE 48. ARGUMENT TO STD. FUNCTION OF WRONG TYPE 49. THE PROGRAM REQUIRES TOO MUCH STORAGE 50. ILLEGAL SYMBOL FOR A CONSTANT 51. EXPECTED BECOMES ":=" 52. EXPECTED "THEN" 53. EXPECTED "UNTIL" 54. EXPECTED "DO" 55. EXPECTED "TO" OR "DOWNTO" 56. EXPECTED "BEGIN" 57. EXPECTED "END" 58. EXPECTED ID, CONST, "NOT" OR "(" 59. "INPUT" IS REQUIRED IN PROGRAM HEADING 60. ILLEGAL (CONTROL) CHARACTER PRESENT IN SOURCE Not all of the above error messages will be used in P-ROBOTS because the compiler has been modified to not allow certain kinds of PASCAL statements. For example, since P-ROBOTS does not allow READs and WRITEs you will not get the above error messages that are normally associated with READ and WRITE. If you attempt to READ or WRITE in a P-ROBOTS program you will get an error message number zero -- "UNDEFINED IDENTIFIER". Also, remember not to use PASCAL "reserved" words as variable or procedure names. I.E., variables named BEGIN, ARRAY, DO, FOR, etc. will cause strange error messages. On very rare occasions, you may get another kind of compiler error if the robots' source code you are currently trying to compile is so "verbose" that it causes the one of the compiler's tables to overflow. When this happens, you will be given an error message which identifies which specific table has been over flowed. The limits for these tables are as follows: 400 Identifiers (Variables, Constants, Procedures and Functions) 40 Procedures or Functions 40 Real Constants 60 Arrays 7 Levels of "Nested" Procedures or Functions 5000 "Compiled" P-Code instructions These limits apply to the total number of identifiers (etc.) for all of the robots you have in the current contest. 28 APPENDIX II: RUN-TIME ERRORS When using P-ROBOTS it is possible to get two kinds of run-time errors. The first kind (and probably the most frequent) is an error that occurs within the P-ROBOTS program itself when you try to do something that the P-Code compiler within P-ROBOTS objects to -- like trying to divide by zero. The second kind of run-time error is generated by Turbo Pascal. These errors are due to situations like not having enough memory or disk space to run the P-ROBOTS program. Each of these types of errors will be discussed below. P-ROBOTS RUN-TIME ERRORS It is possible that the P-ROBOTS compiler will detect an error during the game. These are known as "run-time" errors and they will cause the game to terminate and an error message to be printed. The following kinds of run-time errors will be caught and reported: 1. DIVIDE BY 0 For example, if Delta_X had a value of zero in the following program statement, you would get a "DIVIDE BY 0" error: Target_Angle := ArcTan(Delta_Y/Delta_X); 2. UNDEFINED CASE For example, if the variable X had a value of 12 below you would get an "UNDEFINED CASE" error: CASE X OF 1 : ..... 2 : ..... 3 : ..... . . 10 : ..... END; {CASE} 3. INVALID INDEX For example, a reference to the tenth element of an array (i.e., Spot[10]) that was only defined to have the elements one through five (i.e., Spot : ARRAY[1..5] OF INTEGER;) would cause an "INVALID INDEX" error. 29 4. STORAGE OVERFLOW You would only get a "STORAGE OVERFLOW" error if one (or more) of your robots in the current contest was making too many recursive calls to the same procedure or function or was evaluating a large number of very, very complex assignment statements so that the robot's "stack" space was exceeded. If you get this error, check your overall robot logic -- there must be a better way! TURBO PASCAL RUN-TIME ERRORS Here are the run-time errors that might be generated by Turbo Pascal: 101 "Disk Write Error" -- You would get this error (probably) because you do not have enough room on your disk to contain the complete LISTING.TXT file (i.e., the error listing) and your disk became full. 203 "Heap Overflow Error" -- You probably don't have enough free memory. P-ROBOTS needs at least 384K of free memory (i.e, after counting all of the memory residents programs). 30 APPENDIX III: COMMON PROBLEMS If P-ROBOTS is not doing what you think it should do, check for these common problems: 1. Leaving a "write-protect" tab on the game disk will cause a fatal crash. There needs to be a way for the LISTING.TXT file (i.e., the error listing) to be written on the disk. Also, make sure you have enough disk space to contain the LISTING.TXT file. 20K of available disk space should be plenty of room. 2. Your robot must be a self-contained PASCAL PROCEDURE with the same name as the file (but without the .PR extension). 3. Your robot must have an "infinite" loop in the "main" routine. 4. Don't commit robot "suicide" by firing your cannon for a range of zero. For example: Drive(Angle,100); WHILE (Loc_X < 999) DO Cannon(Angle,Scan(Angle,10)); will cause your robot to commit suicide. 5. You need to have at least 384K of free memory in order to run P-ROBOTS. If you don't have enough memory, you will get a Turbo Pascal run-time error number 203. 31 APPENDIX IV: THE P-ROBOTS PASCAL LANGUAGE "NORMAL" PASCAL P-ROBOTS allows a relatively rich subset of the "normal" PASCAL language. Predefined types include REAL, INTEGER, and BOOLEAN. CONSTants, RECORDs and user-defined TYPEs are allowed. ARRAYs are allowed. Comments may be added to a program by enclosing text with braces { }, or (* *) pairs. Variable and other identifier names may have up to 10 significant characters. Arithmetic operators include: +, -, *, /, DIV and MOD. Comparison operators include: >, <, <>, =, <=, and >=. Boolean operators include: AND, OR, and NOT. Control statements/structures include: CASE, FOR-TO-DO, FOR-DOWNTO-DO, IF-THEN, IF-THEN-ELSE, REPEAT-UNTIL, and WHILE-DO. Functions and Procedures may or may not have parameters. If a Function or a Procedure has parameters, these parameters may be passed by value or by reference (i.e., a VAR parameter). Procedures and Functions may be "nested" to a maximum of seven levels. Recursion is allowed. Pre-defined Functions include: TRUE, FALSE, ABS, SQR, ODD, SUCC, PRED, ROUND, TRUNC, SIN, COS, EXP, LN, SQRT, ARCTAN, and RANDOM. All of these Functions have the same interpretation in P-ROBOTS as in standard PASCAL, except for the various Trig functions which use degrees in P-ROBOTS, rather than radians. The following are NOT allowed in P-ROBOTS and will generate error messages: CHAR, STRING, enumerated types, subranges, pointers, variant records, PACKED, sets, IN, files, input, output, GET, PUT, READ, WRITE, WITH, LABEL, GOTO. UNIQUE P-ROBOTS PASCAL PROCEDURES AND FUNCTIONS Alive -- returns a TRUE or FALSE depending upon whether your robot is alive or not. Ally -- a pre-defined P-ROBOTS "constant" which is one of the values returned by the "ObjectScanned" function. AllyAlive -- returns TRUE or FALSE depending upon whether your Ally is Alive or not. AllyDamage -- returns your Ally's current Damage level. AllyDead -- returns TRUE or FALSE depending upon whether your Ally is Dead or not. 32 AllyFuel -- returns your Ally's current Fuel level. AllyHeading -- returns your Ally's current Heading. AllyLoc_X -- returns the current X coordinate of your Ally. AllyLoc_Y -- returns the current Y coordinate of your Ally. AllyMeters -- returns your Ally's current Meters. AllyShieldRaised -- returns TRUE or FALSE depending upon whether your Ally's shield is raised or not. AllySpeed -- returns your Ally's current Speed. Angle_To(X, Y) -- return to angle in degrees form your robot's current position to the point X, Y on the battlefield. Cannon(degree, range); -- fires a missile at an angle of "degree" and for a distance of "range". Damage -- returns the value of your robot's current damage level. Dead -- returns a TRUE or FALSE depending upon whether your robot is dead or not. Distance(X1, Y1, X2, Y2) -- returns the distance in meters from the point X1, Y1 on the battle field to the point X2, Y2. Drive(degree, speed); -- causes your robot to move in the direction given by "degree" at a specified "speed". Enemy -- a pre-defined P-ROBOTS "constant" which is one of the values returned by the "ObjectScanned" function. Fuel -- returns the current value of your robot's fuel level in "jiggers". LimitedFuel -- returns TRUE or FALSE depending upon whether your current battle has fuel constraints or not. LowerShield; -- causes your robot's shield to be lowered. Meters -- returns the cumulative number of meters that your robot has traveled during the current battle. Nothing -- a pre-defined P-ROBOTS "constant" which is one of the values returned by the "ObjectScanned" function. ObjectScanned -- returns the type of object that was found by the most recent "Scan" call (if any). The result returned can have the "constant" values: Nothing, Ally, Enemy or Obstruction. Obstruction -- a pre-defined P-ROBOTS "constant" which is one of the values returned by the "ObjectScanned" function. 33 RaiseShield; -- causes your robot's shield to be raised. Random(limit) -- returns a random integer in the range of zero to "limit". Scan(degree, resolution) -- returns the distance in meters to any other robot or obstruction that is within the "viewing" arc/angle of "degree" +/- "resolution". If nothing is scanned then the function "Scan" returns a value of zero. ShieldRaised -- returns TRUE or FALSE depending upon whether your robot's shield is up or down. Time -- returns the current CPU cycle count. This function can be used to time various events, speeds, etc., within your robot program. 34 APPENDIX V: A BLATANT "PLUG" FOR ANOTHER SOFTWORKS PRODUCT The Adventure Game Toolkit is designed to allow you to create and play your own text adventure games. Once created, your adventure games can be shared with and enjoyed by others -- even if they do not have a copy of the Adventure Game Toolkit themselves. The Adventure Game Toolkit (AGT) began life as a program by Mark Welch called the Generic Adventure Game System (GAGS). Using GAGS it was possible for the non-programmer to develop complete adventure games using a fixed (but relatively large) vocabulary of action verbs. David Malmberg took GAGS and made a number of enhancements including the ability to customize the vocabulary and to program complex conditional tests and a rich assortment of actions and messages using a special metalanguage (designed specifically for writing adventure games). The current Adventure Game Toolkit combines the best features of both approaches to enable the user to create two distinct levels of adventure games: (1) Standard Level games that require no programming experience (honestly!), only a fertile imagination. These Standard Level games follow the original GAGS format and only require that the user generate the game using a word processor or text editor to describe the various locations, objects and results of actions that collectively make up the game. (2) Professional Level games that also make use of the special adventure game metalanguage to create games as complex and rich as the game designer's imagination and prose style will allow. These games should be technically comparable with the published text adventure games from firms like Infocom. FEATURES OF THE ADVENTURE GAME TOOLKIT AGT has a number of features that make it a very comprehensive adventure product. These features make AGT more powerful, more professional and easier to use than any previously available text adventure game development system. Some of these key features are: POWERFUL * Big, complex games with up to 200 locations, 100 inanimate objects (e.g., treasures, swords, lakes, trees, books, etc.) and 100 animate objects (e.g., people, animals or creatures). * Large standard vocabulary with potential to define many more words unique to a specific adventure. Typical games can have a vocabulary of 500 words or more. 35 * Sophisticated parser that can understand (1) complex input commands including pronouns (IT, HIM, HER, THEM, MY and ITS), and (2) compound commands separated by AND or THEN or punctuation symbols, and (3) commands addressed to characters within the game. Here are a few examples of commands AGT can handle with ease: GET THE FLASH LIGHT AND THEN SWITCH IT ON DROP THE FOOD, THE KEY AND THE BOTTLE THEN UNLOCK THE DOOR WITH THE BRASS KEY AND THEN LEAVE PUT ON THE CLOAK, THEN EXAMINE IT; READ ITS LABEL PLACE THE GREEN ROCK AND THE SMALL PEBBLE BEHIND THE TREE ENTER THE HOUSE; GET ALL; EXIT; SOUTH; SOUTH THEN DOWN SULU, SET A COURSE FOR ALPHA 14 SCOTTY, BEAM DOWN A TRICORDER AND THE QWERTY MODULE * Special, English-like metalanguage (especially developed for writing Adventure games) that gives the game designer total control and flexibility in the development of his/her games. * Source code available to Registered Users. Over 12,000 lines of Turbo Pascal 4.0/5.0/5.5 that may be customized to fit the game designer's unique needs. PROFESSIONAL * "Look and feel" of Infocom adventure games with similar screen layout and standard vocabulary and routines. * Automatic screen adaptation to use either a color or a monochrome monitor. Color combinations may be specified by the game designer or by the player during the game. * Predefined function and cursor keys to input frequently used commands and move directions. * SCRIPT and UNSCRIPT commands to echo game output to printer. EASY-TO-USE * Large library of completed games that can be enjoyed simply as great entertainment or used as a platform by the game designer to build upon and/or learn from. * Professionally written documentation totalling about 200 pages. Has numerous examples that unveil the "secrets" of great adventure writers. 36 HOW TO GET A COPY OF THE ADVENTURE GAME TOOLKIT The Adventure Game Toolkit (AGT) is distributed as "Shareware". Copies can be found on many electronic bulletin boards and time-sharing services including Genie, CompuServe and BIX. AGT is also available by mail directly from the authors at: Softworks 43064 Via Moraga Mission San Jose, California 94539 You can also order by phone using your Mastercard or VISA to (415) 659-0533, 9:00 AM to 8:00 PM, PST ONLY. The price list for various versions/options of AGT is as follows: 1. AGT Registration .............................. @ $ 20.00 ea $ ______ includes: (1) Notice of all future AGT upgrades, new AGT Adventures and related AGT products. (2) Latest version of the program, sample Adventure game source files (CAVE, CRUSADE, UNDERGRD, ALICE and others), and summary documentation on disk. Over one megabyte of program and data files -- ARCed on two disks. Normally, these disks will not be sent until the next AGT upgrade. If you wish these disks sent immediately, please indicate so in your letter or call. (3) Telephone support from 7:00 to 9:00 PST (M-F). (4) A warm glow from having supported at least one of the many Shareware products you probably use. (5) The AGT authors' eternal gratitude. 2. Above with printed AGT manual ................ @ $ 35.00 ea $ ______ includes: Above items plus printed manual about 200 pages long with numerous detailed examples on how to use the Adventure Game Toolkit to create very professional and very clever Adventure games. The printed AGT manual has approximately twice the amount of information as contained in the summary disk documentation. 3. Printed AGT manual (Only) .................... @ $ 20.00 ea $ ______ 4. UPGRADE to the newest AGT version (Only) ..... @ $ 12.00 ea $ ______ includes: Latest version of the program, sample Adventure game source files (CAVE, CRUSADE, UNDERGRD, ALICE and others), and summary documentation on disk. Over one megabyte of program and data files -- ARCed on two disks. 5. AGT Turbo Pascal 4.0/5.0 source code ......... @ $ 50.00 ea $ ______ includes: Turbo Pascal 4.0/5.0/5.5 source code for AGT's COMPILE and RUN programs. Over 12,000 lines of Turbo Pascal source code. YOU MUST BE A REGISTERED AGT USER TO ORDER THE SOURCE CODE! Orders are normally shipped by US mail at no additional charge. For UPS shipment, please add $4.00..........@ $ 4.00 ea $ ______ For shipments outside the United States, add $ 8.00 ea $ ______ Subtotal $ ______ (California residents please add 7 1/4% sales tax) Tax $ ______ TOTAL $ ______ 37 Payment by: ( ) Check ( ) MasterCard ( ) VISA ( ) Cash Be sure to specify the computer/disk version desired: _____ Macintosh _____ Atari ST _____ IBM 5 1/4 _____ IBM 3 1/2 Name: _______________________________________________________________ Address: _______________________________________________________________ : _______________________________________________________________ State: ______________________________ Zip:____________________________ Day Phone: ____________________________ Eve: _____________________________ Card #: _________________________________ Exp. Date: __________________ Signature of cardholder: _________________________________________________ 38 APPENDIX VI: ABOUT THE AUTHOR David Malmberg has been active in the world of personal computer since 1977. He is the author or co-author of six published software products. His most successful products were the Turtle Graphics series published by HESware. These two programs have sold over 80,000 copies world-wide, been translated into Spanish, and won two Consumer Electronic Software Showcase awards as some of the best software of 1983. These programs have been widely used in schools to teach computer literacy to children and other computer novices. His most recent software product was the Adventure Game Toolkit written with Mark Welch. The Adventure Game Toolkit is also available from Softworks. Dave has also published numerous articles and programs in various computer magazines. He has been a Contributing Editor of both COMPUTE!'s HOME & EDUCATIONAL COMPUTING and MICRO magazines. He was one of the principal authors of COMPUTE!'s FIRST BOOK OF VIC, the best selling computer book of 1983. He has written regular columns on educational uses of computers and on LOGO for COMMODORE and POWER/PLAY magazines. 39