hassell@tramp.Colorado.EDU (Christopher Hassell) (08/10/89)
Hello all. I REALLY am the idiot who started all the blaring postings everyone
saw last winter. I've worked on the idea and I believe I've come up with
the final framework. It's structure is adequate and reasonable, I believe,
but the details are obviously a pain to flesh out completely.
For those not in rec.games.programmer I am talking about The Mailgame.
Description follows. Followup is to rec.games.programmer.
---- BACKGROUND : Game Idea from player's view
"mailgame" is descriptive only because I REALLY want to get the idea
across that this game would USE E-MAIL FOR CONNECTIVITY and therefore it could
exist with a huge playfield and hundreds of players, all connected together.
The basic principles of the game are these :
The game is a huge "simulation/database" which means that little
"objects" are kept everywhere and they represent everything that exists,
from falling leaves to entire star-clusters. All objects are generalized
sub-object-groups that they can break down into when detail is needed.
The game's actions come from "running" these objects in a simulation that
makes all the stuff happen in the game. In other words, the whole game's
one BIIIIG universe in which we make the rules, enact the rules and move
the pieces. As far as is necessary, EVERYTHING will exist in ONE
framework, and that means that the universe will have a real "map" to it
of x,y,z coordinates and "near" and "far" clumps of stuff.
MAIL SIMPLY CONNECTS THIS WHOLE HUGE DATABASE SO THINGS CAN MOVE AROUND
(this is not the side that the player sees, it is the programmers)
Player's actions are enacted through "robots" which are basically the way
a player does ANYTHING. Robots can have simple programs which just are a
set of commands that it will do when you tell it via communications, OR
OR OR OR robots can be complex smart suckers which can run vast armies.
I personally am not sure how players should approach programming them,yet
As you may have noticed, there was no statement of exactly what the
game-paradigm or what type of world it is put in. WELLLLLLL I am
INCREDIBLY partial to the one that was under discussion : SPACE WARS.
In this type of world, every system would have a solar-system as its part
of the database, and when you moved from system to system, it would be
okay to have the problems of mail affect you as you travel through
Interspace or whatever the game will call it. These problems are things
like bounced mail, the inevitable delay, botched and resent packets....
Interstellar space also has little of interest in it so there is no
reason for other systems to ever get things "wandering" back and forth
close to the "fault" between the systems' databases, and suffering with
tremendous delays and mail-load because of the mail-time.
NOTE THOUGH THAT OTHER SCENARIOS ARE POSSIBLE, LIKE MEDIEVAL EUROPE OR
INTERNATIONAL SPYING OR MODERN WARFARE OR LOTS 'O STUFF. So I want to
make the system whereby ANYONE can use it for their world-idea.
Note also that the space-war idea has no need for an "object" because
survival would be difficult enough, and protecting oneself from enemies
all the more important.
For those who would like to know why these are the general ideas :
The ability to have this game run on such a huge system as the Internet
would mean that the Internet or whatever mail-service is running would
have a net visible increase in load <When and only when it gets big:->.
This means E-mail shouldn't be overused and things should happen slowly
and not need zappo-zoom interaction.
Beyond this effect, sysads might take difference to ANY games being
"played" on their machines.
With those two issues in mind, I, already liking programming games,
thought that a strategic-style game and/or one that takes BIG
moves, like designing and producing a new robot X would be safely
UN-arcadelike and thus would not attract as much attention as a user
running one file for 3 hours <and they DO look for that stuff :->.
Beyond even that reasoning, I realized that BIG REMOTE actions via
E-mail are going to take Alot of time to percolate out if they have to
come from a "command-central" <i.e. you, a player>, and so PROGRAMMING
ROBOTS makes your brains go further and allows your little creations to
be your smart eyes and ears as they venture WAY out into southern
Australia's Nastiest systems :-> hehehehehehe. The guys who made
Empire knew this and made it a nearly programmable game.
--- DESIGN FOR A GENERIC SUBSTRATE TO THE MAILGAME
Okay... as I said, there is a possibility of having a VERY generic
substrate which basically "runs" the game, but DOESN'T have any of the
detailed rules/stuff the real Game is composed of, locked in on you.
This presents the opportunity to make a very versitile system that can
do many different scenarios and also which allows for mutation of the
game to improve playability. The general idea is that someone would
write a HUGE SET of stuff that would go into the objects that were
maintained in the game. This would be a sort of HUGE campaign-style
"module" that the game could run.
Another thing about this design-restriction is that it ALLOWS for
later development and for CHANGES IN THE GAME...as long as the
administrators agree with them and the game is not comprimised.
This would allow for things like "new technology" or "new frontiers"
and other incredibly nifty stuff.
The way that more detail would be facilitated is easy...just give
objects that used to be solid, unexaminable chunks the ability to break
down into the newly-supported objects. Possible things such as
"supply-lines" were used in the original discussion as an example in
breaking things down. First a "supply-line" would be a strange
military "device" that could take orders and could perform its job.
Later on, a supply-line could become composed of a set of small sites
along its path which actually have to be operating in order for the
flow to continue, and later still a supply-line could have a specific
fleet of ships/transportation that are employed and more and more
detail would be possible, with more problems and better solutions to
the workings of all of the things that are used.
In general there would be three types of objects:
- natural : these are unalterable objects that will always
exist and must be "patched" or have smaller
objects attached to them in order for them to
be changed. Solar systems and heavenly bodies
would be examples of these objects. As the
game changes, some things may have to become
considered members of the next type.
- substantial : these are objects which are simply considered
to be collections of one substance many small
parts all made out of one substance that has a
certain shape. These are able to be
"melted-down" and therefore can be destroyed
and or lost in a larger "natural" collection.
Examples of these objects would be discrete and
manipulable asteroids and other natural "things"
down to little rocks/bugs/trees, that
beings can manipulate. Robots and
space-ships would be in this realm also.
- data-objects : these are things that aren't exactly "real"
but which have an effect on the game. They
represent information and they are what
"communication" `moves' around. Other examples
of data-objects are technology-levels, and
military secrets and any information that can be
sensed and stored about anything anywhere.
----
Robot programming will obviously be a very important issue.
The main description of YOU as a game-object will be as a very brainy
A.I. that cannot be moved easily (because YOU, humanoid, ARE `connected'
to a computer-site and non-user robots aren't). The commands you give
would be to the robots at your disposal and their programming will
interpret commands you give them which might lead to them giving
further commands to more distant robots.
Robot-programming will actually be in something of an assembly-language
which will have a LARGE OBJECT-ORIENTED LIBRARY of procedures available
to it. Compilers will obviously be used and they can be written to
compile from any langauge. MANY MANY original "smarts" in the form of
library-functions will be provided and written already so that the game
will be fun from the beginning and things like calculating orbits will
not be necessary for programmers to do (mostly because other parts of
the system will do those same computations and they might as well let
you in on what they computed).
The assembly-langauge will be oriented around interpreting communicated-
"commands" as a form of interrupt which can change/induce action in a
robot depending on what the robot is doing at any point in time, it
will also be somewhat similar in ways to prolog, as well as being able
to use object-oriented libraries. Another possibility is that
"command-interrupts" will not stop ongoing processes and a robot may
be capable of limited "multi-tasking" except when tasks need to use the
same device to do two different things.
Sensors will be used to take readings and their data can be read by
programs or it can be kept in a recorded stream over time. Robots will
have amounts of memory to record everything they see.
NOTE BTW that the "viewing" of data that is sent back to the
user will be much better than the robots themselves trying to
interpret complicated information. THE OTHER THING is that
these data-objects may be viewed with ANY SORT OF USER-PROGRAM
that is available. This is an aspect of how the game can be
user-customized by having the user's preferred compiler and the
user's preferred data-viewing program(s).
Actuators will be used to make the robot "do" things that affect the
world. Things like RADAR <shooting out waves that bounce back> happen
by using actuators. Other things like mining and handling of stuff
also happens by giving actuators "commands".
One last thing that should be noted is that, in the future, "devices"
can be `compiled' that "do" things that would take much longer and
which wouldn't be easily manipulable. A prime example of this would be
getting an ACTUATOR's action (radio/light pulses/physical contact) to
affect a SENSOR's data. If that connection is predictable and good
then the pair can be "compiled" as a communication-link. This can also
happen and produce more complicated sensors or weapons or whatever is
accepted by the game.
----
One thing to take into account is that the context of this
program would be that of it as a program for a game-administrator
whose account would be considered "secure" and who would maintain the
game whenever necessary, though storage and cpu-time can be distributed
over all of the users at a site. This game would hopefully be operable
without ANY sysad participation or worry. <yes I think it can>
Security is very much an issue, but it would be handled better later on
in a much more effective manner.
-----
WHEW!!!!!!!!!!!!!!!!!!
I will lastly tell you all that this is merely an overview of the game-design.
I'll leave this for now and possibly add on a more formal and technical
description of the modules I feel are necessary. The outline of what needs to
be done is rather straightforwards and, I feel, logical, but the actual details
have not been figured out and some aspects of game-running are rather undefined
and need alot more work. My specialties, personally, have been the design of
the net-connections, the robot-language and the generic-style design, but that
is it so I leave the game-design to the net as well as some of the simulation
organization.
Again, please mail me if you are interested in getting a description of the
modules that I have designed. If enough support exists, I'll post the
technical spex.
I might post that design to let more of the net know what I'm up to. I would
also like to note for those who may see some changes they desire even as I
write, that I've tried to make this the MOST versitile and expandible
base-program for the game, with a touch of realism-capability thrown in to make
it even better. I don't see much that is necessary to change in this design
phase. Almost all of the modules have very specific duties and their
functioning would not be very complex, though with many objects supported and
many types of reactions between them, there is likely to be complexity added
on. Remember that I've lived through 500k of discussion that wandered through
almost all of these tenets, though alot of that wasn't always nice agreement
:-}.
Enough already. I REALLY hope this is a good general design-spec and I submit
it for interest in completing it and MAKING THIS WHOLE DREAM A REALITY!!!!
Heaven knows that enough interest has been shown in it (about 30 people posted
to the discussion which only lasted a month and more than 11 new ones have
asked for information after I piqued some curiosity this summer).
The Mail<Game> Man himself (among others)
### C>H> ### ( !uunet!rutgers! sunybcs!boulder! tramp!hassell )