|
© Gil Williamson 1999 and 2005
Last Update 9 Feb 2005
|
|
game2
Ice Bridge - The Game Concept - Mechanisms
The principal mechanisms we would use to deliver the game would be
web pages, email and (to a limited extent)
Search Engines. The game might spawn a newsgroup if it
were successful, in which case the DMs might inject some
messages into that, but not as part of a running game.
A certain amount of data would have to be held against each
group. I am against cookies, but am for centrally-held passwords and
progress data.
A player would apply to participate in a game, and would be
allocated companions with whom the player would only
correspond by email or "chat room".
I think that there should be a minimum of server-side cgi. For a
start, many potential DMs will have no ability to set up
server-side cgi, and we should restrict ourselves to a few
centrally held functions that all users can use and all DMs
can exploit, like sendmail, Although
Javascript and even Java are "crackable", it will spoil the users'
fun if they actually do cheat, and we can place traps that ensure
we spot cheating when it happens.
Web Pages
Among the deliverables on web pages might be:
- Simple text and pictures;
- Image map pictures, on which point-and-click would lead
to other pages or to Javascript pop-ups;
- Animated gifs;
- Perhaps Shockwave images like this;
- MIDI sounds;
- Coded messages in text or pictures;
- Puzzles - Javascript-driven or otherwise - there
are at least 30 categories of puzzle one could deliver;
- Calculations to do;
- Things to remember;
- Forms to fill;
- Forms which generate email;
- Microdot pictures, downloads and links;
- Bogus web cams, both static and controllable;
- Bogus Newsfeeds;
- Chat rooms;
- Java applets
While this does not include the scenes of wholesale massacre by
automatic weapons normally associated with computer games,
many fine games, from Colossal Cave to Myst and beyond have been
delivered with technology no better than html and client-side Java
and Javascript. Actually, I suspect little programming will be
necessary.
I'd be against early extensive use of big-volume media such as large
Java applets, mpeg, wav, large images, etc. just because of
download time. However, user
tolerance to download rises in proportion to the anticipated
fun.
Email
In order to render the game more personal, email to and from the
participants might be used, strictly on the basis of necessary
information. Examples of its use might be:
- Informing a user about events that are happening to that
user's group;
- Giving a user a password or code key to enable their
group to progress;
- Email generated by a user in filling a form to let the
system know what the user's group wants to do, or to make
some assertion, or ask a question.
Search Engines
First, it would be possible to build a search engine dedicated to
the game system. As ever, a search engine is only any good if
you know what question to ask.
However, Google and Yahoo don't seem to mind storing odd references
to web pages. About two days after the URL is given to them,
it is visible for searches. So, if the keywords we gave it
were extremely uncommon, or simply invented, and the page content
were only a set of links, we could plant clues for players in
any responsive search engine.