🚀 go-pugleaf

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!"