sdn19212@uxa.cso.uiuc.edu (Shehzad Danial Najmi) (03/07/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.