Ideas on game I want to write (long)
Rev. Joseph Miklojcik
ABSTRACT ABSTRACT
For yet another silly adventure game:
mage
APOLOGIA:
It has been said that zillions of adventure games have been written under
UNIX, and that yet another would garner only yawns from all the fun-loving net
people who actually play them. It has also been said that a good multi-player
version of one of these games would, at least, be a respectable achievement,
if not a roaring success. Thus I feel justified in trying. To all those who
will laugh at me for "wasting my time" I submit the following apology.
I became interested in computers at an early age because they provided me with
entertainment that matched my intellectual level. Computer games provided me
with a way to compete with an opponent that would win often enough to
challenge me, but not discourage me from trying again. The more I played, the
more I wanted to know about the machine that was playing me. I had to learn
how to use an operating system to run and maintain the game programs. I had
to learn how disk drives stored their information to be able to alter the
disks and cheat. After a while, I liked using the computer as much as I
enjoyed playing the game. Now, I know enough to be able to write my own game,
which has been a dream of mine since age 9.
SYNOPSIS
mage is a multi-player, interactive adventure game, written in the tradition
of other game with a similar user interface such as rogue and hack. In mage,
one takes on the role of a wielder of magic in a land much like Tolkien's
Middle Earth or Piers Anthony's Xanth. You can be either a Wizard, starting
out as an apprentice to a master (who will either be computer run or the
character of anohter experienced player), or a Sorcerer newly initiated into
the Towers of Fate, responsible to several members of a high council.
Characters will be able to meet in taverns, battle it out in arenas or other
environments, go on solo quests, perform magical experiments, and a multitiude
of other activities.
MAGE vrs. OTHER GAMES
Unlike other games of it's kind, life is not cheap in mage. Death will occur
only rarely, and in a land of magic, even that is not often final. Each user
will be allotted but one character per game, and the Wizards will often be
pitted against the Sorcerers as either race to find magical artifacts,
ingredients, and other resources to make their side more powerful.
Also unlike other games, mage is moderated by a single authority, or Game
Master (GM). All one needs to do to GM one's own game of mage is to get
permission from the system administrator, who will run the appropriate ware to
start you off. Certain people in a local mailing list will then be notified
that a new game is starting up. The GM is not required to be logged on to the
system at the time others in his or her game is being played.
The GM will have the capacity to change factors in the environment of the game
at almost any time, although he or she will be forging most of these decisions
at the start of the game, when databases filled with maps, statistics about
the game world, and behavior settings for non-player characters are created.
This creative process is greatly assisted by well-tested default maps, etc..
These databases and options, once established, form a specific scenario.
Further departing from the traditional rogue-like adventure game, games of
mage may last for indefinite periods of time. If the GM wishes, he or she may
set specific victory conditions for the Wizards and the Sorcerers, or may
claim that victory is personal, and achieved for any player when that player's
character reaches "mastery."
Game balance is stressed in mage. Since groups of players will be competing
in some scenarios, the odds must not favor either side in any way. Of course,
the number of players on either side will be nearly random, since the decision
to become either a Wizard or a Sorcerer is completely dependent on each
individual player at the time his or her character's creation. However, the
side with fewer players will make up the difference by having more resources
per player. Randomness is rare in mage, allowing for greater use of strategy
and planning. Players walking into known situations will have a good idea of
whether or not they will be sucessful beforehand, but the game is complex
enough to make most situations not completely predictable for even the most
veteran players.
CLIENT/SERVER MODEL
The multi-player and GM features are accomplished through the use of a
client/server model of programs. When the player runs mage, it will start up
a client program that will communicate with a central server program. This
model yields several benefits:
1) It allows system administrators the freedom to stop people from eating cpu
cycles by playing games. By simply running a special super-client program,
the administrator tells the server not to play until some special time. This
is a great improvement over the old method of either broadcasting a message
"stop playing games for chrissake" or simply halting the system and rebooting.
2) It allows the game to reference databases constructed by the GM, without
fear of collisions. Since only the server will be using the database, it can
perform all accesses sequentially.
3) It facilitates player communication. The server handles all security and
special requests such as "ignore all messages from player x."
MULTI-PLAYER SOLUTIONS
The multi-player feature is not completely continuous throuought all parts of
the game. Different players will only be able to truly interact in certain
parts of the game, such as an inn where they can talk or trade objects.
Players can exchange tips and rumors for money, listen in on other players
using spy spells, and interact using a rich command set.
In other situations, such as exploration of underground labrynths, players
will operate alone, but their environment will be continuous. This means that
if a player leaves an object in a given room, another player will be able to
come and get it. These situations will be closed to all but one player at a
time, therefore at certain points during the game, speed in real time will be
required. These situations are kept to a minimum.
For the rest of the game, play is solo. This is necessary due to timing
problems; all players must give their moves before results can be processed.
If this were to be continuous over the entire game, it would take too long to
process each move. However, using certain spells, players can spy on one
another or send messages to one another. This can be accomplished without
preposterous turn processing, since these functions barely require
synchronization.
Jon W{tte
>It has been said that zillions of adventure games have been written under
>UNIX, and that yet another would garner only yawns from all the fun-loving net
So, where are these adventures ? I'm sort of an adventure collector,
but my collection is close to nonexistent. Anyone who has an adventure
for UNIX sys 4 or V (Or the Mac or the PC...) and wants to share it,
please mail me!
>SYNOPSIS
[.. Loooots of stuff deleted ...]
>MULTI-PLAYER SOLUTIONS
>
>The multi-player feature is not completely continuous throughout all parts of
>the game. Different players will only be able to truly interact in certain
>parts of the game, such as an inn where they can talk or trade objects.
>Players can exchange tips and rumors for money, listen in on other players
>using spy spells, and interact using a rich command set.
I like this idea. I've thought about it a long time. Games are made to be
fun, not realistic (unless that's "fun")
I am currently working on a play-by-electronic-mail game called It's Cyber
(No coding, I'm the game designer/balancer) and a multi-user core-war
spinoff called RobotWar (It was available on the Apple II back in 1832)
both for a UNIX sys V(&4) computer. I would very much like to get into
the development group for this game, as I feel I have a few hours to
give and a few tons of unused creativity left.
I like your idea, Joseph, and feel free to mail me. We could set up a
development group. (I also make a living programming, so I KNOW how
much administration is involved !) Reasonable first sys req:
1) BSD UNIX sys 4.2 or 4.3, Server-client comm. via sockets OR
SYS V.2 or V.3 UNIX, Server-client comm. via message queues
2) Game dialogue in old-fashioned "prompt & answer" style
Random world generation
3) Basic player interaction (sending messages, meeting in arenas
(to which you have to travel) trading in markets)
4) Game written in ANSI-oid C, each participant has his own well-defined
job to do. All communication between game pieces is "objective",
NO GLOBALS !!!! (This requires a "World" pointer in EVERY function call)
This makes the game MUCH easier to implement and makes for fewer bugs.
SO, anyone else for this idea ? Email me, or Joseph, or post to get more
people going! Estimated first beta release (mage v1.0b1): Early 1990.
--
__ Jon W{tte (The dread Smiley Shark) email:h...@nada.kth.se
/ \ (+46 (0) 8 258 268)
/--- (c) 1989 Yessbox Allright Professional Products Inc. - Y.A.P.P.I.
/ -- No More --
Rev. Joseph Miklojcik
That last post was meant as a plea of suggestions and comments. I
would love to hear from you! Send your stuff to:
I'll write you back, I swear.
Also, If any of you can help me find someone or some source that can
help me decipher the manuals I have on writing client/server programs,
I will be forever in your debt!
Liberal and Gratuitous thanks --
-- joe
Jon W{tte
>d88...@nada.kth.se (Jon W{tte) writes:
>|4) Game written in ANSI-oid C, each participant has his own well-defined
Read carefully ^^^^^^^
>If you write your game in ANSI C, you aren't going to have very many players.
>Most sites are still using pcc.
I think we could use a version that's compatible with both... maybe with
different header files or something. I mean, we can't stop evolution by
staying in the middle ages, can we. Besides, it's the writing that's the
fun :-)
Also, it isn't my game, it's Josephs. But your ansi->pcc converter is
very welcome indeed, if you choose to contribute :-)
Thanks for pointing it out, as I said, there's a LOT of planning in
writing a game of this size.
Ken Seefried iii
>| job to do. All communication between game pieces is "objective",
>| NO GLOBALS !!!! (This requires a "World" pointer in EVERY function call)
>| This makes the game MUCH easier to implement and makes for fewer bugs.
>
Given a choice, I would write it in C++. Vastly superior
implimentation language, and the features lend themselves to this kind
of a system...
>If you write your game in ANSI C, you aren't going to have very many players.
>Most sites are still using pcc.
>
>Sean
You mean not everyone runs GNU CC? And GNU G++?
#include "BigSmiley.pic"
...ken
ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs,
k...@gatech.edu masscomp, rlgvax, sb1, uf-cgrl, unmvax,
ut-ngp, ut-sally}!gatech!ken
Sean Casey
|4) Game written in ANSI-oid C, each participant has his own well-defined
| job to do. All communication between game pieces is "objective",
| NO GLOBALS !!!! (This requires a "World" pointer in EVERY function call)
| This makes the game MUCH easier to implement and makes for fewer bugs.
If you write your game in ANSI C, you aren't going to have very many players.
Most sites are still using pcc.
Sean
--
*** Sean Casey se...@ms.uky.edu, se...@ukma.bitnet, ukma!sean
*** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted.
*** ``I'm a state machine with no state!''
wilson m liaw
>>d88...@nada.kth.se (Jon W{tte) writes:
>Given a choice, I would write it in C++. Vastly superior
>implimentation language, and the features lend themselves to this kind
>of a system...
>
>
Which c++? There is c++, and then there is g++. There is a difference.
On this point, I agree with Ken, c++ would be a better choice. I have
never written a game in anything other than 68000 assembler language, though.
Mac
-=-
Wilson Mac Liaw $ Two sure ways to tell a sexy male;
Internet : macg...@cis.ohio-state.edu $ the first is, he has a bad memory.
CompuServe : 71310,1653 $ I forget the second :)
GEnie : W.Liaw $
Christopher Hassell
jm...@topaz.rutgers.edu (Rev. Joseph Miklojcik) writes:
#It has been said that zillions of adventure games have been written under
#UNIX, and that yet another would garner only yawns from all the fun-loving net
#people who actually play them. It has also been said that a good multi-player
#version of one of these games would, at least, be a respectable achievement,
#if not a roaring success. Thus I feel justified in trying. To all those who
#will laugh at me for "wasting my time" I submit the following apology.
Puhfoooey on those that might.
#SYNOPSIS
#
#mage is a multi-player, interactive adventure game, written in the tradition
#of other game with a similar user interface such as rogue and hack. In mage,
#one takes on the role of a wielder of magic in a land much like Tolkien's
#Middle Earth or Piers Anthony's Xanth. You can be either a Wizard, starting
#out as an apprentice to a master (who will either be computer run or the
#character of anohter experienced player), or a Sorcerer newly initiated into
#the Towers of Fate, responsible to several members of a high council.
#Characters will be able to meet in taverns, battle it out in arenas or other
#environments, go on solo quests, perform magical experiments, and a multitiude
#of other activities.
I personally like the life of a magic-user more as well. This is probably
because they have so much more stuff to deal with and, in some of the best
scenarios, they even have very interesting permutable-magic (make up your
own spells).
I would also support making life a more valulable commodity in a game.
Games when several lives are used are really not going to "synch" with the
way we wish we could be in the adventure...living it.
Quests for magical artifacts and the power of learning how to use them,
BEYOND all the silly kill-this-race, or save-this-queen plots would be very
attractive if it did resemble normal D&D.
#The GM will have the capacity to change factors in the environment of the game
#at almost any time, although he or she will be forging most of these decisions
#at the start of the game, when databases filled with maps, statistics about
#the game world, and behavior settings for non-player characters are created.
#This creative process is greatly assisted by well-tested default maps, etc..
#These databases and options, once established, form a specific scenario.
I believe that algorithms are possible that can forge perfectly adequate
adventures from a random use of rules that make the randomness cohesive.
Using play-tested maps and NPCs and worlds, in general, always leads to a bit
of stale adventuring.....but only because parts of the game are repeated
exactly, which can be quite irritating.
#Further departing from the traditional rogue-like adventure game, games of
#mage may last for indefinite periods of time. If the GM wishes, he or she may
#set specific victory conditions for the Wizards and the Sorcerers, or may
#claim that victory is personal, and achieved for any player when that player's
#character reaches "mastery."
I also am a strong believer in having a vague game-goal like what you say. I
think that, as we do in real life, there is no reason to win/end after doing
something....or even to know adequately what actions will "benefit" you, other
than ones that give you experience. Making you play into a story is
interesting and very enveloping if it is done right, but life goes on and we
always have to do more after a great achievement.
#per player. Randomness is rare in mage, allowing for greater use of strategy
#and planning. Players walking into known situations will have a good idea of
#whether or not they will be sucessful beforehand, but the game is complex
#enough to make most situations not completely predictable for even the most
#veteran players.
Other than the bit of randomization I would want for the initial scenario, I
have been cradling an idea I very much wish to put into practice once it has a
good test-bed to live in. In general it is basically the use of "abilities"
in sensing happenings/objects, AND the provision of a large number of possible
"distractions" that are simply more like the boring details that exist all
around us. If you are listening for the sound of an enemy, why shouldn't you
jump once or twice at a rabbit rustling in the bushes? (random, of course) I
find the lack of detail, even boring detail, to totally stifle the illusion of
reality in most games. If an amount of skill was attributed to recognition of
any of the things that we must detect in the game, beginners and masters would
truly find the "experience" score to have more meaning as "experience" and
knowledge, instead of better muscles and dexterity and charisma etc.. (barf).
That is the only other form of randomness and complexity I would love to see.
#MULTI-PLAYER SOLUTIONS
#For the rest of the game, play is solo. This is necessary due to timing
#problems; all players must give their moves before results can be processed.
#If this were to be continuous over the entire game, it would take too long to
#process each move. However, using certain spells, players can spy on one
#another or send messages to one another. This can be accomplished without
#preposterous turn processing, since these functions barely require
#synchronization.
It certainly does help the entire synchronization problem if meetings and
interactions (even the altering of one's environment, say, by placing an object
somewhere). I am still fascinated by what a game could be if interaction was
more supported, but alas, that is dANG-O-DANg complex and not too likely to be
done any time soon.
One last thing I might say is that to better keep players apart, the plot might
be changed a little to make only one "side" and two factions for player
characters to be on. If players are more independant and have nothing and no
one to cooperate with then there will be alot more exploration and wanderings,
possibly even enough to find several sub-plots which can be tied in deeper,
later on.
Jest suum musings by your local Reality-Abuser.
### C>H> ###
Neil Gilmore
>In article <Jul.17.05.02....@topaz.rutgers.edu>
>jm...@topaz.rutgers.edu (Rev. Joseph Miklojcik) writes:
(basics deleted
>I personally like the life of a magic-user more as well. This is probably
>because they have so much more stuff to deal with and, in some of the best
>scenarios, they even have very interesting permutable-magic (make up your
>own spells).
A guy over in rec.games.frp has a neat system for this type of
magic. The spells, however, do tend to look like programs.
>I would also support making life a more valulable commodity in a game.
>Games when several lives are used are really not going to "synch" with the
>way we wish we could be in the adventure...living it.
>#Further departing from the traditional rogue-like adventure game, games of
>#mage may last for indefinite periods of time. If the GM wishes, he or she may
>#set specific victory conditions for the Wizards and the Sorcerers, or may
>#claim that victory is personal, and achieved for any player when that player's
>#character reaches "mastery."
>I also am a strong believer in having a vague game-goal like what you say. I
>think that, as we do in real life, there is no reason to win/end after doing
>something....or even to know adequately what actions will "benefit" you, other
>than ones that give you experience. Making you play into a story is
>interesting and very enveloping if it is done right, but life goes on and we
>always have to do more after a great achievement.
I would prefer that, as in life, the players set their own goals.
(more stuff deleted)
>One last thing I might say is that to better keep players apart, the plot might
>be changed a little to make only one "side" and two factions for player
>characters to be on. If players are more independant and have nothing and no
>one to cooperate with then there will be alot more exploration and wanderings,
>possibly even enough to find several sub-plots which can be tied in deeper,
>later on.
Wouldn't it be more interesting to have no sides or factions
inherent in the system? I'd bet money that after a while, the players
would form their own sides and factions.
>### C>H> ###
+-----------------------------------------------------------------------+
| Kitakaze Tatsu Raito Neil Gilmore internet:gil...@macc.wisc.edu |
| Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 |
| Middle Kingdom Madison, Wi |
+-----------------------------------------------------------------------+