These scripts could be attached in an object-oriented fashion to cities, continents, and oceans. They could detect bomb-events to automate the re-conquering of a bombed-out city. Instead of putting a piece on patrol, you could enter a patrol script that could be as simple or as complex as you want. City scripts could carry out complex long-term production schedules and automatically send new pieces to the front. One fighter on each carrier could be automatically directed to hunt for subs. A destroyer could carry out a long-range mapping mission automatically. The possibilities were endless.

We never fully defined this scripting language, but we got far enough along to expose some of the complexities and possibilities. This page collects our discussions under various key areas to form kind of a proto-manual for this ambitious programming language.

Language Elements
Sample Scripts
Data Dictionary
Definition Tables
Names
Events
Paths
Messages
Enforced Automation

Language Elements

Paul got the ball rolling at the outset of our dialog by defining some of the basic elements. Unfortunately, we never got much farther than this.

paul1989-09-15:

Conquest Programming Language (CPL?):

I have a few very preliminary and incomplete pieces of the language:

• MOVE <piece> TO <location> [, TO <location> ...]
• MOVE RELATIVE <piece> BY <vector> [, BY <vector> ...]
• SLEEP <piece> TILL <date>
• ATTACK WITH <piece> (this needs lots of work)
• BUILD <piece>
• LOAD <piece> ON <piece>
• Looping Constructs:
  • IF-THEN-ELSE
  • REPEAT UNTIL
  • GOTO
• Simple Arithmetic
• Read access to characteristics matrix of friendly pieces

Sample Scripts

• Sleep
• Wake
• Transport Load
• Random (do we really want this one?)
• City Aircraft Destination
• Stack Move
• Patrol (see below)
• Skip
• Move Later

OTHER SAMPLE SCRIPTS:

Explorer Script (attached to Destroyer Miami 12)
on newday
  if z is empty then put 90 into z
  repeat until I am near land
    move 1 bearing z°
    if I am near enemy then say "Enemy Sighted"
  end repeat
  turn left
  put latitude into x
  repeat until latitude>x
    follow shoreline
    if I am near city then beep
    if I am near enemy transport then attack enemy transport
  end repeat
  put bearing of nearest unknown into z
end newday

Script of City London
on newday
  if stillbuilding is true then exit
  if currentproduction is "Fighter" then
    send latest fighter to Paris
    set currentproduction to "Army"
  else
    send latest army to nearest shoreline
    set currentproduction to "Fighter"
  end if
end newday

Patrol Script (attached to fighter Chigaco 27) -- a slight variation
on newday
  repeat until I am inside a city
    move 1 toward nearest city
    if I am near enemy transport than attack enemy transport
  end repeat
  move 5 bearing 215°
  repeat 5 times
    move 1 in any direction
    if I am near enemy then beep
  end repeat
end newday

Data Dictionary

OBJECT IDENTIFIERS

• Each Continent and Ocean is assigned a unique 2 digit ID number.

  class Continent object
  {
     Continent_ID : integer (0..99)
  }

• Each city is assigned a compound two-part identifier. The first part simply duplicates the city's continent ID (this is redundant; cities are considered immobile. Or are they?). The second part is a two digit number assigned at generation time, and unique among cities on that continent.

  class City object
  {
     Continent_loc : Continent ;
     City_ID : integer(0..99)
  }

• Each piece is assigned a compound multi-part identifier. The first two parts identify the continent and city of manufacture; the next part describes the piece type; and the final part is a number assigned sequentially upon production. Collectively, these parts are known as the piece's "license plate".

  class Piece_ID : object
  {
     Location_of_Manufacture : City ;
     Piece_Type : integer(0..99) ;
     Production_Number : integer(0..9999)
  }

Definition Tables

Concern: Does the flexibility of allowing startup-time modifications to piece characteristics complicate strategies to the point that successful general-purpose computer opponents cannot be written? To state the issue in another way, Is it possible to determine the merits of a piece by examining its definition table? If not, we must severely restrict the customization of definition tables.

Ideally, the set of properties included in the table would define all possible pieces in an elegant fashion. Here is Paul's initial set of properties:

• Speed
• Range
• Time to Build
• Medium (Land/Air/Water)
• Detectibility
• Carries
• Capacity
• Stackable (Yes/No) **Limit on stacking?
• Strength at which piece is considered "crippled"

Additional properties:

• Visibility after contact (in days)
• Maximum Additional Strength (0 for most pieces, 1 for armies/fighters)

In addition, each piece will require an individual set of properties

• Attacks allowed per day (normally 2, crippled pieces 1)
• Strength (can increase for some pieces after combat)
• Speed (can decrease after damage)
• Fuel Remaining
• Attacks Remaining Today
• Movement Remaining Today
• Current Location (indication if inside some other piece or inside city)
• Other pieces on board (yes/no or list?)
• Bombers only: Blast radius of bomb (0 if bomb has been dropped)
• State (Awake/Asleep/On Patrol/Under program control)
• Destination [this might be accomplished with a script instead]

Names

Question: Will confusion arise if two human opponents are allowed to provide a different set of names?

Answer: Each opponent must not be allowed to see names assigned by his enemy. The proposed default naming convention implicitly provides strategic information about production and logistics. Therefore, each human opponent _must_ have a private naming table. Neutral internal names will also likely prove necessary. This suggests an interesting scenario: A script refers to a piece by name. The player renames the piece. The player then gives another piece the first name. What happens when the script is next executed?

Solution: The "neutral internal names" will be immutable, and will be referred to as ID's. The player-assignable names only will be referred to as NAMES, and may be changed at will. The scripting language must allow the use of either.

It is not yet clear how to define the boundaries of oceans.

Should individual ships have names?

It is clear that we are trying very hard to define an object-oriented game. In that light, I believe that ALL objects should have unique, unambiguous names.

FURTHER DISCUSSION (JOHN 11/18/89):

This naming is a tricky business and also a critical one. It is necessary to use names in scripts in a very general way so that the same scripts can be used from one game to the next. It is also necessary to refer to objects from inside repeat loops.

Perhaps we should imitate HyperCard. HyperCard assigns THREE different names to each object.

First, the object can be given a name, like "Chicago". This is OPTIONAL.

Second, the object is given a sequential number, which CAN be modified by the user. Thus we could refer to city 5 of continent 12. Such a labeling system is essential for structures like repeat loops. In HyperCard the order of object numbers determines which object is "on top" of the other. In our game, the order could determine who goes first in the movement list. If these numbers are frequently changed, it becomes important to refer to specific cities in scripts by name or ID number.

Third, the object is automatically assigned a unique ID Number.

Labeling continents and cities poses no special problems, but labeling moving pieces is more difficult. I PROPOSE that we adopt the following system for assigning automatic ID Numbers:

• Each Continent and Ocean is assigned a unique 2 digit ID number.
• Each city is assigned a 4 digit ID number in which the first two digits match the continent that the city is located on, and the second two are assigned at generation time.
• Each piece is assigned a 9 digit "social security" number in which the first four digits represent the original city that produced the piece, the next two describe the piece type (01=army, 02=fighter, etc.), and the final 3 digits are assigned sequentially upon production.

  Continent 12 = "America"
  City 1205 = "Chicago"
  Fighter 1205-02-007 = "Red Baron" (the 7th fighter made in Chicago)

In this case, a script could refer to the "Red Baron" in any of the following ways:

• Move piece "1205-02-007" to (33,45)
• Move fighter "Chicago 007" to (33,45) -- {here fighter is a noun}
• Move "Chicago Fighter 007" to (33,45)
• Move "Red Baron" to (33,45)
• Move fighter 3 of this continent to (33,45)

When a descriptive number appears without quotes it is assumed to be a sequence number (as in the final example). These sequence numbers are VERY tricky. I PROPOSE that sequence numbers be assigned AT THE BEGINNING OF EACH MOVE. Thus fighter 3 of continent 8 refers to the third fighter located in continent 8 AT THE BEGINNING of the move, even if that fighter is currently located over open sea. If the fighter finishes his turn still over ocean 17, then in the NEXT turn he will be referred to as fighter 6 of ocean 17.

The language will need to provide several counting functions for both beginning of move and CURRENT situation. The word "CURRENT" could signal the difference. Thus "Number of fighters in continent 8" would refer to the number at the beginning of the turn, and "CURRENT Number of fighters in continent 8" would refer to the number of fighters at the moment the line was executed. I provide the following script as an example:

  repeat with j=1 to number of continents
    repeat with k=1 to number of fighters in continent j
      if current number of fighters in continent j>2 then
        move fighter k of continent j 10 units east
      end if
    end repeat
  end repeat

Of course, both naming systems can be used in the same line, as in "move fighter k of continent "America" 10 units east." Also fighters can be inside cities and continents at the same time so that fighter 7 of "America" could also be referred to as fighter 3 of "Chicago". The same applies to armies inside transports and fighters who begin their turns on carriers. And variables could always be used in place of literals.

The algorithm used to assign sequence numbers at the beginning of each turn should be written in a script at program level and thus subject to modification by advanced users. Perhaps 2 or 3 different standard ordering algorithms should be available at the click of a button. And the numbering system could be changed at any time by a user or script with some kind of "Increase Priority" command. Players can also use custom scripts to affect the order of play, moving all fighters at once, or all pieces in "America", or all armies ever produced at Chicago.

This naming system is very flexible and makes all sorts of wild scripts possible.

Events

Normally, if a user wants to change the effects of a given event he will simply "intercept" it by creating a script triggered by that event. He can intercept all menu commands by invoking the MENU event.

Each event has a name, and the event can be passed on up the heirarchy or sent to other objects. In addition to the standard events, a user can create his own events at any time by invoking them from within a script. Following is a preliminary list of possible events:

• Menu - triggered when the user issues a menu command
• Enemy Contact - triggered when piece moves next to enemy
• Piece Contact - triggered when piece moves next to friendly piece
• Shoreline Contact - triggered when piece moves next to shore
• City Contact - triggered when piece moves next to city (us, them or n.)
• Piece/City Hit - triggered when piece is hit
• Piece/City Destroyed - triggered when piece is destroyed (not by bomb)
• Piece/City Bombed - triggered when piece is vaporized
• Piece Lost - triggered when piece runs out of fuel or violates shoreline
• Piece Recovered - triggered when damaged piece reaches full strength
• Piece Created - triggered when piece first appears
• City Captured - triggered when city is taken (us, them, or neutral)
• New Day - sent at the beginning of each day
• New Resident - sent to a container-object whenever a piece moves in (container object includes Transport, Carrier, and City)
• Resident left - sent to a container-object whenever a piece moves out

Paths

I am beginning to suspect that our notion of patrol paths might prove to be a very potent concept. We have already discussed using moving patrol paths to achieve automated escorts. I think patrol paths could also be used to generalize the notion of city destinations. Actually, we shouldn't call them patrol paths, but simply paths. Maybe we could find a way to add programmable branches to paths; if so, we could actually control much complex behavior by simply drawing paths and attaching pieces to the paths. This could become a kind of visual programming language.

Messages

Remember this thread of yours?

Whenever we click and drag a piece, the game could automatically generate and store away a text "radio" message equivalent.

I like this, not the least because it is "object oriented" ;-)

These messages would be produced transparently and invisibly in the background and would serve two functions...

I propose broadening the scope significantly; these messages should become a fundamental part of the architecture. We'll develop an object hierarchy (is this a new idea? I think so). What's an Alexander object? Each piece is an object; each city is an object; maybe each continent is an object; maybe each player is an object. And there may be others...

So how would this be applied? Here's a rough example. Let's say a city is building armies. When created, the city sends a message to the new army: "Go to coordinates thus-and-so, and guard the coast." When the army arrives, it might send a message back to the city: "I'm in position." Or maybe it would just report interesting activity: "I'm being attacked by armies on a transport!" Maybe it could be sneak-attacked and killed under certain circumstances, without getting a warning out. Maybe every message sent by a piece would increase its probability of detection... (This last idea is very similar to one proposed by you.)

This idea, extended, could significantly alter many aspects of the game, including detection: Maybe detection would become a probability rather than a certainty - the more messages, the more likely that a nearby piece would be detected. Hmm... interesting, if nothing else.

Enforced Automation

One of the central problems even with the current game is that it takes too long to play. As the pieces pile up and spread across the globe it can take ten or fifteen minutes just to make a single move. One radical approach is enforced automation: limit the number of pieces a player can "interfere with" in a given move. (I think you may have proposed something like this at one point.) The theory is that even the most sophisticated central command can't make all the decisions and must sometimes rely on soldiers in the field to think for themselves. Each day of the war, a player makes a limited set of decisions and moves on so that the games moves at a brisker pace and ends sooner.

In order to make this work we would have to provide easy to use yet sophisticated automatic capabilities for all pieces. Some of the features would include:

1. CITIES. Players could direct cities to make the same kind of piece over and over, cycle through a small set of different pieces, or choose at random from a weighted subset. In the last case, we could perhaps allow the user to define a global wishlist of the preferred proportions of all pieces; cities could automatically consult this wishlist and produce whatever piece was currently in short supply.
2. RULES OF ENGAGEMENT. Pieces could be given a default behavior in case of enemy contact. Possible behaviors might include AllStop, ExploreThenRetreat, ImmediateRetreat, OneShotThenHold, OneShotThenRetreat, FightToTheDeath, etc. Behaviors might also vary depending on the type of enemy target, current number of supporting troops within a certain radius, etc. The trick would be to reduce these possibilites to an easy point and click interface. Each piece would have three possible settings: global default defined for all pieces of that type, (optional) local default for that particular piece, or manual (within limits discussed below). Pieces could also have a survival instinct so that, if not engaged in combat and low on fuel, they would automatically return to their assigned or nearest port for refueling, etc.
3. PATHWAYS. Players might be required to define movement pathways which would extend from the factory gate to a (possibly somewhat indeterminate) destination. These pathways could be made to appear on the map and could be easily altered; if enemy occupation forces a break in any path, the player would be required to specify a new path (or settle for some kind of default rerouting). These paths would be more sophisticated than the mechanisms in the current game. An army could be instructed to proceed to a specified port city, board the next available transport, disembark on orders from the transport, then follow a clockwise inward spiralling search pattern in search of unoccupied cities. In this case, a path line would be drawn from the factory city to the port city. The transport would have a program (a kind of internal path) that would tell it to wait until, say, six armies had boarded then sail due west; this might appear on the screen as a westward pointing arrow extending from the transport. On contact with an apparently unoccupied land mass it would order two armies to disembark and provide search paths for each; these paths could be made to appear on the map as soon as the armies disembark.
4. PHASES OF PLAY. In order to enforce as much automation as possible, players would be limited as to how many pieces they could operate on "manual". There are many possible ways of handling this; the trick would be to limit overrides while avoiding situations in which the player watches helplessly while all his pieces march over the edge of a cliff in single file. At the beginning of a turn the player should be given an opportunity to react to the latest enemy incursions or new discoveries by adjusting pathways and settings. At this point he could choose up to, say 10 pieces for manual override. During the second phase, all his pieces would move according to their programs. Some pieces might be programmed to stop and ask for intervention IF AND ONLY IF some of the ten "slots" were still available. Thus, in an uncertain situation, a player might specify only six of his ten possible pieces as manual during the first phase and hold four back just in case automated pieces ask for intervention. We might want to provide a third phase for some final adjustments to rules of engagement before the player's turn is complete.

This is obviously a can of worms, and may not be entirely feasible. The goal is to provide a set of behaviors rich and varied enough so that players could feel comfortable in leaving most of their troops on automatic pilot most of the time. Ideally we would provide a range of complexity ranging from a pick list of "canned" behaviors to full-fledged programming.