A VIEW to a KILL
	     Model-View-Controller and the User Interface

Okay, here we are with our final architectural description.  After
this, we can start working on the design and implementaion of an
actual game.  We'll probably start with a simple implementation of
Checkers, generalize it to multi-player distributed play, then tackle
other projects.

Feel free to keep up the discussion, but I will be leaving for
Christmas (back to Northern Illinois, brr) and won't return until Jan
6th.  Be thinking about what sort of objects you might have the time
and inclination to impelement, as I hope to start coding by the end of
January, and have something at least minimally functional by March.

This is my particular vision of the organization and function of the
user interface.  I am the first to admit to my lack of experience in
these matters, and welcome other viewpoints.  I will also be reading a
copy of the Purple Book (DPS development) over Christmas, which should
decrease my ignorance somewhat.  Here I am discussing the
architecture; I hope cover the 'look-and-feel' of the UI later.  I
hoped to do it now, but I have a plane in two hours...


			 I.	Architecture

One of the most pervasive paradigm in OO UI design is
Model-View-Controller, or MVC.  In my doubtless butchered viewpoint,
that means having three distinct (though tightly coupled) systems,
often corresponding to three distinct hiearachies:

	- Model: This is the 'state' of an application.  Virtually all
of our discussions to date have focused on the 'Model' aspects of
WarKit.  This corresponds to the NeXTSTEP Cell class, or (say) a
back-end database.  There is no real interface associated with these
systems, only raw information.

	- View:  This is the 'face' of an application, where it
presents data to the outside world.  A report for a database, or
(obviously) a NeXTSTEP View are both examples of this.

	- Controller: This is the 'hand' of an application.  It is the
object which, from the application's perspective, acts as the user.
The user, responding to information presented in the View, has the
Controller send messages to modify the state of the Model.


My breakdown might be better said to be "inspired by" MVC rather than
an implementation thereof, but you be the judge.

	A. Model

The server is essentially all 'model'.  It consists of the Known
World, which in turn holds the locations of all the pieces.  It also
has ports for all the players.

The client contains a pointer to the KnownWorld of the server.  It
could actually be a copy of most of the static information (terrain
and space), with a proxy for the changeable information (the WarMap of
locations).  

A client would also have a list of 'KnownPieces', those pieces which
are 'his', as well as (potentially) other pieces that the client knows
about.  The owned would be the 'actual' pieces, with a
pointer to their region of residence.  Enemy pieces would be
references, and probably be contained in a WarMap (for obsolete or
out-of-date locations?).  In cases of full knowledge, it might make
sense to have the KnownWorld handle the entire display.

The client might also keep track of statistics like battles
won/lost, pieces in play, and so forth, but those are really just
bell's and whistles, not part of the 'core' model.

	B. View

The client's view is an actual subclass of View which is responsible
for drawing the KnownWorld and KnownPieces.  Like NeXT's Control and
Cell, the View would receive the 'drawSelf::' message, and tell the
appropriate Model entities to draw themselves.  The PostScript code
would reside in the Model, not in the View.  The view could take care
of thinks like rotation, scaling, and grid layout.

The implemention details should probably be hidden inside the model,
but this is how I was thinking of handling drawing:
	- a Region would be associated with a PostScript user path.
		and probably a bounding rectangle, for efficiency
	- a Terrain would correspond to a color or pattern
	- a Piece would have a Type 3 font character.

So, a terrain pattern would in general be something fairly simple.  One would
draw the terrain within the bounding rectangle, then clip it to the
Region's path.  Doing nicely contoured hills might be somewhat more
tricky, possibly handled by repetetive scalings of the Region's path.
Regions could cache their drawing in an NXImage, and then just
composite it out when necessary.

Pieces would be associated with a Type 3 font dictionary and a single
character.  The reason for using a font is that it 'caches' the
bitmap representation, rather than having to render it anew each time.
This is very important if you have 200 infantry units on the screen!
The piece (WarMap?) would only need to do
an 'xyshow' to display itself.

The view would also be responsible for receiving mouse events.  The
user could click on a particular piece, or drop an icon on a point.
The view would translate the mouse coordinates into Model space
coordinates.  It would probably handle the hex-coordinates as well.

Hit-detection is the process of figuring out what object should be
associated with a particular point, like when selecting a piece.
Since the shape information is stored as a user path, we can use the
DPS operators to find which region corresponds to that.  From there it
should be relatively straightforward to find the nearest piece.  The
WarShape class then becomes essentially a wrapper around a UserPath
and various DPS operators.

Note that I am implicitly assuming we are working in two dimensions.
The problems of display and hit-detection in three dimension are far
more complex, and I don't even want to think about them at this point.
This is particularly true since we are relying on PostScript for
several different things, in order to simplify matters.  If you can
think of a more general (and equally simple) mechanism, let me know.

			  C.	Controller

The final piece of our Triad is the controller.  In the War UI, the
controller is respresented by an Inspector Panel.  To effect change,
one must select a piece (or group of pieces).  One may then assign
various activities to that piece, as well as examine its status.  One
of my goals is to allow passive inspection w/o requiring a trip to the
server, to make that an efficient process.

I have never actually written an Inspector Panel, so perhaps someone
who has could give some insight on what is and is not feasible to do
with one.  In addition to modifying selected pieces, there are some
other activities which may or may not fit into the same framework:
setting up delayed actions, introducing new pieces, etc.