cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/08/90)
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: <none> 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!"jesup@cbmvax.commodore.com (Randell Jesup) (06/08/90)
In article <136840@sun.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >Open Issues : > I don't know what resolution the display should run at (probably > 320 X 200 with lots of colors) Probably > 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, ...); This sounds like a good use for gels (since they also preserve background, etc). Otherwise you need to redraw the background, or use BMBMRP, which causes horrible flashing, or use the blitter directly. > Protocol on the wire. Use DNet or a MIDI "net" ? Or SANA. Go to Dale's talk at Devcon, if you're going to be there. (SANA = Standard Amiga Network Architecture, which the Amiga Network working group run by Dale has standardized on.) Of course, this assumes Matt or someone feels like making DNet (or whatever) SANA compatible. It has the advantage that this could run over local ethernet, TSSNet, arcnet, local parallel hookup (with wrapper), whatever. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
guineau@wjg.enet.dec.com (06/08/90)
In article <12411@cbmvax.commodore.com>, jesup@cbmvax (Randell Jesup) writes: > > Protocol on the wire. Use DNet or a MIDI "net" ? > > Or SANA. Go to Dale's talk at Devcon, if you're going to be > there. (SANA = Standard Amiga Network Architecture, which the Amiga > Network working group run by Dale has standardized on.) Of course, this > assumes Matt or someone feels like making DNet (or whatever) SANA > compatible. It has the advantage that this could run over local ethernet, > TSSNet, arcnet, local parallel hookup (with wrapper), whatever. Is there documentation on SANA available? --- W. John Guineau guineau@wjg.enet.dec.com Digital Equipment Corporation Marlboro MA. 01752
swarren@convex.com (Steve Warren) (06/08/90)
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
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/09/90)
In article <12411@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > ... Go to Dale's talk at Devcon, if you're going to be >there. (SANA = Standard Amiga Network Architecture, which the Amiga >Network working group run by Dale has standardized on.) ... [I won't be at DevCON :-( but I will be a dad :-). ] I'm a little bit confused about this. Since Commodore is using SVR4 for the base of it's AMIX product, why not use the TLI interface which is standard in SVR4 to help developers maintain applications that work both under AmigaDOS and UNIX ? -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> 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!"
dale@cbmvax.commodore.com (Dale Luck - Amiga) (06/09/90)
In article <136932@sun.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >In article <12411@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >> ... Go to Dale's talk at Devcon, if you're going to be >>there. (SANA = Standard Amiga Network Architecture, which the Amiga >>Network working group run by Dale has standardized on.) ... > >I'm a little bit confused about this. Since Commodore is using SVR4 >for the base of it's AMIX product, why not use the TLI interface >which is standard in SVR4 to help developers maintain applications >that work both under AmigaDOS and UNIX ? > The TLI stuff is only a shell over one of the SANA layers. It is just similar to BSD sockets or whatever libraries are used to write Mac network applications or DEC VMS applications. The stuff that sits underneath the interface library is based on exec devices and ioreqs. This will mean than tli based programs as well as bsd socket applications can coexist in the same box since the underlieing interface is common and reentrant, just like all good devices. I am looking for a volunteer to develop a TLI library along with the socket library I already have to see if we are missing some critical functions that are necessary to support TLI properly. Having a TLI based application you want to port to the Amiga is probably a good start. Dale Luck Commodore-Amiga, Inc.
dillon@overload.UUCP (Matthew Dillon) (06/11/90)
>> Protocol on the wire. Use DNet or a MIDI "net" ? > > Or SANA. Go to Dale's talk at Devcon, if you're going to be >there. (SANA = Standard Amiga Network Architecture, which the Amiga >Network working group run by Dale has standardized on.) Of course, this >assumes Matt or someone feels like making DNet (or whatever) SANA >compatible. It has the advantage that this could run over local ethernet, >TSSNet, arcnet, local parallel hookup (with wrapper), whatever. I've got the disk, but whether I can find the time or not .... its up in the air (Re: DNet) -Matt -- Matthew Dillon uunet.uu.net!overload!dillon 891 Regal Rd. Berkeley, Ca. 94708 USA
new@udel.EDU (Darren New) (06/11/90)
In article <102904@convex.convex.com> swarren@convex.com (Steve Warren) writes: >Might be fun to let people "teleport" out of the dungeon temporarilly, >rather than turning to stone. A friend of mine designed something like this a while ago. The players would turn to stone, but if they (say) left their packs open, or held a wand in their hands, other player could come along and steal stuff. Also, the sysop played as a large silver dragon which was usually a statue but could occasionally seen walking down a cross-corridor carrying a stoned player in its mouth >:-> If you could be robbed while you were stone, I would think most people would go and hide in a concealed place while not playing or use some sort of intangability spell (which was easy to obtain in my friend's dungeon, since it worked both ways). >I would like to be on your mailing list. Me too! -- Darren
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/12/90)
I wrote : > Players that "exit" the current session turn to stone in the > dungeon until they return. > In article <102904@convex.convex.com> swarren@convex.com (Steve Warren) writes: > 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. Au contrair. There is nothing preventing another player from picking up a 'stoned' player and moving him/her. In fact, if you had sufficient strength you should be able to wield the other player like a stone club. This of course has interesting ramifications when the player "returns". Another use for statues is that if you and a buddy are carrying one apiece you could set them up to block the hallway and protect your "rear" while you fight a forward action. Throwing one would probably pretty effective too but given their "weight" you might not send it very far. >I would like to be on your mailing list. That you are ... -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> 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!"