Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.caldera.com!enews.sgi.com!arclight.uoregon.edu!news.maxwell.syr.edu!news-peer.gsl.net!news-paris.gsl.net!news.gsl.net!rain.fr!globalip.ch!imp.ch!SUNqbc.risq.net!news.risq.qc.ca!news.mcgill.ca!marina.psych.mcgill.ca!randalk
From: Randal Koene <randalk@marina.psych.mcgill.ca>
Newsgroups: comp.os.linux.misc,comp.os.msdos.programmer,comp.os.os2.games,comp.os.os2.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.programmer
Subject: TEXT VERSION: Real-Time On-Line Role-Playing Adventure - Concept
Date: Sat, 19 Apr 1997 11:45:11 -0400
Organization: McGill University Computing Centre
Lines: 180
Message-ID: <Pine.SUN.3.91.970419113946.1286D-100000@marina.psych.mcgill.ca>
NNTP-Posting-Host: marina.psych.mcgill.ca
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:170742 comp.os.msdos.programmer:79400 comp.os.os2.games:40250 comp.os.os2.programmer.misc:48464 comp.unix.bsd.freebsd.misc:39350 comp.unix.programmer:53210
Grumble, grumble...
I realize I rightfully received some email complaining about the HTML
tags all over my previous posts. And that in a message that is basically
a plea for platform independence! So here's the proper text version:
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Unlimited On-line Game
Unlimited Players
Unlimited Platform Support
Low Hardware and Software Requirements
Open and Expandable Environment
On-line Evolution and Growth
What got me thinking about this?
Unlimited On-line Game
Here's an idea for an unlimited real-time on-line role-playing action/adventure
game, playable by anyone with access to the internet.
Note that this text is also an invitation to any persons who would like to
cooperate and contribute to the development of a game such as the one I
describe, by helping to plot the story-line, specify rules, strategies and
aspects of the environment, programming on any platform or arbitrary
combinations of these items or any others you may wish to add!
A truly unlimited on-line game has to satisfy certain requirements:
It must accept any number of (simultaneous) players.
It must interface with any computer platform.
It must make low minimum hardware (& software) requirements.
It must have an open and expandable environment.
It must grow and evolve while it is on-line.
Here are some ideas how those requirements can be met:
Unlimited Players
Unlimited players, and necessarily also unlimited computer-generated and
maintained characters, clearly requires unlimited computational power on
the game server. As this is impossible, even undesirable, the reasonable
solution lies in a distributed network, as opposed to a single server. It
is a notion that makes a lot of sense in an on-line internet game where
every player brings with him/her some of his/her own computational power.
The usual problem encountered in such a set-up is the information transfer
bottleneck. Having a neural network background, I feel that the bottleneck
can be avoided as long as the system is truly distributed, instead of
merely distributing some tasks and then centrally collecting results.
The obvious way for a spacially oriented game such as an on-line real-time
role-playing adventure to retain true distributed qualities is to distribute
processing tasks according to area-specific activity densities. Each
contributing processor will be responsible for a limited area, and hardly
ever needs to know the condition of any areas but its nearest neighbours.
An analogy would be the cellular distribution of frequency bands, as used
in cellular telephone technology today.
The real neural network aspect lies in the self-organizing nature of the
distribution of duties, so that a shift in the allocated tasks per processor,
or the removal and addition of processors, does not require centralized
coordination. Neighbouring nodes must be aware of the attention requirements
of tasks in their area, and of the processing loads of themselves and their
connected neighbours. An imbalance must automatically lead to a self-organizing
shift in the distribution of duties. Considering the vast differences between
node contributions (e.g. an 80286 based node or a SUN Ultra workstation node),
the distribution of tasks must be relative to node capabilities.
An immediate advantage of this approach is also that the local client machine
of a player need not duplicate much of the work. Any information beyond the
scope of the player's area is irrelevant until it impinges upon the area's
neighbours or the area itself. The client machine is offering its services
as a server-node, and therefore has most of that area's information in
its local system anyway, hence requiring information transfer only on
the fringes. It is really only interactions between adjacent areas and
shifts in local focus or density that need to be transmitted between
neighbouring nodes.
Unlimited Platform Support
This is achieved in several ways. Firstly, the client requirements must
be absolutely minimal. In an adventure based on real-time interaction
according to a set of automated rules instead of action reflexes, it is
theoretically sufficient for the client to submit actions and conversation
as replies to nodes that are signalling to the player in the form of
simple email.
In this, its most primitive client incarnation, the game
can be played by absolutely anyone with an email connection, even on an
old Commodore 64. A player using this interface is a low-end contributor,
of course. He/she is not adding a server-node to the network. He/she is
interacting on a semi-continuous real-time scale. To the primitive client,
the game will be very adventure-like, with no graphics, no motion, but a
set of rules and an enormous environment that is impinging upon the
character in real-time. At the same level, but slightly more continuous,
is a connection through a character-based internet chat program.
The first step up, providing some form of server-node contribution, is a
character based platform independent compilable C-program, capable of
receiving and transmitting (through common protocols on Unix, IBM, Mac,
etc. such as TCP/IP, or optionally again through a chat or email
program), presenting client output and receiving client input, and
performing server computation tasks of the local environment as a
server-node contribution.
On the next higher level, we find what are
basically shells to the platform independent code, which convert the
basic environment information into graphics on commonly used platforms,
such as X-Windows, OS/2, DOS, Windoze and Mac. Those shells can be as fancy as
they like, with rippling water, swaying trees, birds and bugs in the
air, corresponding sounds, speech generation from the text of
conversations, combat scenes - anything the shell programmer would like
to put into it. The real-time element of the environment information,
even in its coded text format, ensures that graphical rendering will
seem quite life-like and active along the expectations of any current-day
3-D game.
Low Hardware and Software Requirements
This was all answered in the section above.
Open and Expandable Environment
The coding of objects and characters should be such that new combinations can
be added to the network at any time without having to update the software.
This is somewhat like the use of a DNA code to create an infinite variety
of creatures, without ever having to change the elementary components that
make up DNA sequences.
Essentially the game must have a language of its own
that can be used to program the environment within the consistent code of
the client-server node software (think of platform independent languages
like Postscript or Java that are understood by native programs on many
different machines and operating systems).
In terms of spatial and numerical
extent the game can be as open-ended, since the number of players is a direct
ratio of the number of processor-nodes, and the density in an area is
reflected in the amount of processing going on there. Players take their
processor along with the area that they are in, so movement into new areas
can spawn new sections of the environment on the server-node involved.
On-line Evolution and Growth
Using the expandable techniques above, scale, complexity and diversity of
the environment can increase both through automated evolutionary/genetic
processes and through changes released into the environment by human
authors (who need not necessarily be directly afiliated with the designers
of the game, as long as his/her creations adhere to rules that maintain
the playability of the game). Thus change becomes excitingly unpredictable,
while players are also able to contribute directly to the expansion of the
game.
What got me thinking about this?
I was looking for a nice strategy/role-playing game, when I came across
the Ultima Online home
page and had a look around. I was impressed with the grandness of the
idea behind a real-time game involving thousands of players as well as
computer generated characters. But from a programming point of view, as
well as from the view of someone with unlimited internet access on a
SUN workstation, but limited (costly) access through a PC at home and
no desire to spend much time on the archaic cpu power-trap Windoze95,
the game's system requirements seemed ludicrous. Add to that my neural
networks background, and my reasons are clear.
_____________________________________________________
RANDAL A. KOENE
PhD2, Department of Psychology - McGill University
randalk@marina.psych.mcgill.ca
Office: (514)-398-6133/4319
Home : (514)-527-3822
- OS/2 VirusScan: "Windows found: remove it? (Y/y)" -
_____________________________________________________