13 Jun 1977 16:49 COREWA.REF[ G,REF] PAGE 2-1 Imagine the following system to implement JMC's computer battle: (to be implemented in LISP) The BATTLEFIELD is an m*n array, each of whose cells is a pointer to a LISP list. In any cell can be any list. Some of these are interpretable as instructions. Each player (GENERAL) has a set of SOLDIERS. Each soldier has the following properties: NAME (* means "optional") (stored on the property list under NAME:) LOCATION (where he "is" on the BATTLEFIELD) PC (program counter -- what cell of the BATTLEFIELD does he execute next) OWNED-BY who's PC is this * MESSAGEQ (a queue of messages sent to this soldier, updated by the system) * INCREAMENT (on a non-jump instruction, increament his PC by ... . This permits soldiers to be not purely "vertical" on the battlefield) * OBITUARY (send this message to it's intended recipiant if this soldier dies) * WEAPONS (what commands does this soldier know? The more weaponry he must carry around, the "slower" he is). Typical commands are (SEND X TO) Take the message at X, and send it to TO. (RCV X) Take the next message in my messagequeue, and store it in X (MOVE X Y) Take the data in location X, and move it to Y (MOVE= i Y) Put value i in location Y (CAR/CDR X Y)Put the CAR/CDR of X in Y (CONS X Y Z Put CONS X Y into Z (IF (<=/=>//!=/= X Y) Z) Evaluate and jump to Z if true (JUMP Z) Unconditional jump to Z (PAUSE) Sleep. Wakeme if I get a message (MOVETO X) Make my new LOCATION X (MAKEINCREAMENT X) Make my new increament X (CHANGEINCREAMENT TO X) Change the incremeant of TO to X (ADD/SUB/DIV/MUL{=} X/i Y) Arithmetic on X and Y, store it in Y (MAKESOLDIER X Y Z) Make a new SOLDIER, starting at X. Put his name in Z. Spare properties at Y. (NOP) No-op (PRINT X) Print X on terminal (PRINT= i) Print message i on terminal (KNOWWEAPON w) Gives this program access to weapon w (CALL w X Y) Call the weapon (LISP function) w, with arguement X, returning it's value into Y. (DEFINEWEAPON w X) Define the weapon w from location X. Typically, a command a general would give. WEAPONs may not have side effects. The amount of weaponry a general may generate may be limited. Here X, Y, and Z are relative arguements, to be added to the LOCATION of the SOLDIER. Typically, if BATTLEFIELD is a two dimensional array, they would be dotted pairs. Execution of an instruction has an associated cost. This cost is a function of the complexity of instruction, the size of the arguements, and the weight of the SOLDIER. Typically, a soldier with a lot of WEAPONS might weigh more. Also typically, the weight of a SOLDIER varies as the distance of his PC from his LOCATION, and the size of his increament. COSTs associated with relative arguements vary non-linearly (cubic, perhaps?). ------------------------------------------------------------------------------------ 13 Jun 1977 16:49 COREWA.REF[ G,REF] PAGE 2-2 There exists a world CLOCK, and a system TASKQUEUE. The TASKQUEUE is a list of TIMEs and SOLDIER-NAMES The system process is as follows: Take the next element from the TASKQUEUE. (increment the clock if necessary) Increament the CLOCK. Execute that SOLDIER's next instruction. If that execution "killed" him (an illegal instruction, or address out of bounds) then send out his obituary. Otherwise, compute his next TIME by adding the COST of his next instruction to the CLOCK, and put him into the appropriate place in the TASKQUEUE. (Note that this system allows one to "CHEAT" by changing an instruction after its COST has been computed, but before it has been evaluated. This could be avoided by storing the instruction in the TASKQUEUE, too.) The GENERALS (players) are like the other soldiers in this priority system, except they can't be killed. When it is the general's turn, he may execute any instruction, which will happen (and the next input requested) at the appropriate point in the queue). The world is initialized by having each player place his (predefined) soldiers onto the BATTLEFIELD, and loading the TASKQUEUE with each general's name. The game can be suitably handicapped by weighing one general more than another. Nor is it limited to just 2 players. There can be a limit on the number of MAKESOLDIER's an army may execute. The game is over when either: One army has no (non-general) SOLDIER's left. The CLOCK reaches some predetermined limit.