Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sun!stpeter.Eng.Sun.COM!cmcmanis From: cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga.tech Subject: Architecting a remote dungeon Keywords: Dungeon Platform Message-ID: <136840@sun.Eng.Sun.COM> Date: 7 Jun 90 19:43:52 GMT Sender: news@sun.Eng.Sun.COM Lines: 92 Off and on I am in the process of architecting a program that will generate 32 X 32 X 32 dungeons. (Dungeon's don't have windows) The overall goal of the program is to generate 32 interesting levels, each with a "maze" which has at least one start point and one end point which ends in a stairway to the next level. The resulting dungeon should be readily compressable to something on the order of 64K to 128K bytes. 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. Overall dungeon construction is fairly well understood. Walls are composed of "bricks" which are 2 units wide, 1 unit high, i unit thick. People have the same approximate dimensions but are vertical. Hallways are 2 units wide by 2 units high. (two person objects could stand abreast in a hallway.) Each "space" is 2 X 2 X 2. Ideally "person" objects would consist of 4 views each of 2 subgroups. Subgroup A is the "body" subgroup and it has a front, left, right, back view, and subgroup B is a "head" subgroup and it too has a left right front back view. Position information of a person consists of a structure as follows : { u_char DX, DY; /* Dungeon "square" */ u_char spos; /* Position in square , 9 possible*/ u_char bvec, /* body vector (pointing direction */ u_char hvec; /* head vector. */ u_char wvec; /* Weapon vector */ u_short pid; /* Person ID */ } 8 bytes / person allow an update rate of people to be 10/second at 1200 baud. The idea being that someone could use something like Dpaint III to design a brush or Animbrush to represent them that would be cross loaded when they "entered" the dungeon, then other people "in" the dungeon would see this image. Open Issues : I don't know what resolution the display should run at (probably 320 X 200 with lots of colors) Should prescaled (and possible antialiased) views be generated of people so that the display algorithim can use something like hbitmap = People[pid]->Views.head[hvec][distance]; bbitmap = People[pid]->Views.body[bvec][distance]; BBMRP(rp, hbitmap, ...); BBMRP(rp, bbitmap, ...); Given a "view" on a lores screen of about 32 X 64 for the body and 32 X 32 for the head at "point blank" range. That would only be 2460 bytes/person/distance. Or about 12K/person for precomputed image data. (max distance 5 which is from the back of one square to the back of an adjacent square.) Of course people/monsters not on the current level could be swapped to non-chip ram. Protocol on the wire. Use DNet or a MIDI "net" ? I feel we could probably use the Robotron type controls to move around (ie two joysticks, one to move one to look) Illumination, anyone got a good torch algorithim ? Other Ideas : Players that "exit" the current session turn to stone in the dungeon until they return. Plans : The first goal is to get a dungeon generator built that will create a dungeon and allow someone to "fly" through it ( basically view it from any angle). At the same time some sort of storage format for the dungeon will need to be defined. (a new IFF FORM ? :-)) Anyway, if anyone is interested in contributing either formally or informally to the project let me know and I'll set up a mailing list. It tends to run in spurts so don't expect miracles. :-) -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"