From ernest%WS5%BEPC2@SCS.SLAC.STANFORD.EDU Wed Nov 17 20:18:08 1993
Return-Path: <ernest%WS5%BEPC2@SCS.SLAC.STANFORD.EDU>
Received: from SCS.SLAC.Stanford.EDU by pundit.cithep.caltech.edu (NX5.67d/NeXT-1.0)
	id AA00651; Wed, 17 Nov 93 20:12:41 -0800
Received: from DECNET-MAIL (MAIL$SERVER@BEPC2) by SCS.SLAC.STANFORD.EDU (PMDF
 V4.2-12 #4747) id <01H5FNLFWJDC8ZG4JM@SCS.SLAC.STANFORD.EDU>; Wed,
 17 Nov 1993 20:12:29 PST
Date: Wed, 17 Nov 1993 20:12:29 -0800 (PST)
From: "Ernest N. Prabhakar" <ernest%WS5%BEPC2@SCS.SLAC.STANFORD.EDU>
Subject: WarPath:  Getting a Move on
To: WAR@PUNDIT.cithep.caltech.edu
Message-Id: <01H5FNLFY58I8ZG4JM@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: WAR@PUNDIT.CITHEP.CALTECH.EDU
X-Vms-To: bepc2::scs::in%"war@pundit.cithep.caltech.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Status: R

19 November 1993, Ernest N. Prabhakar

Is anybody there?  I feel like I'm starting get into things again, but
its hard to sustain without any feedback.  Are you all forwarding me
to /dev/null, or just nodding in tacit agreement and waiting until we
get back to more meaty issues?  Or do you feel I am being painfully
pedantic and are too polite to tell me to get a life...

Anyway, I believe I have a simple protocol for handling movement.  It
is almost painfully sparse, but I guess thats good for providing
generality.  We can always provide a sample class demonstrating its
use, if we want something more specific and detailed.


COMMENTS on REGIONS

First, a few more thoughts on regions.  I think it would work best if
a region:
	isa WarSpace
	isa Topology [note that protocols CAN 'inherit' multiply]
	hasa Terrain
	hasa WarMap

which I believe would be written as

@protocol Region <WarSpace,Toplogy>
	id<WarMap> map;
	id<Terrain> terrain;
	id<Terrain> terrainAt:Location;
@end

[Yes, I'm using pseudo-code for the arguments]

Note that the use of 'terrainAt' would allow a single region to have multiple
terrains, if it wished.

R - TERRAIN

Secondly, (since I'm in a spare mood), I'm beginning to think our
'default' Terrain should have no methods - it is sort of an 'abstract
protocol' that specific protocols can inherit from, if that makes
sense.  Of course, as we explore further we might find methods to put
there, so it seems a good investment to define it now.

For example,

@protocol Terrain2D <Terrain>
	float height;
	float heightAt:Location;
	float heightAt:(float)x :(floay)y;
@end

People could define protocols for various common terrain mechanisms to
include as part of the distribution.  You could even have a terrain
which supported the WarSpace protocol [I'm starting to dislike that
name...], to keep track of its own position.

Another tricky issue of terrains is that edge effects (crossing
into/out of) are almost - if not more - important than crossing within a
terrain.  There may need to be a separate abstraction for that, but I
hope not.

R - TOPOLOGY

Finally, I should add that the Region hierarchy should work like the
view heirarchy.  That is, later subregions should be on 'top' of
earlier ones, and hence 'hit' locations should be calculated from the
bottom up.  The reason for the this convention is to allow children to
overlap.

Also, it may be that 'peers' only need to conform to 'space'
and 'map' protocols, rather than the full' region'.  In fact, perhaps
we should think of them as 'portals' [exits and entraces], which may
or may not leed to another region.  The only important methods, after
all, are being able to a) decide if a piece goes there after leaving
here, and b) transfer the piece there.  In that case, 'region' would
inherit from that 'portal' (gate? exit?) protocal.


			       WARPATHS

Anyway, onto movement.  The first construct we want is a WarPath,
which is basically an ordered WarSpace:

@protocol WarPath <WarSpace>

	-(Location) start:piece;
	-(Location) end:piece;
	-(Location) step:piece;
	-(Location) back:piece;
//i.e., there is some sort of internal counter
// which can be set to either end or moved back and forth
// the location returned is the current one

	-(float) length:piece;

	-<Region> region;

@end

Note that all the movement takes a parameter "piece".  Most of the
time a 'nil' value should suffice, if the path is independant of who
traverses it.  But some pieces will certainly have different 'steps'
than others.

Note that this is considered purely a geomemtrical construct - tracing
a line in space.  While it may consult a piece to shape the line, in
general there is no interaction.  All the interactions with terrain
and other pieces is handled by our next protocol.

			       WarMove

I hate to use the term 'Move', because we overload it so much in
English, but I can't think of anything better.  Trip is the closest I
could come, but it doesn't sound nearly as nice.  A WarMove hasa path
(isa? naww), and handles the mechanics of moving pieces.  In general
there will be some sort of formal informal protocol it uses to query and
modify pieces as they move.

@protocol WarMove
	-<WarPath> path;
	-<WarPath> setPath:<WarPath>path;

	- check:piece;
	- move:piece;
	- checkMove:piece;
@end

The latter return nil if the move (or check) fails, probably returns
the piece if succesful.	  The 'check' is used to verify that the piece
can take the move (i.e., is it possible given the rules and state of
the piece).  'checkMove' basically means move if check is legal.  It
is included because it can often be more efficient to do both at once.

And that's really about it.  I had lots of ideas about how to
implement move, but then I realized that it is much simpler to let
each game put in their own than try to find a general case.  The point
is that these protocols tell everyone OUTSIDE what they need to know,
and the internal details are 'confidential' matter between a move and
a piece.

The main reason for splitting up a Move and Path is to allow 'standing
orders'.  That is, there can be a well defined Path that pieces are
expected to take, and pieces can be applied to it sequentially.
Conversely, you can know that a piece is allowed a Move, and
experiment with different Paths until you find what is allowed.

The important distinction, is that the callING piece has "control",
whereas the callED piece has "information".  You want to export as
much control as possible, while keeping the information hidden.  At
least, that is my understanding of encapsulation.


Of course, you know that when we say a piece has "a move", we often
mean that it could fire, resupply, or do other things as well.  And
that perhaps we should expand our abstraction to cover that.  However,
that requires a much deeper understanding of what a piece is.   Which
will be the topic of our next discourse:  "War and Pieces"...