Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!adobe!hawley From: hawley@adobe.COM (Steve Hawley) Newsgroups: comp.sys.mac.games Subject: Re: Robot games... Message-ID: <13962@adobe.UUCP> Date: 11 Apr 91 16:56:16 GMT References: <1991Apr7.212327.6218@en.ecn.purdue.edu> <112421@unix.cis.pitt.edu> <1991Apr8.154729.24914@uokmax.ecn.uoknor.edu> <112698@unix.cis.pitt.edu> <1991Apr9.174522.10940@santra.uucp> <1991Apr10.231829.9924@minyos.xx.rmit.oz.au> Reply-To: hawley@adobe.UUCP (Steve Hawley) Organization: Adobe Systems Incorporated, Mountain View Lines: 81 In article <1991Apr10.231829.9924@minyos.xx.rmit.oz.au> rxcjm@minyos.xx.rmit.oz.au (John Mazzocchi) writes: >jmunkki@hila.hut.fi (Juri Munkki) writes: > >>So, anyone want to have a Forth programmable robot battle program? >>Would it be worth the trouble to write one? > >Yes! God, yes. The best robot game I ever played was the old Robot War! on the >Apple II. C-Robots would be a second choice. But the current spate of games >(Omega included) are a poor substitute. FORTH is probably a little hardcore for most people, mostly because of the bizarre syntactic oddities (please don't start any threads about whether or not FORTH has syntax) like if-then-else contructs: IF ELSE THEN I started a robot war type program for the Mac about 3 years ago that was based on an assembly language. I got as far as writing a 1-pass assembler for it (which did about 600 lines per second) as well as a disassembler and monitor, but gave up because I decided that was not the way to go. I think that a robot war programming language should be geared to the task at hand so that the things that a robot would typically want to do are pretty straight forward, but I think that the language should be Turing complete as well. In other words, if you want to make a robot that does nothing but calculate pi and outputs the numbers by drawing them with its path, then you should be able to do that. The language should be small, quick to interpret and easy to read/write. While I think FORTH is out of the question here since it loses on the read/write stuff (please, no flames -- I've written a FORTH compiler, I *know* the details of the language, and this is no place for "FORTH is easy/hard to write/read" arguments), I think that a better approach would be a more procedurally-based language than FORTH. For example, use a procedural RPN language with a stricter syntax than FORTH (say, something like PostScript), with tagged objects on the stack, giving you integers, floating point numbers, strings, arrays, name-objects, and procedures. To write your program you would want a vector that contains functions that are performed at an interrupt level. You would have a function that gets called whenever you get hit, when you collide and any other things of importance. You would also have a function or functions that are called every nth of a second for periodic things (scanning, repairs, etc). So a function to scan might look like this: /ScanProc { RobotScan { % returns: boolean % saw something AmIHealthy? { TurnTo InFiringRange? { MaximumPower FireLaser } if Move } { % not healthy, run away 180 add TurnTo Move pop % pop off distance - not used } ifelse } if AmIHungry? { FoodScan { TurnTo Move pop } ifelse } if } def /ScanProc SetScannerProcedure The advantage is that the language is almost high level, but interprets very easily. The syntax is consistent (unlike BASIC) so it parses well, and it's fairly easy to write in a human-readable format. Comments? Steve Hawley hawley@adobe.com -- "Did you know that a cow was *MURDERED* to make that jacket?" "Yes. I didn't think there were any witnesses, so I guess I'll have to kill you too." -Jake Johansen