Constraints for the first iteration (0.1)
[00.1-Constraints.txt]
Ernest N. Prabhakar, 8-OCT-93

There are two equal and opposite errors any design process can fall
into:  trying to do too much, and not trying to do enough.  I think
our first job is to implement "something" that works, then see if we
can generalize/enhance it from there.  Most likely we will learn
enough from "0.1" that we will want to throw it away and write "0.2"
from scratch.

So, based on the preceding discussions, as well as my own reflections, I
believe we should adopt the following constraints on our work and
discussions.  If any of these is terrible offensive to you, let me
know; otherwise, live with it.

A.	Goals

1) Our goal is to build a kit that will support writing "Wargames" in
the restricted sense, as specified in Section II (A-D) of the
GameList.  [In particular, no video games, sorry]

2) In particular, our focus is games that operate on a regular 2D or
3D hex, square, or continous surface.

3) The purpose of the kit is to make it "easy" to implement "most" of
the "basic" functionality of those games, and "straightforward" to implement
all of their functionality.  [Yes, those words are deliberately vague]

4) The hope is to cover a wide variety of particular cases under a
single paradigm by using a suitably high 'level of abstraction',
rather than providing lots of special hooks.

5) Examples of other types of games (Sections I, III, and IV) can be
useful for improving/increasing our level of abstraction, but are not
in themselves relevant to our design goals.

B.	Restrictions

1) We will use a client-server model.  The "pieces" are 'owned' by the
clients, and the "world" is 'owned' by the server, and they live in
different threads (and probably machines).  [who owns location is
still in doubt]

2) For generality, we will use NeXT's Distributed Objects as our
communication medium.

3) We will assume that all clients are fully trustworthy, and hence
ignore security issues.

4) "linear" efficiency issues are not as important as flexibility.
[i.e., we don't care if A is three times slower than B, but we do care
if A goes as the cube of the number of pieces while B is only linear
in the number of pieces]

Please let me know if these are clear, and if there are any other
major philosophical questions you would like addressed.  Do remember
these are only the *initial* guidelines.  Once "0.1" is actually
tangible, we can look into relaxing at least some of these
constraints.