I'm pretty sure MazeWar does use PUPs. When you boot, there's a
"Host" option that lets you specify an arbitrary network address on
the Internet in order to join that machine's game. Thus it should
be possible to play between say, England, Rochester, and El Segundo,
although the response might be a bit sluggish if some players are 4
or 5 hops away.
It is true that it's possible to "cheat" by running a kludged-up
version of the program. That's why the sources have been
(informally) carefully guarded over the years.
Kudos should go to the author of MazeWar, Jim <Guyton @ Rand-AI>.
Date: 2 September 1982 0034-EDT (Thursday)
From: Craig.Everhart at CMU-10A
Subject: Re: MazeWar game for Altos
I stand corrected. Jim Guyton already pointed out my error
privately; enclosed are some of his remarks about how it gets the
job done. My comments were based on my bad memory of having peeked
at the network traffic; I apologize for any damage done by my faulty
- - - - - - - -
Date: Wednesday, 1 Sep 1982 20:19-PDT
Subject: Re: Mazewar
From: guyton at RAND-UNIX
Every player simply sends a single pup to every other player in the
game on every change-state. 90% of the time this is in response to
the player moving -- which is very infrequent compared to the
capacity of a 3Mbit Ethernet (and the Alto).
Each packet is not acknowledged; the assumption is that most of them
get through and the ones following a lost packet make the lost one
out of date anyway. Not entirely true, but good enough for a game!
Of course the small number of people allowed in a single maze does
help keep the communications overhead down. But the limit was to
prevent crowded mazes, not because of communications.
The only broadcast msgs are those when someone tries to join a game.
To join a game on another network you have to supply net#0# as the
duke-rat host number. It has been a long time since I left Xerox
and even longer since I leaked a version of mazewar to the
universities; but I think that that version "supported"
multiple-network games. Certainly the current version does.
Date: 6-Sep-82 15:06:06 PDT (Monday)
From: Reed.ES at PARC-MAXC
Subject: Re: HUMAN-NETS Digest V5 #89
"As I've overheard it, the main program for the game resides
on a Gateway, with relatively low-bandwidth screen
"transactions" being sent to the individual players'
machines (vs. fully updating each screen remotely)."
Mazewar operates as follows:
Up to 8 players may play. There are indeed three windows, but you
didn't describe them quite correctly. The top window shows the rat's
eye view of the maze: looking down the corridors as if you are in
the maze. The middle window is the bird's eye view you describe, and
the bottom window is also as you describe it.
Each game. when started, searches for existing mazewar games on
the local net (or a net specified by the user). If none are found,
it establishes itself as King Rat. Other games starting after the
King Rat game hook into the King Rat, which maintains the game's
database. The King Rat is listed first in the scoring area.
A game will also establish itself as King Rat when it can't enter
an already in-progress game. Thus multiple games may exist. A user
may choose which game to play by specifying the host number of the
King Rat of the game desired. This is usually found out by agreement
among the players, but the searching algorithm simplifies it.
No gateways are involved except as they fulfill their normal
functions of linking networks together.
"There is no centralized service for MazeWars; in fact, I
think it's impossible to play the same game on different
Ethernets, since the packets it uses aren't Pups, and
therefore aren't transmitted by Pup gateways."
-- Craig.Everhart at CMU-10A
This is totally incorrect. A game may be played between any machines
that are connected over any number of gateways. (I once played a
game where I was in Rochester, NY, and one opponent was in El
Segundo, CA, and a third in Palo Alto, CA. The response time was not
much worse than in a local net game.) The data packets themselves
are stuffed into Pups and transmitted/received as any other Pup is.
Your claim is more accurate for TREK (see below) than for Mazewar.
When Mazewar was first introduced, the net traffic it engendered
resulted in the management at Xerox edicting that people would not
play during working hours. It was a very popular game. The inventors
even had programs which could smash an arbitrary Mazewar program (by
sending a quit packet to it) when people were deemed to be causing
TREK's speed depends noticeably on the number of players playing,
although I don't think this is because of net traffic so much as
machine limitations. TREK operates by sending all packets to a
standard address, and each instantiation of it listens to that
specific address. This caused a lot of problems early on since the
standard address was not always available on a given net, and since
a TREK game is limited to a single network (multi-network addresses
were not supported; this may have been fixed, but I don't know), you
couldn't always predict when TREK would interfere with someone on
your network. Of course, one could always reserve specific addresses
for TREK, but that kind of thing doesn't always sit well with
TREK's use of distributed databases essentially results in every
machine having a copy of certain public information. Certain other
information is not public - like the state of damage to a given ship
(all the outside games see is the level of the shields and perhaps
some erratic movement.) This has certain advantages, like preventing
the game from being dependent on the status of a particular
participant. However, just choosing random addresses is not a good
idea, as we found out. Better would be to have the initial game use
it's own address. A machine need not be up in order for other
machines to listen for packets sent to it. And the fact that that
game established its own address as a valid destination for game
packets is an indication that the machine is not going to be
interfered with. Of course, if the game outlasts the initial
machine's involvement (since that player quits before the game is
over), the use of its address would be a performance problem. In
this case some mechanism should be established for switching the
broadcast address to one that is currently involved in the game.
-- Larry --
Back to Maze War Retrospective
Please send site comments to our Webmaster.
Please see our notices about the content of this site and its usage.
(cc) 1998- Digibarn Computer Museum, some rights reserved under this Creative Commons license.