;;  
;; Ken McCaw (8923426)
;; kenmccaw@wolf
;; c473ao@hilbert
;;
;; DOMAIN: SCUDworld
;;
;;      The SCUDworld domain will allow General Schwartzkoff to take 
;;  some time off during a crisis.  All that is required is a square
;;  grid, a description of the terrain, the positions of enemy troops
;;  and equipment, the positions of US troops and equipment, and the
;;  goal that we wish to achieve.  PRODIGY will then be able to plan
;;  a course of action that will liberate a position, destroy a target,
;;  or even plan military training exercises.
;;  
;; ---------------------------------------------------------------------------
;;
;;	I would estimate that this part of the assignment took about
;;  26 hours...Prodigy was easy to learn, but difficult to master...
;;
;; ---------------------------------------------------------------------------
;;
;;	The only bit of code that was borrowed from other domains is the
;;  mult-binding-list function from SCHEDWORLD.  It is used to generate
;;  positions for (x, y) such that the position generated is one square
;;  away from some known position.
;;
;; ---------------------------------------------------------------------------
;;
;;	The only domains I have looked at are SCHEDWORLD and FROZENBLOCKWORLD.
;;  My operators are based on my own ideas, so any similarity between
;;  SCUDworld and any other domain is purely coincidental.
;;


;; Control Rules and Analysis
;;
;; 5-24-91
;;
;;
;; 1.  
;;
;; (a)    My simulation lacks the realism involved in real war
;;     If I had allowed the enemy to be moving/firing, I would have
;;     had to have had a lot more time to develope my domain.  The
;;     main problem with an active enemy is that Prodigy would be
;;     modeling a "real time" event.  For example, two tanks may be
;;     firing at the same time, or the US tank may be firing at a
;;     retreating tank, etc. 
;;        In addition, planning for both sides would have created a
;;     LARGE number of new nodes, with many additional heuristic 
;;     functions.  For example, I would have needed to decide whether
;;     the enemy equipment was taking an offensive or defensive position.
;;     And then, based on the current state (which may change instantaneously
;;     in a real time system), I would have to decide whether the enemy
;;     should fire a weapon, move to a new position, or do both!
;; 
;; (b)    I thought it was going to be difficult to choose the best "next"
;;     position for any piece of US equipment.  But after examining Prodigy's
;;     backtracking for a while, I discovered that by recording the starting
;;     positions of US assets, and generating new positions that favored
;;     squares which were closer to that position than the current position,
;;     it became relatively easy.  Except...
;;        The major problem with this scheme occured when the most direct
;;     route could not be taken.  This happens when there are mountains 
;;     on a square and a plane, the army and/or marines cannot enter the
;;     square.  My solution was a lisp hack in the functions.lisp file 
;;     which rearranged the binding list of next squares based on their
;;     closeness to the starting square of the equipment.  Using this
;;     method, Prodigy checks the best paths first, and if they fail will
;;     choose a bad square in hopes of finding a way around the barrier.
;;
;; (c)     I found the "state" command in the analyzer very useful, along
;;     with the "opfail" command.  These were useful in tracking the 
;;     "stupid" mistakes I made along the way.
;;
;; (d)     A decent manual...
;;
