wscott@en.ecn.purdue.edu (Wayne H Scott) (04/08/91)
I fell in love with the programmable robot games years ago when I had
an Apple ][ and played Robot Wars (?) by MUSE.
Yesterday I downloaded Robot Battle Demo with high hopes.
It is not the game I have been waiting for someone to write for
the mac. I have a plan in my head for a very good robot battle
program but I do the know how to write the macintosh front end.
(Maybe I could get together with someone?)
Robot Battle seems like a good game but to make it enjoyable the language
needs to be improved so that it doesn't frustrate the programmer.
Like the following improvements:
* The programming language is far too limited. A nice properly parsed
language could be set up with yacc that would have a good syntax.
In Robot Battle you must put spaces between every command and
general expressions are not legal. (plus it needs a unary minus
operator.)
* The language must include strong math capabilities. If I am going
to write a fancy program to compute trajectories I want floating-
point numbers, trig functions, square roots, etc. The more power
you give the programmer, the neater the robots are going to be.
I like the fact that Robot Battle counts a turn as whenever the
robot scans, moves, fires or turns, and does not punish the
involved computations.
* In Robot Battle, you can only move in one of eight directions.
This forces the programer to use separate logic to move and fire.
I think the robot should be able to move in any direction so that
general moves are possible.
* The language should include structured flow of control statements:
if - then - else
for next
while
real functions
I don't mean to discount the work and effort that when into Robot Battle
(and RoboWars for that matter) but I wanted to see what people think
of my vision of a new battling robot game.
All I need is for somebody to send me code to handle all the graphics and
I could supply the parser and interpreter. (and I need some spare time!)
By the way, I might write one of these games someday so please send me
what you would like to see.
--
_________________________________________________________________________
Wayne Scott | INTERNET: wscott@ecn.purdue.edu
Electrical Engineering | BITNET: wscott%ecn.purdue.edu@purccvm
Purdue University | UUCP: {purdue, pur-ee}!ecn.purdue.edu!wscottbluecow@unix.cis.pitt.edu (Tobish E Smith) (04/08/91)
In article <1991Apr7.212327.6218@en.ecn.purdue.edu> wscott@en.ecn.purdue.edu (Wayne H Scott) writes: >Like the following improvements: > * The programming language is far too limited. A nice properly parsed > language could be set up with yacc that would have a good syntax. > In Robot Battle you must put spaces between every command and > general expressions are not legal. (plus it needs a unary minus > operator.) I'll try to answer these points one-by-one, but I think what I say in this comment will apply to all of them. Our goal in creating the Robot Battle language was to make it accessable to people who have never programmed before. Therefore, our main concern was to keep the language (and the necessary manual about the langauge) very simple. As a programmer, you might like to see a lot of constructs built in to RIPPLE to make your code smaller and cleaner looking. This is fine for experienced programmers, but for neophytes it can be both confusing (to read about these capabilities in the manual) and a cheat (believe it or not, some people actually have to think about how to do a loop for a few minutes since we don't include any looping constructs - this is good; they've learned how to accomplish a simple but fundamental programming construct on their own, learning a bit about logic in the process). The RIPPLE language, while primitive, has the same potential as if we had included more advanced constructs. > > * The language must include strong math capabilities. If I am going > to write a fancy program to compute trajectories I want floating- > point numbers, trig functions, square roots, etc. The more power > you give the programmer, the neater the robots are going to be. The full version has sin, cos, and abs. However, only once have I ever created a robot that has needed these, and that was as a test case. Using square root, for example, to calculate distance: this isn't necessary since if you find a robot using radar, the radar tells you the distance. Perhaps if we were convinced that more math would be useful, we would include it. We won't, however, simply for the sake of having a large command set. That's counter to what we're striving for. > > I like the fact that Robot Battle counts a turn as whenever the > robot scans, moves, fires or turns, and does not punish the > involved computations. This is a necessary by-product of RIPPLE's extreme simplicity. We realize that many lines of code will be needed to do useful logic, and we want to see the robot be as cerebral as possible. > > * In Robot Battle, you can only move in one of eight directions. > This forces the programer to use separate logic to move and fire. > I think the robot should be able to move in any direction so that > general moves are possible. This was a point over which we pondered for many a day. In the end we settled on the grid-based movement system because it eases the computational burden on the program (since we have objects on the battlefield such as decoys and humans) and since it creates a challenge. It is a non-trivial coding problem to have your robot move in on the enemy robot. Again, this is what we wanted. RIPPLE doesn't directly tell you when your robot hits an obstacle; it doesn't have commands like FINDENEMY. While easy to use, it does not hold your hand in any way; all programming problems are left to you. Having the grid-based movement keeps with that philosophy; free-form movement just for the sake of being able to more easily move in on the enemy robot is hand-holding of another sort, especially when you consider the awesome power of the beam weapon in the full version. This weapon has an extremely short range, but a couple hits and the enemy is dead. If it were trivial to move in on the other robot, this weapon wouldn't exist. > > * The language should include structured flow of control statements: > if - then - else > for next > while > real functions Again, these don't provide any new functionality, they simply shorten the size of your robot code. The sets of robots possible to create using RIPPLE doesn't expand at all by the inclusion of these commands, so we felt them unnecessary. > >I don't mean to discount the work and effort that when into Robot Battle >(and RoboWars for that matter) but I wanted to see what people think >of my vision of a new battling robot game. > We had to make a decision when developing the RIPPLE language as to what audience we wanted to appeal. The result is a language that is extremely easy to learn and use and is still capable of producing an enormous array of sophisticated robots. Your suggestions are good, and represent the path not taken for us: a programmer's robot battle game, whose manual would look something like the latest edition of K&R and would scare the bejesus out of non-programmers. In this robot battle game, the robots would be very sophisticated indeed. But try not to belittle the capabilities of Robot Battle based on the simplicity of the language; I think you'd find that there is a great amount of depth and strategy available, especially when using the full compliment of weapons. As for the implementation of your suggestions, we've been toying with the idea of adding many of these type of commands and having a big-n-beefy programmer's version of Robot Battle, that would be available to registered users. This would allow people to get a feel for the game using the current RIPPLE (and to learn how to program, for those who hadn't before) with the option of asking for the "complicated version" when they register. If we receive more comments of the same nature as yours, we'll follow that plan; most of your suggestions could be implemented in a day or so. >_________________________________________________________________________ >Wayne Scott | INTERNET: wscott@ecn.purdue.edu >Electrical Engineering | BITNET: wscott%ecn.purdue.edu@purccvm >Purdue University | UUCP: {purdue, pur-ee}!ecn.purdue.edu!wscott Toby Smith bluecow@unix.cis.pitt.edu (Moo.)
wscott@en.ecn.purdue.edu (Wayne H Scott) (04/08/91)
In article <112421@unix.cis.pitt.edu> bluecow@unix.cis.pitt.edu (Tobish E Smith) writes: > >In article <1991Apr7.212327.6218@en.ecn.purdue.edu> wscott@en.ecn.purdue.edu (Wayne H Scott) writes: >> * The language must include strong math capabilities. If I am going >> to write a fancy program to compute trajectories I want floating- >> point numbers, trig functions, square roots, etc. The more power >> you give the programmer, the neater the robots are going to be. > >The full version has sin, cos, and abs. However, only once have I ever >created a robot that has needed these, and that was as a test case. Using >square root, for example, to calculate distance: this isn't necessary >since if you find a robot using radar, the radar tells you the distance. >Perhaps if we were convinced that more math would be useful, we would >include it. We won't, however, simply for the sake of having a large >command set. That's counter to what we're striving for. > >Toby Smith >bluecow@unix.cis.pitt.edu (Moo.) I have written a very nice robot on an IBM game called crobots. That finds a robot on the screen and shoots at it. When the robot is damaged it moves to another place and calcuates the correct angle to look to find the same target. Those kink of calculations require trig functions. -- _________________________________________________________________________ Wayne Scott | INTERNET: wscott@ecn.purdue.edu Electrical Engineering | BITNET: wscott%ecn.purdue.edu@purccvm Purdue University | UUCP: {purdue, pur-ee}!ecn.purdue.edu!wscott
jtsweet@uokmax.ecn.uoknor.edu (Jonathan Thoma Sweet) (04/08/91)
Some of the problems I have found were:
1) No Arrays
2) No For-Next Loops
One of the first things I wanted a robot to do was to check the damage
of each shield and use that for both targeting (if the sheild damage had
changed) and for movement (keep the weakest shield on the far side).
You can accomplish both of these, but with only 26 varables, it makes it
very difficult. If we only had 1 dimentional arrays, it would make the
game 100% better.bluecow@unix.cis.pitt.edu (Tobish E Smith) (04/09/91)
In article <1991Apr8.154729.24914@uokmax.ecn.uoknor.edu> jtsweet@uokmax.ecn.uoknor.edu (Jonathan Thoma Sweet) writes: >Some of the problems I have found were: > > 1) No Arrays A good point. We'll add them to the registered version. At this point we're leaning toward having a few built-in arrays of fixed size to use. > 2) No For-Next Loops We've really been trying to stay away from this since it opens up a whole can of worms: hey, now that you put in for-next, how about an else clause? And what about functions? and... As I've said before, we're trying to keep RIPPLE as simple as possible. However, since so many people are requesting for-next, we might just be inclined to add it. Tob & Chuck bluecow@unix.cis.pitt.edu
duga@merlin.cvs.rochester.edu (Brady Duga) (04/09/91)
Well, I downloaded Robot Battles from Sumex yesterday, but I can't seem to get it to work. I de-binhexed and unstuffed it twice, just to see if something went wrong the first time. I was running (eventually) on an SE, 2megs, no inits, in Finder, but it constantly crashed (always with id 2. Is that a Bus error?). Sometimes it would crash immediately, sometimes I would get to the startup screen and I got as far as the Main screen once. Has anyone else had similar problems? (I feel really stupid if the docs say this game doesn't run on the compact Macs...) --Brady (duga@cvs.rochester.edu)
jmunkki@hila.hut.fi (Juri Munkki) (04/10/91)
In article <112698@unix.cis.pitt.edu> bluecow@unix.cis.pitt.edu (Tobish E Smith) writes: >In article <1991Apr8.154729.24914@uokmax.ecn.uoknor.edu> jtsweet@uokmax.ecn.uoknor.edu (Jonathan Thoma Sweet) writes: >>Some of the problems I have found were: >> >> 1) No Arrays > > A good point. We'll add them to the registered version. At this point >we're leaning toward having a few built-in arrays of fixed size to use. > >> 2) No For-Next Loops > >We've really been trying to stay away from this since it opens up a whole >can of worms: hey, now that you put in for-next, how about an else clause? >And what about functions? and... > As I've said before, we're trying to keep RIPPLE as simple as possible. >However, since so many people are requesting for-next, we might just be >inclined to add it. Bah, you should have implemented Forth instead of a poor BASIC imitation. Forth is widely used in robotics and microcontrollers because it is a very simple and yet powerful language. I know some people have a hard time "Thinking Forth", but once you learn how to use it, it's way better than any robot programming language that I've seen in any of the games. I've already written one Forth interpreter, but that one was more string processing and speed oriented than is desirable for a robot language. I'm now writing a different implementation that is slower, more robust but also much more portable. It wouldn't be a big deal to implement a floating point or fixed point (I prefer fixed point) class for it. (Yes, it uses operator overloading and has string, list, pointer and numerical object types...) If a language is correctly designed, adding built-in functions and operations should be easy. So, anyone want to have a Forth programmable robot battle program? Would it be worth the trouble to write one? ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
duga@merlin.cvs.rochester.edu (Brady Duga) (04/10/91)
WHoops! I forgot to mention, I'm running system 6.0.5. --Brady
rxcjm@minyos.xx.rmit.oz.au (John Mazzocchi) (04/11/91)
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. The thing about Robot War! is that it used an assembly language, of sorts, to write the code for the robots. It was powerful, terse and easy to use. The only thing I ever missed was trig functions. You would have to write subroutines using series approximations. -- + John Mazzocchi + "The mind is not a vessel to be filled, + + Melbourne, Victoria + but a fire to be lighted" - Plutarch + + Australia + + rxcjm@minyos.xx.rmit.oz.au +
hawley@adobe.COM (Steve Hawley) (04/11/91)
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: <bool> IF <if-clause> ELSE <else-clause> 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: <distance heading type> 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
bluecow@unix.cis.pitt.edu (Tobish E Smith) (04/12/91)
For all of you out there who are experiencing nasty Robot Battle problems, we have a new version available that fixes the nasty crashing bug. We'll make it available (via e-mail) early next week to anyone who requests it. I don't want to post it to sumex just yet; they like to limit upgrades to once a month. The new demo has the following new features: separate color and b/w versions - the color version wants an '020 or better to run fix of the bug that caused the freeze-ups for/next and arrays added to the language All weapons are functional (sonic beam and missiles), however, only lasers actually do damge; this allows people to see exactly what the full version is like. I'll post a note on mac.games when the new version's available. Tob bluecow@unix.cis.pitt.edu
chapman@ug.cs.dal.ca (Paul Chapman) (04/12/91)
In article <13288@ur-cc.UUCP> duga@merlin.cvs.rochester.edu (Brady Duga) writes: >Well, I downloaded Robot Battles from Sumex yesterday, but I can't seem to >get it to work. I de-binhexed and unstuffed it twice, just to see if >something went wrong the first time. I was running (eventually) on an >SE, 2megs, no inits, in Finder, but it constantly crashed (always with >id 2. Is that a Bus error?). Sometimes it would crash immediately, sometimes >I would get to the startup screen and I got as far as the Main screen >once. Has anyone else had similar problems? (I feel really stupid if >the docs say this game doesn't run on the compact Macs...) I had the same problem -- System 6.0.3, no inits, etc. Coincidentally, everyone who is reporting this has an SE (myself included). I'm drawn to the conclusion that it's the SE the program doesn't like. System error 2 is an address error, although I don't see why it would occur only on one machine specifically, especially a fairly tame one.. Anyone else have problems with the game on other Macs? - Paul (chapman@ug.cs.dal.ca)
bluecow@unix.cis.pitt.edu (Tobish E Smith) (04/12/91)
In article <1991Apr11.175722.11626@cs.dal.ca> chapman@ug.cs.dal.ca (Paul Chapman) writes: > I had the same problem -- System 6.0.3, no inits, etc. >Coincidentally, everyone who is reporting this has an SE (myself included). >I'm drawn to the conclusion that it's the SE the program doesn't like. >System error 2 is an address error, although I don't see why it would occur >only on one machine specifically, especially a fairly tame one.. Anyone >else have problems with the game on other Macs? > >- Paul (chapman@ug.cs.dal.ca) The problem is in the code that checked for the presense of color. It's been causing problems on many machines, but especially hates the SE. We have a new copy that we're currently testing (another post here lists the improvements) and will be distributing it via e-mail to anyone who requests it, beginning early next week. Sumex likes to limit revisions to once a month, so we're taking this route for now. In the meantime, as someone else mentioned, the copy on mac.archive.umich.edu, while in b/w only, will work. Tob bluecow@unix.cis.pitt.edu P.S. Bane of the Cosmic Forge is _OUT_??? Oh. My. God. Looks like I'd better pencil out the month of May...
ront@ellis.uchicago.edu (ronald j thielen) (04/12/91)
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? My understanding is that Chipwits was written using MacForth. For some time now, a friend of mine (who bought both Chipwits and MacForth) has been considering trying to rip out the old MacForth kernel and replace it with the most current release to see if it will fix the problems with Chipwits.
harrisd@athena.mit.edu (David Harris) (04/12/91)
There's been a lot of talk recently about using the Forth language for controlling robots. It turns out that a RPN language is very effective. I've written a program, RoboWar, that's been up on sumex-aim for nearly a year now. It's gotten lots of positive feedback and isn't going to crash on you. I've also developed a new version (2.1.1) that includes a much better interface along with an increased instruction set (yes, it does have the trig functions) and fun animation and sound effects. It's 99% stable right now, but I'm not going to post it until it has a bit more time to collect bug reports. If you like RoboWar 1.5.1, send in your registration and you'll get a much better version. Besides, RoboWar is only $10, the cheapest as well as most sophisticated robot game in the shareware arena. I haven't seen the Apple ][ RobotWars game, but many people have told me that RoboWar is very much like the Apple ][ program, but expanded to take advantage of the more powerful Macintosh. If anyone has comments or suggestions about RoboWar, drop me some email. I'm always working on making it a better and more flexible game. David
jmunkki@hila.hut.fi (Juri Munkki) (04/13/91)
In article <13962@adobe.UUCP> hawley@adobe.UUCP (Steve Hawley) writes: >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: > > <bool> IF <if-clause> ELSE <else-clause> THEN > >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. When I talk about Forth, I'm not usually talking about the current Forth standards, but something that applies better to the task at hand. In this case the implementation will have at least lists, strings, numbers and pointer types. Procedures are not stored the way PostScript uses them, but you can have procedure pointers, so the only thing that is missing is that you can't manipulate procedures as lists. As far as syntax, I've always felt that the PostScript style ifelse- structure is harder to read than the equivalent Forth structure. This may be just because I'm more used to Forth and you have more PostScript experience. (I have used PostScript, but not recently.) I'm going to write the Forth interpreter anyway, so if I feel like it, I'll write a short prototype robot war program and let people decide what they like. Note that followups go to comp.lang.forth.mac. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~