A Generalized approach to Client Server
[Documents/03.2-Generalize.txt]
Dustin L. Laurence, 30 Sep 93

I suppose I should point out here that I may be the only person on
this list who doesn't have a NeXT, has never used a NeXT, and doesn't
know any object-oriented language.  Ernie has described Objective C
to me very briefly.  While I think that it sounds like a nice
programming enviroment I don't intend to learn anything more about it,
at least until this project is much further along.  The reason is
because I think that having one or two people here who approach the
subject from a purely wargaming standpoint might be useful.  If I learn
too much about the environment that this is to be implemented in, then
I lose the advantage of not tending to think of the tools most easily
available when I try to figure out what would be most useful for
wargaming.

So I intend to approach the subject purely as a wargamer, and pretend
that I know as little as possible about programming.  I hope that
someone finds this approach useful.

>I don't think you can reduce topology and terrain to such general terms.  The
>*World objects (SquadLeaderWorld, SFBWorld, what have you) are all going to
>have to be written differently, I'm afraid.  You could probably parameterize 2D
>discrete maps, for example (square grid, hex map, path-connected areas, or what
>have you), but you probably couldn't generalize it to 2D continuous spaces.
>And I'm not sure you'd even want to.


I strongly suspect that we can treat regular tilings (square or hex
grids) as special cases of continuous spaces.  With less elegance,
we can do the same with graphs (path connected areas), if we allow
something equivalent to teleportation (which allows us to partition
the graph into pieces representable in a 2D or 3D space) or if we
allow spaces of arbitrary dimension.

[Discussion of relative complexity of clients and server]

The nicest model in principle would be a server which is smart enough
to take over all tasks and operate as a monolithic server if necessary,
while allowing the clients to take over whatever tasks the applications
programmer wishes them to take (and whatever tasks he is willing to go
to the effort to make them capable of doing).  This is quite possibly
impossible from a realistic standpoint, but remember what I view my
role to be.  This is what I would ask for as a wargamer hoping to use
the end product to implement some games.

>| This breakdown implicitly assumes that the only "spatial" interaction pieces
>| have is moving, sensing, and attacking.  Is that too simplistic?
>
>Yes.

Hmm.  Can you give some examples of tasks which cannot be done in
terms of the above activities, if they are understood in a suitably
general fashion?  I'm not actually convinced that sensing and
attacking are distinct activities from a fundamental standpoint.

>| Can other activities - for example, in role player games - be handled in
>| those terms, OR be handled player-to-player independent of terrain?
>
>Nope.  If only.  There's acquisition, repair, communication, and all sorts of
>secondary concerns (encumberance after acquisition, for example) that don't
>generalize very well.

Let's see if we can fit them into Ernie's paradigm, and then see if
the fits are elegant or cludgy.

Acquisition: an attack on an external object which has the effect of
adding that object to the attacking object's list of possessions
(attacks affect the attacker in many, many conventional wargames, so
we _must_ have this capability anyway; don't forget the time-honored
"Attacker Back 2" and "Exchange" combat results).  Encumbrance is
another effect on the attacker.

Repair: several cases, depending on the kind of repair and the time
model we use.  We have event driven vs. discrete time, and continuing
vs. one-time repair.

Event driven time: the server maintains an event queue and pings each
object when their next activity comes up.  In this category, we have:

One time repairs: Object pushes the time that the repair takes place
onto the event queue, and when the server pings it the object repairs
itself.

Continuing repairs: some options available.  Can handle like the one-
time case, but the object also pushes the next repair time onto the
stack when it repairs itself.  If the number of repair events needed
is known, they could also be all pushed on at once.  Finally, if true
continuous behavior (rather than the discrete activity outlined above)
is needed, the object simply pings the server for the current time
and saves it as the time it began repairs.  Each time the object is
activated by something (receives a message) it first checks how much
time has elapsed since its last activation, and repairs that much
damage before handling the event which woke it up.

Discrete time: presumably, this way the server pings every object at
regular intervals rather than at arbitrary intervals as governed by
the event queue.  I think that it is pretty clear that this case can
be handled if the above case can be.  In fact, that is why I think
that we ought to be able to handle discrete time as a special case of
event-driven time (the events on the event queue are regularly spaced
in time).

So I propose that if we can implement event driven time, then the
programmer can use either model as she wishes.  We may want to write
the code to handle discrete time within the event queue framework,
simply because it would otherwise be re-invented so often.  But at
the bottom it could still be a special case of the use of an event
queue.

Sorry, got sidetracked.  Communication: objects send messages to
other objects.  I don't see the problem.

>But I think that's about as general as you're going to be able to get on
>mapping, unless you have something insanely cool in mind.

Oh, boy.  Sign me up for insanely cool!

See my remarks above.  I don't know how well we can implement a
fully continuous model of space.  But if we can, a hexmap reduces to
restricting objects to 60 degree turns and multiples of a fixed
interval for moves.

I guess I'm arguing that if fully continuous space and fully continuous
time are feasible, then it is quite easy to specialise to hexmaps
and/or discrete time steps.

>I like real-time, myself.

Me too, where appropriate.  However, for a very large number of wargames,
it is _not_ appropriate.  Do you really want to play Third Reich at
one second = one second?  And do you really want to play Star Fleet
Battles at 1/20 of a second = one turn (though admittedly this last
example is silly only because the original designer chose a silly
scale).  Real time is more useful if we generalize the notion to
simply fixing the maximum time that is allowed for a task.  This
would allow it to act as a chess clock, for example.  However, there
will still be many games where we want the option of allowing as
much time as desired for a turn.

However, isn't it easy to allow the server to generate its time
interrupts either based on the system clock or based on completion
of previous tasks?  The former is real time in a generalized sense,
and the latter is not.

>| 4.  The stereotypical client-server problem is that of a database (a file
>| server just being a special case of a database, of course:).  Is that a
>| useful paradigm for thinking about the WarServer?
>
>Yes.  I'd like to see slightly more of the load on the clients, though, than
>your typical database server.  :)

Funny that you should argue yourself toward thinking of the server as
a database.  Peter Perla's breakdown of the elements of a wargame has
a database (in a suitably general sense) as a fundamental part.

I don't usually think of a database as generating messages on it's own
all the time, but maybe that's just me.

>| Well, I hope you enjoyed wading through this.  Please correct me if I made
>| any obvious blunders.  Also let me know whether you think I am approaching
>| the problem from the wrong (or right!) perspective.  Now, let the discussion
>| begin!
>
>Just be careful that you aren't trying to go for something too perfect.  The
>joy of object-oriented programming is that you have a bunch of building-blocks
>which you can then slap into a program in short order, rather than having some
>hypergeneric do-it-all object that does EVERYTHING.

Depends on the ambition of the project.  The other approach is to set
up a suite of objects which are extremely general, and then providing
a number of packages based on this which implement the most common
gaming paradigms.  This allows games with standard features to be
implemented easily, while still allowing those who want to to implement
non-standard games using the fundamental set of general objects.

I think that both are possible, but clearly the latter is far more
ambitious.  By nature I'll tend toward the latter, but it may be
outside the scope of this project.  But a sketch of how it might
work (remember that I'm not thinking very hard at all about how the
programming details might work, I'm just wishing as a wargamer):

Fundamental system includes:

(1) A way to represent and manipulate continuous terrain.

(2) An event queue manager for representing continuous time.

(3) Some objects which are suited to moving on (1) and taking their
    time cues (not queues :)  ) from (2).

Turn based package includes:

(4) Instructions for the event queue to generate discrete time steps.
    Does this really need a package?

Perhaps it also includes:

(5) Classes of objects derived from those in (3) which are already
    specialized to turn based time.

Hexmap package includes:

(6) Instructions for terrain which only has to vary from grid point
    to grid point

(7) Objects derived from those in (3) which are already specialized
    to move point to point in 60 degree turns and fixed distances.

Discrete game package includes:

Turn based and hexmap packages, plus

(8) Objects derived from (5) and (7) which are already suited for
    both packages simultaneously.

The point of breaking things up into several packages like this can
be seen from considering some (at least nominally) hexmap games.
Consider Africa Korps, Panzer Leader, and Squad Leader, three all-
time classic wargames.  If we can't implement these three, we are
fooling ourselves if we call this a general wargame package (though
they are not a terribly representative sample, being heavily biased
towards tactical games).

Africa Korps fits easily into the discrete package.  Movement and
terrain are entirely discrete.  Might be fun trying to teach the
system to see who is in supply, though (and this would be a
fundamental problem in very many operational and strategic scale
games).  If we had infinite time, we would certainly write a standard
way to handle questions of this type.

Panzer Leader (or its predecessor Panzerblitz, but I happen to own
PL) shows the first attempts to break away from the fully discrete
grid.  We can handle it as with AK, except that we must handle having
LOS/LOF (sorry, Line of Sight/Line of Fire) obstacles _along the
hexsides_.  Hexsides have been used like this at least since the
seventies, so we must be able to handle it.  If we think of the map
as continuous, using (1) and some of (6), and pieces from (8), it
works fine.  If we were fixed to hexmaps without an underlying
continuous system, we'd have had to put in the hexside features from
the beginning or kludge something up.

Squad Leader is something of a milestone in terrain representation,
where LOS/LOF is determined using terrain which is fully continuous
in two dimensions and discrete only in height.  Clearly no mapping
system which started from the hexmap would work at all well, while
if we started with (1) we are fine.  The pieces still come from (8),
because the pieces move discretely in discrete turn segments.

For variety, consider a minatures game.  Everything is fully
continuous, so we use only the turn-based time package and the
fundamental continuous representation of space.

I suppose that constitutes a vague proposal for what the wargame
applications programmer should see.  I'll just toss it out and let
the rest of you shred it to bits.

Dustin, who always wants more generality than is good for him