Date:	1989-09-15
		From:	Paul
		Subject:	Tape Addendum

A point from my notes that I completely missed during the taping: I'm concerned with the multi-media concept in that I think it may significantly increase our communications burden. Currently, the burden is two hours and small change: an hour to listen, an hour to respond, and maybe a little time to think (but usually not). Add in a computer disk, and things may slow down drastically - or fall apart altogether.

Here, I guess, is what it boils down to: the question of what is - or should be - driving the taping. Projects like Archipelago and Conquest? Maybe; I dunno. But it's definitely worth ..uh... talking about.

Strategic Conquest: my last point, which was cut off, is that we may be able to design a certain amount of extensibility into the program. In particular, I am here thinking about playing pieces, and it occurs to me as I write that it should be easy to even go beyond my first conception on this subject. We need to define every area of variability in playing pieces. There are several that come immediately to mind:

• Speed
• Strength - This should be subdivided, at least to:
  • Attack Strength
  • Defense Strength
• Range
• Medium (i.e., air, land, water)
• Time to build
• Name
• Icon
• (and others)

Wildcard pieces could be easily added by the players. Existing pieces could be easily modified. We could even go to the extreme of carrying around this baggage for each instantiation of each piece type, and modify them dynamically. This is presumably how you would build fighting aces. Come to think of it, this may be a necessity rather than an extreme. Parameters such as speed and strength have to be available on a per-piece basis.

Anyway, I'm sure you get the idea. On the negative side, I'm not sure how easy it's going to be to pigeonhole pieces thusly. Imagine some arbitrary new piece: can it be defined through a "complete" version of the above list? Here's a concrete example: let's define a new piece, a sub-chaser. How will it look next to the other pieces?

Name	Army	Fighter	Bomber	Carrier	Sub	Chaser
Speed	1	20	10	3	3	3
Range	999	20	30	999	999	999
Time to Build	4	6	25	15	10	10
Medium	Land	Air	Air	Water	Water	Water
Detectibility	2	2	2	2	0	2
Carries	-	-	-	Fighter	-	-
Capacity	-	-	-	10	-	-
Stackable	Yes	Yes	Yes	No	Yes!	No

Hmm... Clearly I am in trouble. I don't know how to relate detectibility of the sub (normally low) to this new piece, the sub chaser - which should be able to find subs pretty easily. Clearly, one could add a detectibility vector, but that idea doesn't excite me. I do like the sub-chaser, though. What do you think?

If you like the direction I'm headed, why don't you:

• Extend the table horizontally. Add in transport, destroyer, battleship, and new pieces that come to mind.
• Extend the table vertically. Presumably necessary to accomplish the above.

The idea of templating these tables at the city level has some appeal. Here's the idea: The template would define precise characteristics of pieces built at that location. Particular cities' pieces might come out a little different than those from other cities.

For example, Boston's fighters might have an extra unit of range. If we could quantify the value of various characteristics we could pool them at each city and allow the city owner to allocate the pool as he chose.

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