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. It also gives me an idea for a new kind of piece: the SPY.