Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!convex!swarren From: swarren@convex.com (Steve Warren) Newsgroups: comp.sys.amiga.tech Subject: Re: Architecting a remote dungeon Keywords: Dungeon Platform Message-ID: <102904@convex.convex.com> Date: 8 Jun 90 16:40:40 GMT References: <136840@sun.Eng.Sun.COM> Sender: news@convex.com Organization: Convex Computer Corporation; Richardson, TX Lines: 43 In article <136840@sun.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >Eventually, I will begin populating the dungeon with "intelligent" >(ie other users) beings and "dumb" monsters which are mostly >fixed strategy automatons. The plan is that one or more people >could share a copy of the dungeon database and explore it together. >Each machine that was participating could generate 0 or more monsters >that would be present in all replica's of the dungeons. [...] This is a great idea! One problem - this could conceivably kill off a poor innocent adventurer if some friends pop in, monsters in tow, then all pop out, leaving the poor guy to fight off the monsters they brought with them! Maybe the monsters should leave whenever a player leaves. > Protocol on the wire. Use DNet or a MIDI "net" ? How about parnet? That would give you more bandwidth if you needed it... > I feel we could probably use the Robotron type controls to move > around (ie two joysticks, one to move one to look) That works well. > Illumination, anyone got a good torch algorithim ? > >Other Ideas : > > Players that "exit" the current session turn to stone in the > dungeon until they return. > Might be fun to let people "teleport" out of the dungeon temporarilly, rather than turning to stone. If two people side-by-side quit together their stone bodies would block the hallway. I would like to be on your mailing list. -- _. --Steve ._||__ DISCLAIMER: All opinions are my own. v\ *| ---------------------------------------------- V {uunet,sun}!convex!swarren; swarren@convex.COM