Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!olivea!tymix!tardis!udwarf.tymnet.com!carl From: carl@udwarf.tymnet.com (Carl Baltrunas & Cherie Marinelli 0.1.9) Newsgroups: comp.sys.mac.games Subject: Re: RPG opinions (was Re: Programmer...) Message-ID: <0B030501.NJ1UOH@udwarf.tymnet.com> Date: 15 Nov 90 07:43:08 GMT Reply-To: carl%udwarf@tardis.tymnet.com Organization: Catalyst Art Lines: 71 X-Mailer: uAccess - Mac Release: 0.1.9 In article , draphsor@elaine0.stanford.edu (Matt Rollefson) writes: > .......... We're asking for a > program to model a dynamic world now. Most game worlds are static - > they don't change until the player comes along. In a real simulation, > things should be happening despite me as well as because of me. This > becomes extremely difficult to program, though. > Draphsor vo'drun-Aelf draphsor@portia.stanford.edu I had a design once for a game called Amazon, set in the amazon jungle and some caves/dungeon nearby (why is there always a cave or dungeon?). Anyway, the game consisted of rooms, objects and players (real and npc). The idea was to have the game maintain all the players and randomly move the npc's that were not part of your party as well as your character and your band of npc's. The movment of npc's was to be according to some role-script and not entirely random. That being the case, the only reason your band fights on your side is because their scripts have a "loyalty" factor built in. If you treat them well, the loyalty factor goes up, if not, it goes down and there is the chance they will attack you (or each other, since they have varying loyalty based on their scripts). Next, the characteristics of all players changes with experience. If you do a lot of fighting, your strength increases. If you make a lot of good decisons, your wisdom goes up. If your move quickly, your agility increases... etc.. for all of the different capabilities. Spells work better the more you use them. (An aside: Read "The Practice Effect" by David Brin, Bantam Books, April 1984, for an example of how tools work better the more you use them, and become dull and useless if they are not used for awhile. Interesting concept.) Also, for some reality, if you happen to be a band of level 3-5 characters and walk into a room with a couple of 9-15 monsters, they may very well be fighting or not, but they'll probably ignore you since you're not much more that a samll nuisance to them (eg. like flies at a picnic). If you attact them, they'll kill you with once swat (if they connect), but otherwise they won't bother you. The major impetus for this design was that most CRPC games were single user, you and your guide vs. the static computer. My game was to be dynamic and allow for multiple players to come and go (or play simultaneously from different access points [vis. terminals]) with all movement of players and objects kept in a shared database (also shared memory on the machine it was designed for) so you could play as player-1 for a while and then as player-2, etc. Whenever your player wasn't connected and playing, you (and your band of npc's) were expected to be sleeping (so it was a good idea to find a safe haven to make camp). If another player came across your sleeping band, they could wake up your npc's and/or kill/rob/bribe them away from you. [Loyalty values again, a single npc could have many loyalties, again a touch of reality] An npc might also join another band (depends of their script) to stay alive, but if they encounter you the best loyalty may win out. Rooms, puzzles, monsters, objects, players corridors were designed as objects that had properties, and could be added easily while playing the game (if you knew how). The idea here was to have the game evolve and different copies would not be the same after a short while of playing. An export/import facility was being designed to move things to/from various instantiations of the game. My design is over 10 years old, ideas based on TSR's D&D, the original Adventure from Stanford and the original Zork from MIT. It was never implemented, although parts of it were written. It required a lisp-like language so capabilities for objects and players could be kept. Of course it didn't have a Graphical User Interface, since multi-access timesharing systems didn't have those things in ready supply back then. Even today, there are very few applications with a shared GUI (don't flame me, I know there are some :-). I still have a fondness for these ideas in a game, single user or multi-user and have not been too impressed by many of the slasher games coming out of the game industry today, since I can't be the only one that has some of these ideas, I'm still waiting for someone to incorporate these things into new games (or some of the old ones, i don't care which). I might... if I get around to developing games for the Mac. Or if someone is willing to collaborate using my ideas. -carl Carl A Baltrunas - Catalyst Art Cherie Marinelli - Bijoux {sumex, apple}!oliveb!tymix!atlas!udwarf!{carl or cherie} {carl or cherie}%udwarf@tardis.tymnet.com