Clarifying the Questions
[Documents/03.3-Clarify.txt]
Ernest N. Prabhakar, 30 Sep 93

Ooh, conflict!  Did we ever decide whether "designing" a wargame
qualified as a zero-sum game?  :-)

Seriously, I think this disagreement is really productive.  I
sincerely appreciate the thorough way people are making their points.
In particular, I hope this discussion will prove a good education in
OO Analysis and Design for people on the list (including me!).

This and previous discussion on this thread have been uploaded to the
FTP site.

A rule of thumb for conflict resolution: 

- If you believe something can't be done, state a specific example you believe can not be implemented with the given constraints

- If you believe it can be done, give a sketch of how it may be
implemented, and try to isolate the differing assumptions.

I hope to stay out of the way as much as possible, and just weigh in
when things get stalled.  However, I do want to clarify a couple of
points.

1.  Security

While I agree it may be important in general, I really do not want to
consider it at this stage.  Wargaming relies heavily on people
following the rules in good faith.  Restricting information is
something I believe should be done at the user-interface level, in
order to make the game more interesting.  It is not something we
should build into our system because we are worried about people being
dishonest.  The typical game package will generally provide all the
client modules anyway, so it would not be a concern for them.

2. Load-balancing

I think many of the issues of compute balancing between client and
server can be handled dynamically.  For example, a server can either
send a client a "proxy" object, which routes messages back to the
server, or a "copy" of the object, which exists directly on the
client.  The former uses the servers CPU, the latter the client's.
The implementation difference between the two, if I understand DO
correctly, is a single keyword in the Objective-C file.  And we could
always allow our proxies to ask for the "real" object to be sent over.
Thus, for design purposes, I think we can choose what is most elegant,
and pin things down much later.

3. Caching 

Similarly, it is a fairly straightforward process for clients to
maintain copies of information in the server, and have ways for it to
be updated when it is changed.  And vice versa, for that matter.  The
important question is who has the "master" copy of that data, and who
has "slave" copies.  The 'master' is the object who:
	a) can change the data
	b) knows who has slave copies of the data, and
	c) notifies them to update it

This master-slave information control is almost precisely what NXProxy
is for (someone with more DO knowledge, please jump in!).  Thus,
setting up slave copies of data is something that I would also claim
is trivial.  The important question is not whether copies exist, but
who is The Master!

4. Geography

I really believe there are only two fundamental questions clients need
to know about geography.
	1) What is the geography at this single point?
	2) What kind of terrain/topology between these two points
	affects the particular action I wish to perform?
	(attack, sensing, moving, etc.)  

There is a third question - "how do I present this geography to the
human player?" - which I am not ready to face yet.

Note (sorry if this was unclear, Ken) that I am only talking here
about things that require communication with the world.  Other
behavior ("acquisition, repair, communication, encumberance") can be
handled by or between the affected units without knowledge of the
world (though they may notify the world afterwards).

5. Protocols

Remember, our job at this stage is to define the problem and establish
protocols for communication between objects.  If we can define those,
then we can decide whether a general implementation will suffice.
Until then, though, it is probably not worthwhile to get too bogged
down in implementation details.

6. Location

The question of whether the clients or the server has the 'master'
copy of the location of pieces is a fairly crucial one, I believe.
Does anyone have thoughts on that?

A C++ class for a location might be a 3-vector with methods for:
	- distance from another location
	- determining if it is within a given region
	- finding the bounding-box of a given set of units 

The "location" vector could also include size (area covered) and
orientation.  The main advantage of (non-virtual) C++ classes is that
they are really just C structs, and hence can be trivially passed by
value as function/method arguments.


It seems we are getting into some fairly hairy technical issues, so if
someone wanted to post a quick review of DO under NeXTSTEP, that would
be very useful.

- Ernie P.
WarMaster