Random remarks (time, DO)
[03.4-Remarks.txt]
Don Yacktman, 1 Oct 93 
[plus comments by Dustin Laurence]

I've been reading the discussions of late, but haven't had
the time to make any deep comments.  However, one thing at
this point that I would highly recommend is to actually
_look_ at a few war games that have been implemented on
the net (under X or whatever) and point out both the good
and the bad in their respective designs.  (Then of course,
we take the good and build on it where feasible.)  The
theory is fine, but without concrete examples, we'll get
nowhere fast.  (Of course, there have been some very good
concrete examples in the discussions, too...but I'd like
to see a bit more.)  Oh, and note that one possibility
hasn't really been considered yet.  Many games have the
client and server in the same app; either what would
normally be the server's job is distributed amongst the
clients or the first client to come up designates itself
as both client and server to everybody else.  (I think
that Bolo on the Mac uses a scheme to that effect...)

Anyway, rather than comment on specifics from the previous
postings, which I haven't got time to do right now, I'd
like to mention a couple of other things which might be
of interest (or might not; you decide).

First.  Time handling.  There's lots of ways to do this;
one might be a steady clock pulse sent to each respondent
every game cycle, whatever the cycle ends up being.  Or,
if there will be lots of "dead" cycles, you use the event
queue idea.  Event queues are really attractive for many
situations, of course, and have a long history of use in
real-time situations.  In the MiscKit, I am adding an
ordered queue object which is an extension of the event
queue I used in a CPU RTL-level simulator a couple of
years ago.  The queue sorts events as it gets them and
then dispenses them in order.  It is very fast, and uses
a heap data structure internally to get its speed.  In
some game situations, you'll want to use this, I'm sure.
Note that there is a simple one-method protocol which,
if followed, allows _anything_ to be sorted as it goes
into the queue, and so you can sort by time, priority,
or whatever have you...  I just thought you might like
to know that this free object will be available to you.

Another comment on times.  This is a problem I had to
solve with my arcade-style games, but in a wargame which
does real-time simulation and simultaneous events are
possible, there is another unique problem.  Let's say
you have three objects in a simulation.  Each one chooses
it's next move based upon the position of the other two.
And each is expected to move at the same time, without
any knowledge of what the others will do.  (In some cases
this might actually be an issue, in others it isn't, and
in most table games, this would be an ideal, but isn't
possible to achieve, so it's thrown out...but computers
_can_ do it.)  The problem, as you can guess, is that
I can't move them all at once; I have to do it in some
(arbitrary) order.  And that means that whichever one
goes last has the advantage of knowing the other's moves
and can therefore act with extra knowledge that the
first objects did not have!  In an arcade-style game,
this can cause all sorts of race conditions and weird
bugs, requiring you to watse cycles on sorting out
turns as you add and remove objects from the game.  A
much simpler solution is to take a turn in two phases;
everyone decides (1) where they will go/what they will
do based upon current simulation state, and (2) then
they all move, without being able to change decisions
based upon other's moves.  In a table game, each player
would write down what their move is to be, and then
when all are done, the game master collects the moves
and executes them.  (Or, if a client can be trusted,
it moves.)  Anyway, I think that you'll find many of
the considerations of an arcade game actually are things
to think of in some war game situations; just that a
single time frame may be much longer, allowing for
strategy to win a game rather than reflexes...  Note,
at any rate, that this whole thing implies that the
nature of a server and client will be dependant upon a
particular game.  I think the most realistic thing we
can hope for is a collection of objects that can be
used to build up the kind of servers and clients that
we want to have.

As a final note, I do have NeXT Distributed Objects
experience, but I am far from being any sort of expert.

For an example of a client-server, though, you might
want to take a look at the highscore system that the
GameKit employs; it is an actual DO implementation
that might spark a few ideas.  I've spent a lot of
time on it, and the system I finally arrived at is one
of having reasonably intelligent clients.  Basically,
a client will check in to the server upon launch and
get back in response the complete, current, high score
table.  When a new high score comes around, the client
checks to see if the score is good enough to get into
the local table.  If it is, the score is inserted and
then forwarded on to the server.  Then the server
sees if an insert is possible...if it is, the insert is
performed and then forwarded to each client for insertion.
If it doesn't fit (meaning that a forwarded message and
the current one crossed paths between the client and
server) the score is discarded.  There's a lot more
involved, of course, but that's the overview.  Basically,
each client keeps a local copy, and acts upon it; the
server's job is that of a distributor cap to keep things
in sync between the clients.  And a final note.  I've
found that even on my in-house LAN, DO can be rather slow.
We may want to forego DO in certain speed critical
situations and build our own message-passing objects
that use sockets or what have you.  DO is definitely
way too slow to do something like xpilot, for example...
though it would be fine for a slower paced game (which
would include many, but not all, of the games mentioned
already in this forum).

Well, if there are any specific DO questions, I'll try
to answer them.  I have a pretty good feel for what they
can and can't do, and they actually can handle a lot of
the concerns already raised.  (Like, if you do client-
client connections, how do you notify of client deaths?
DO does it automatically.  All you need is the code to
deal with the situation, which you'd need anyway.)

Well, I know those thoughts don't completely dovetail into
the current theoretical discussion, but at least they are
things to think about.  What say we look over a few
examples of existing games and see what we do or don't
like about them?  It could be enlightening.  Especially
since what's nice in theory may not work very well, especially
performance-wise, when it comes time to implement, and so
we really ought to know what the tradeoffs and existing
solutions are...

Well, thanks for your indulgence...

LAter,
-don
======
I'd like to echo some of Don's remarks on timing.  What he describes is
known in the wargaming community as "simov", or simultaneous movement.
SPI (Ernie asked for me to expand some of my wargaming acronyms; SPI
stands for Simulations Publications Incorporated, though _nobody_ ever
referred to them as that as far as I know; they are in essence defunct
now) and others did a lot of experimentation with simov--in the
seventies, I think.  For manual board games, the bookkeeping is usually
too much.  It works in naval and air games, and other games where the
number of distinct units is small.  But for general games, the problem
has so far been insoluble in the manual boardgame format.

So much work went into trying to make simov work because it obviously
reflects the simultaneous nature of war better.  The complicated phased
turns of many modern games is a direct result of the quest for the effect
of simultaneity; many interleaved phases each turn are a compromise
between simov and "I move, you move" games.  Squad Leader (which seems
to be popular on this list) is a fine example of this last technique.

A computer game has in principle no extra bookkeeping chores when doing
simov, and (I contend) should be exploited as much as is feasible in
computer wargames which use turns.  I think we should support the
applications programmer in using simov as far as is possible (while not
requiring it in those cases where it is not desirable, of course).  This
is one of those pieces of wargaming technology which seem to require a
computer for full utilization.  In fact, simov and (particularly)
realistic fog-of-war techniques by themselves would justify computerized
wargames.

Dustin