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

Damn! I did run out of tape! Rather than re-tape, I thought I'd try this multi-media thing. The intent is to keep it short, at least this time.

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)
If this is done right, adding a new piece is simply a matter of defining a new characteristics matrix (and perhaps updating all the old ones with additional attack/defense vectors). I'm sure you already see the power of this approach.

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
Time to Build   4625151010

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.
I'm not yet too interested in the attack & defense vectors; they should be pretty straightforward, right?

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:
    • GOTO
  • Simple Arithmetic
  • Read access to characteristics matrix of friendly pieces
Some syntax is needed to deal with exploration and mapping. I don't have any good ideas here.