sdn19212@uxa.cso.uiuc.edu (Shehzad Danial Najmi) (03/06/91)
OFFICIAL ANNOUNCEMENT: DIGITAL DUNGEON by MAGIC MATRIX
System: Amiga 500,1000,2000,2500 with single drive, 512K and joystick.
Hello all. My original request for input on the comp.sys.amiga.announce board
rendered a number of interesting and useful replies. Based on that information
and further thought, I am releasing for your inspection, in a number of
different places, a revised statement of intentions. It is my desire to make
this product as truly representative of the needs of the people that I talk to
as possible. Here, then, is the Digital Dungeon as of 3/6/91:
The primary function of the Digital Dungeon (hereafter DD) is to accurately
and efficiently display the graphical particulars of a combat scene in a
gaming environment. It could be seen as a sophisticated replacement for
a lead-figure outfit or paper map setup. The advantages of such an interface
between computer and game span all of the common complaints regarding the
simplicity of lead-figures and the messiness of paper maps and chalkboards.
The following is a list of features I tentatively plan to incorporate in the
final product. I plan to continue revising this based on my Internet
interactions, so keep the ideas flowing. Regularly I will announce the updated
statement of intentions, until a fairly late point in the development cycle.
But here we are for now:
1. Graphical Player-Character Editor: A powerful but intuitive tool which
allows for the customizing of animated player-chracter graphics. This
will by no means involve a pixel-by-pixel construction of the graphic.
Rather, the player or referee will be able to choose from a large array
of heads, armors, packs, cloaks, weapons, lighting sources and so forth.
The Editor will be very flexible: There will be no restrictions as to
what goes where on a player-character. All X frames of the animation
for each character will be customizable, so one might even render the
thief with a left-to-right swagger, etc. The character representations
will be birds-eye-view, or, in other words, seen from the top. The will
also be provision for a "dead" version of each character, so that the
position of any character killed in combat will be apparent to the rest
of the party. Note: The editor will require only one "rotation" for
a character to be established. The program will generate the other seven
top-view rotations in real-time. Additionally, the program will generate
unique shadows for each character, in all eight rotations, and 3 lengths,
representing different distances from light sources.
2. Scene Editor: The referee will have a sophisticated setup at his disposal
for generating combat scenes. The DD program will deal with the adventure
on a scene-by-scene basis, and for each scene, the ref will be able to
perform the following:
1. Load standard IFF backrounds from Dpaint and other programs. The
backrounds will all be birds-eye-view, done in 64-color Extra Half-Brite
mode. There will be a standard color palette, with a reasonable
selection of grey-scales and a fair representation of the other colors.
2. Arrange events. Events are sequences of operations performed in
response to the function keys. Obviously ten events will be available
per scene, but each event could entail a number of actions. Some
examples of what might be included in an event follow:
1. Load a backround scene. This event will be mandatory.
2. Position the characters in marching order. This will provide a
template for whatever characters are along for the adventure. This
way it need not be known ahead of time who will play. Whatever
characters are selected at the beginning of the adventure will be
loaded one by one into the template and positioned on screen.
3. Set the light level for the screen.
4. Introduce monsters.
5. Start and stop animations, such as fountains, torches, etc.
6. Halt for the manual positioning of characters and monsters.
7. Perform "spot" animations, such as opening a door, etc.
3. Compile scenes. After all of the events were arranged for a particular
scene, the program could optionally save them in one place, so that
their later retrieval is as quick as possible. In other words, the
backround graphic, the monsters, the animations, and the script for
the scene would all be saved under one file name, so that the whole
scene could be loaded in with a menu selection.
4. Output script. The maps for the function keys in each scene and the
monster and animation lists can be dumped to a printer, so that a
fast reference is there during gameplay. The referee need only look
at his printout to know, for example, that F5 will load in the 3 rats at
their various locations, and simultaneously open the door to the
next room (since the mother rat is about to make her appearance).
5. Position characters on horses, in boats, etc.
3. Real-time Functions: There are a number of functions at the referee's
disposal once the gaming session has actually begun. Besides being able
to perform any of the pre-prepared actions by use of the function keys,
there are the following options:
1. Assign movement to a player. Essentially this passes control of an
animated player-character to one of the players by means of the
joystick. The player may then move his character on screen to a new
postion or merely hit the fire button to pass control back to the ref.
A joystick extension might be a good investment. (Radio Shack)
2. Move a monster. Once a monster has been called in with a function key,
it will be possible to move it with the mouse when selected.
3. Meter movement. The ref will have the option to start a meter at the
top of the screen in order to keep track of character and monster
movement. The unit will probably be feet. This will end all arguments
as to whether a character could logically move around the pit and
still attack on the same round.
4. Determine scope and range of spells and distance effects. The ref may
call up either:
1. A ruler. For crossbow ranges, etc.
2. A cone-shaped graphic. Will size itself on command and present
its dimensions, so that the scope of a fireball or flame-thrower
would be readily apparent.
3. A circular graphic. Will size itself and present its dimensions, so
that the effects of a grenade would be visible, for example.
5. Call up a grid. In some cases, it would be difficult for a player
or even for the ref to figure out the relative distances between things,
though this would probably get very easy over time. However, a grid
of five or ten feet could be called up to superimpose itself on the
backround.
6. Generate character marching order. When the characters are loaded up
at the start of an adventure, they may be put into a template used in
the scene generator, so that the ref need not position the characters
on screen for every new screen.
7. Load a character. Gets a character from the special party file and
adds it to the screen. Allows for those pesky late players. One can
then redo the marching order template to include the new character.
8. Load a party.
9. Set light levels. Light may be controlled in a fairly sophisticated
fashion. Each torch present adds 1/4 to the total light level, which
is nominally 0 for inside scenes. Each lantern adds 3/8, each light
spell or big flashlight adds 1/2, etc. To further increase the
realism of the production, the shadows change for each of the
character graphics as either they or the source of a light moves.
Additionally, for outdoor scenes, the "sun" may be controlled by the
referee. It may be set either with the scene editor, or actively
controlled by the ref. This simply raises the overall light level to
the satisfaction of "cloudy" or "sunny", 1/2 in the former, 1 in the
latter case. The shadows are then calculated based on the time of
day, "morning", "mid-morning", "late morning", "afternoon" (no shadow),
etc. As a last note about shadows, each character may have more than
one active shadow at a time, reflecting the presence of more than one
light source.
10.Extemporaneous mode. There will be times when the referee simply
will not have the chance to design the scenes before-hand. This
feature allows for circular and rectangular floor patterns to be
called up, the manual placement of trees, walls, etc, and the manual
importation of monsters (possibly with random characteristics: see
item 1. below.).
The following are things that have been suggested for inclusion. I need to
hear more about them from you to decide.
1. Character and monster information. This begins to get a little intrusive,
but we might make the use of the information functions optional.
1. Info window. A real-time function, the ref can call up the information
about any character or monster and change it. Consider hit points,
power, bullets, armor rating, etc. This would be accomplished simply
by clicking on the character and hitting a key, or something similar.
2. Information definition. The ref can call this window in the creation
phase to set initial values for monsters and characters. These will be
saved for the monsters when the scenes are compiled. The characters
info will stay with them from adventure to adventure.
3. Information templates. The information definition function could be set
to automatically ask for the categories of information particular to a
game. For example, Villains and Vigilantes would allow for categories
like power, hit points, missiles, etc.
2. Changeable weapons. The characters and monsters would be allowed to
change weapons in real-time. Needless to say, this presents serious
programming difficulties, but I would be willing to give it a shot if
there was enough demand.
3. Customized monsters. Again, this would be difficult to implement.
Notes:
1. There will be a very large amount of artwork bundled with the system,
including backrounds, premade characters, premade monsters, premade
animations (fountains, fires, etc.), premade spot animations (doors, pits,
etc.), and so forth. I am a competent, if uninspired artist, but my
brother is very good, technically speaking, and he has pledged his support.
It should all look very good. We plan to have a lot of art that may be
used in the referee's customized backround screens. One would only need
an IFF paint program.
2. I hate to say how much I would charge for all this. I want to give
something back to both the Amiga community and the gaming world. I can
tell you that it will be under $50, and very probably $30. This
would include at least three disks and the documentation, shipped within
a week. I will also arrange for international orders.
3. There will probably be no particular orientation for the program towards
a particular gaming system or time era.
4. I am going to look into developing some of the established "paper"
modules in the big gaming systems for the DD. This would mean that you
could order the completely done up versions of some of the more popular
modules, with the artwork, animations, scenes and monsters already
scripted and compiled.
All right, keep the comments coming. I want to look back at the end of the
summer and say that this was OUR baby! Thanks, Shehzad Najmi for Magic Matrix.gblock@csd4.csd.uwm.edu (Gregory R Block) (03/06/91)
From article <1991Mar6.055847.11970@ux1.cso.uiuc.edu>, by sdn19212@uxa.cso.uiuc.edu (Shehzad Danial Najmi):
> OFFICIAL ANNOUNCEMENT: DIGITAL DUNGEON by MAGIC MATRIX
I'd buy it in a minute. I've always dreamed of having something like this.
Do you have any idea when it could be done? I'd like it yesterday :), but
I know that isn't quite possible. I could really use something like this,
more than you could possibly know. I think metal figures are nice, but that's
all they are- nice. I would much rather have a computer. And a joystick
extender is a nice idea. How will it handle combat? I understand that you
could not exactly work combat into it, because then it would be game-specific,
and that could be a pain if you're not working in a certain game. This could
be nice... How about staircases? How would those be handled? Would you just
load up a different background?
Next question. Is this going to be a super-bitmap kind of thing? Or will it
be a top-down view-the-whole-map kind of thing... Super-bitmap scrolling would
be most awesome... but I imagine it could be slightly limiting. Also, how
big will each cell on screen be? I am thinking maybe 1/2" to 1". But I
could be wrong, you know... And thank you for using EHB. I only wish more
programmers would.
Greg
--
gblock@csd4.csd.uwm.edu | Amigas, Amigas everywhere, but not a one can think.
----Gregory R Block---- | Where's an AI when you need one?
________________________| A Mac, by any other name, would smell like a lawsuit
Roses are red, Violets are blue: Go buy a Mac, and you'll be screwed too...