Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!bluecow
From: bluecow@unix.cis.pitt.edu (Tobish E Smith)
Newsgroups: comp.sys.mac.games
Subject: Re: Robot games...
Message-ID: <112421@unix.cis.pitt.edu>
Date: 8 Apr 91 00:08:45 GMT
References: <1991Apr7.212327.6218@en.ecn.purdue.edu>
Organization: University of Pittsburgh
Lines: 110


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.)