| VERION 2.5/3.0 (1995/08/17) | VERSION 4.1 (1995/09/27) |
| 3.01 Technical Definitions The Nemesis game engine [MADE] is an object oriented API. The basic object in the game is a screen frame, which can be thought of as the stage where the action takes place. Anything that can be seen or heard on the stage is an actor. Movies, sounds, music, animations and objects that can be manipulated are all actors:
|
3.01 Technical Definitions The Nemesis game engine [MADE] is an object oriented API. The basic object in the game is a screen frame, which can be thought of as the stage where the action takes place. Anything that can be seen or heard on the stage is an actor. Movies, sounds, music, animations and objects that can be manipulated are all actors:
|
| 3.02 Technical Specifications This section outlines software and hardware standards and protocols. It contains the quantitative assumptions we are making about target platforms and operating systems. It also contains the qualitative assumptions we are making about compression ratios and bandwidths. |
3.02 Technical Specifications This section outlines software and hardware standards and protocols. It contains the quantitative assumptions we are making about target platforms and operating systems. It also contains the qualitative assumptions we are making about compression ratios and bandwidths. |
3.03 Data Structures
|
3.03 Data Structures
|
| 3.04 Content Allocation
— TBD ZORK: NEMESIS is currently slated for two CD-ROMs. However, the use of 16 Bit art and large amounts of Red Book audio will require moving to three CD's. The breaks between CD's will be at Act Breaks so as to minimize CD swapping. |
3.04 Content Allocation
— TBD ZORK: NEMESIS is currently slated for three CD-ROMs. The breaks between CD's will be at Act Breaks so as to minimize CD swapping. |
| 3.05 Minimum System Requirements Nemesis is targeted initially at Power Macintosh and MPC2 CD ROM but is designed for portability to the major CD based systems that have been released or announced to date: Sega Saturn, 3DO, Sony PSX, Atari Jaguar and Apple Pippin. MPC2 system 486 66MHz Microsoft Windows95 8MB RAM CD ROM w/ 300kB/sec transfer rate [Double Speed] 8MB free HD SoundBlaster 16 bit compatible card SVGA graphics adapter accelerated local bus 16 bit |
3.05 Minimum System Requirements Nemesis is targeted initially at Power Macintosh and MPC2 CD ROM but is designed for portability to the major CD based systems that have been released or announced to date: Sega Saturn, 3DO, Sony PSX, Atari Jaguar and Apple Pippin. MPC2 system 486 66Mhz DX4 Microsoft Windows95 8MB RAM CD ROM w/ 300kB/sec transfer rate [Double Speed] 8MB free HD (min. install) SoundBlaster 16 bit compatible card SVGA graphics adapter accelerated local bus 16 bit Qsound |
| 3.06 Power Macintosh system RISC Power PC 601 60MHz (6100 level) System 7.5 8MB RAM CD ROM w/ 300kB/sec transfer rate [Double Speed] 8MB free HD Foreign File Access extension ISO 9660 file access extension QuickTime 2.0 extension QuickTime Musical Instruments 2.0 extension |
3.06 Power Macintosh system RISC Power PC 601 60MHz [6100 level] System 7.5 8MB RAM CD ROM w/ 300kB/sec transfer rate [Double Speed] 8MB free HD (min. install) Foreign File Access extension ISO 9660 file access extension QuickTime 2.0 extension QuickTime Musical Instruments 2.0 extension |
| 3.07 Design Language The game's design language is a terminology set intended to match our understanding of what the game looks like and how it works. The design is primarily object oriented. Adopting this language allows us to construct a logical model of player/game interactions. |
|
| 3.08 Frames Frames are the most basic element of content displayed. Each frame has a ID number and name. The number is a four digit numeric. The name is an alphanumeric string <31 characters in length. The naming convention is [cell alphanumeric framenumber frametype]. There are three types of frames:
|
|
| 3.09 Image Frames [image_frame] Image frames are 640 X 400 pixels at 8 bit color depth. The entire frame is active to mouse clicks. The letterbox frame outside the frame is set to black when the game is launched to add to the cinematic experience. |
|
| 3.10 QuickTime Video Frames QuickTime video frames are any size, but never larger than 320 X 240 pixels at 8 bit. The entire QuickTime video frame is active to mouse clicks. There are three types of QuickTime video frames:
Movies are time-based images in the QuickTime format. QuickTime video frames are reserved for the game introduction sequence, flying logos, portal transfers, the making of Nemesis video, and endgame sequences. 3.10.02 VR Transitions [vr_transition frame] VR Transitions are sequence-based images in the QuickTime format. MouseDown input in combination with cursor screen location (up, down, left, right) advances or retreats through the image sequences. The effect is as if the player is walking or turning in the game space. MouseUp input stops the image advance/retreat. 3.10.03 VR Objects [vr_actor_frame] VR objects are sequence-based images in the QuickTime format. MouseDown input in combination with cursor screen location (up, down or left, right) advances or retreats through the image rotation sequences. The effect is as if the player is rotating the object in the game space. MouseUp input stops the image rotation. |
|
| 3.11 Animation Frames
[animation_frame] Animation frames are any size, but never larger than 640 X 360 pixels at 8b. The entire frame is active to mouse clicks. |
|
| 3.12 Actors Actors are time or sequence-based objects that are in a frame (except text actors). Estimates of actor sizes are all based on 10 second durations or 30 step sequences. There are five frame actors: 2.1 animation actor [animation_actor] 2.2 audio actor [audio_actor] 2.3 MIDI actor [midi_actor] 2.4 VR actor [vr_actor] 2.5 QuickTime actor [qt_actor] 2.6 Text which will need translating for foreign languages [text_actor] 3.13.01 Animation Actors [animation_actor] Animation Actors are image sequences that provide interactive movement to an object in a frame (opening a drawer for example). Animation actors can be as large as 640 X 360 8b , but in most cases are 160 X 100 8b, or smaller. Animation actors are ~3MB (150kB image @ 8 cels). 3.13.02 Audio Actors [audio_actor] Audio Actors are Audio Interchange Files (AIFF) that are interactively played back. Audio actors are 16b @ 44.1 kHz samples compressed @ 3:1. Audio actors are ~300kB. 3.13.03 MIDI Actors [midi_actor] MIDI Actors are general MIDI files that are interactively played back. MIDI files will generally be multibuffered music played back and looped when a frame is opened. MIDI actors are ~150kB. 3.13.04 VR Object Actors [vr_actor] VR Object Actors are sequence-based images in the QuickTime format that are interactively rotated. VR actors can be as large as 640 X 360 8b, but in most cases are 320 X 200 8b, or smaller. VR actors are -4MB (150KB image @ 30 cels). 3.13.05 QuickTime Actors [qt_actor] and [video_actor] QuickTime Actors are time-based images in the QuickTime format that are interactively played back and/or looped . QT Actors can be as large as 640 X 360 8b, but in most cases are 320 X 200 8b, or smaller. QuickTime Actors are -3MB (150kB image @ 15 fps). Some QuickTime Actors will be live action sequence, while others are animations bundled into QuickTime Actors because of complexity. QuickTime Actors which involve live action footage are labeled [video_actor] to differentiate the two types. 3.13.06 Text Actors [text_actor] Text Actors are pieces of text which provide important content and are required to understand the game. These are noted so as to facilitate less confusion during foreign translations. |
3.12 Actors Actors are time or sequence-based objects that are in a frame (except text actors). Estimates of actor sizes are all based on 10 second durations or 30 step sequences. There are five frame actors: 2.1 animation actor [animation_actor] 2.2 audio actor [audio_actor] 2.3 MIDI actor [midi_actor] 2.4 VR actor [vr_actor] 2.5 QuickTime actor [qt_actor] 2.6 Text which will need translating for foreign languages [text_actor] 3.13.01 Animation Actors [animation_actor] Animation Actors are image sequences that provide interactive movement to an object in a frame (opening a drawer for example). Animation actors can be as large as 640 X 360 8b , but in most cases are 160 X 100 8b, or smaller. Animation actors are ~3MB (150kB image @ 8 cels). 3.13.02 Audio Actors [audio_actor] Audio Actors are Audio Interchange Files (AIFF) that are interactively played back. Audio actors are 16b @ 44.1 kHz samples compressed @ 3:1. Audio actors are ~300kB. 3.13.03 MIDI Actors [midi_actor] MIDI Actors are general MIDI files that are interactively played back. MIDI files will generally be multibuffered music played back and looped when a frame is opened. MIDI actors are ~150kB. 3.13.05 QuickTime Actors [qt_actor] and [video actor] QuickTime Actors are time-based images in the QuickTime format that are interactively played back and/or looped . QT Actors can be as large as 640 X 360 8b, but in most cases are 320 X 200 8b, or smaller. QuickTime Actors are -3MB (150kB image @ 15 fps). Some QuickTime Actors will be live action sequence, while others are animations bundled into QuickTime Actors because of complexity. QuickTime Actors which involve live action footage are labeled [video_actor] to differentiate the two types. 3.13.06 Text Actors [text_actor] Text Actors are pieces of text which provide important content and are required to understand the game. These are noted so as to facilitate less confusion during foreign translations. |
| 3.14 Multibuffering Actors Multibuffering Actors is the simultaneous, synched or un-synched, playback and/or looping of multiple actors. These actors can be multibuffered in the combinations outlined:
|
3.14 Multibuffering Actors Multibuffering Actors is the simultaneous, synched or un-synched, playback and/or looping of multiple actors. These actors can be multibuffered in the combinations outlined:
|
| 3.15 The Cell Cells are the most basic transition elements. Cells are made up of n frames. Each cell has an ID alphanumeric. The ID is an alphanumeric string <n characters. The naming convention is [location cellnumber celltype]. The number of frames determines the cell type. There are four cell types:
[image has not been reproduced here] 3.15.01 2frame cells contain two frames — facing and rear. 2frame cells are -440KB. The design symbol for a 2frame cell is: [image has not been reproduced here] 3.15.02 4frame cells contain four frames — facing, left, right, and rear. 4frame cells are -880KB. The design symbol for a 4frame cell is: [image has not been reproduced here] 3.15.03 6frame cells contain six frames — facing, left, right, rear left, rear right, and rear. 4frame cells are -1.36MB. The design symbol for a 6frame cell is: [image has not been reproduced here] 3.15.04 VRframe cells contain 60 frames facing and rear. VRframe cells are -8MB. The design symbol for a VRframe cell is: [image has not been reproduced here] |
|
| 3.16 Further Definition of Frames
and Actors Frames and actors further define cells by specifying their type, orientation, and duration. This is an example of a cell's complete notation:
|
|
| 3.17 Memory Allocation Memory allocation is calculated for each cell by the sum of the cell type, the frame type, and the actors and their duration (for the purpose of calculating total content, 10 seconds each is assumed unless otherwise noted): memory (cell type + frame type + frame actors) |
|
| 3.18 The Background The Background is an invisible layer that exists behind all frames. The background contains fields that hold and pass values and/or objects to any given frame. |
|
| 3.19 Fields Fields are invisible containers that hold and pass values and/or objects from one frame to another or from a frame to the background. The game state [game_state] is an example of a value passed from a frame to the background. |
|
| 3.20 The Cursor The Cursor is a visible container. It can hold and pass values and objects to frames and frame actors. Rotating a VR object is an example of passing a value to a frame actor from the cursor (X,Y screen location). Lighting a candle animation actor with a match cursor is an example of passing an object. The Cursor functions as a screen guide for the player. Moving the Cursor to the edge of the screen will indicate if a direction of travel is possible. When a Cursor passes over an object which may be seen in detail or handled in some way, the Cursor will indicate this but changing slightly. When the mouse button is pressed, the Cursor will also change slightly to indicate this interaction. |
3.20 The Cursor The Cursor is a visible container. It can hold and pass values and objects to frames and frame actors. Rotating a VR object is an example of passing a value to a frame actor from the cursor (X,Y screen location). Lighting a candle animation actor with a match cursor is an example of passing an object. The Cursor functions as a screen guide for the player. Moving the Cursor to the edge of the screen will indicate if a direction of travel is possible. When a Cursor passes over an object which may be seen in detail or handled in some way, the Cursor will indicate this but changing slightly. When the mouse button is pressed, the Cursor will also change slightly to indicate this interaction. |
| 3.21 Movie/Animation Playback Movies and animations playback when the player's actions or game state indicates that the program should initiate a sequence. Most hard core gamers find these playbacks laborious on second viewing; they also slow down game play. The player may stop playback of most sequences in the game by entering the cancel key combination. Under Windows, the combination is CTRL-C. On the Macintosh, the keys are X-. (Command period). Clicking, common on some adventure games, will not stop playback on either machine so as to avoid accidentally stopping a movie. For the consoles (which do not have keyboards), a multi-button sequence will be used (TBD). |
3.21 Movie/Animation Playback Movies and animations playback when the player's actions or game state indicates that the program should initiate a sequence. Most hard core gamers find these playbacks laborious on second viewing; they also slow down game play. The player may stop playback of most sequences in the game -by entering the cancel key combination. Under Windows, the combination is CTRL-C. On the Macintosh, the keys are X-. (Command period). Clicking, common on some adventure games, will not stop playback on either machine so as to avoid accidentally stopping a movie. For the consoles (which do not have keyboards), a multi-button sequence will be used (TBD). |
| 3.22 Object Manipulation ZORK: NEMESIS has a limited object list necessary for completing some of its puzzles. The idea of a complex inventory has been eliminated to veer away from the tendency of game players trying every conceivable combination of objects in an ever frustrating and increasingly complex cycle. Players may only carry one object at a time. Once an object is used, it is either fused to the mechanism where used or destroyed; in other words, no object is needed to solve multiple puzzles. Typically, if an object is used on the wrong puzzle, no interaction occurs (a few exceptions exist as specified later in this document). All object locations will be tracked, and all objects will remain in their locations, even when their land is left. Object locations are also stored in save games. |
3.22 Object Manipulation ZORK: NEMESIS has a limited object list necessary for completing some of its puzzles. The idea of a complex inventory has been eliminated to veer away from the tendency of game players trying every conceivable combination of objects in an ever frustrating and increasingly complex cycle. Players may only carry one object at a time. Once an object is used, it is either fused to the mechanism where used or destroyed; in other words, no object is needed to solve multiple puzzles. Typically, if an object is used on the wrong puzzle, no interaction occurs (a few exceptions exist as specified later in this document). All object locations will be tracked, and all objects will remain in their locations, even when their land is left. Object locations are also stored in save games. |
| 3.22.01 Multiple Objects If a player clicks on an object which may be carried while holding another object, the new object becomes the cursor and the old one is dropped. If an object is only a temporary cursor object (like the electrode prods in the Aslum Examaination Room or sand bags in the Conservatory Stage), the previous object remains the cursor at the end of the interaction with the temporary item. So, in Kaine's Castle, if the player is carrying the sword [cursor_object], and reads the battle plans (a detail object only), the sword is still the [cursor object] at the end of viewing the plans; it is not dropped at this point. |
3.22.01 Multiple Objects If a player clicks on an object which may be carried while holding another object, the new object becomes the cursor and the old one is dropped. If an object is only a temporary cursor object (like the electrode prods in the Asylum Examination Room or sand bags in the Conservatory Stage), the previous object remains the cursor at the end of the interaction with the temporary item. So, in Kaine's Castle, if the player is carrying the sword [cursor_object], and reads the battle plans (a detail object only), the sword is still the [cursor object]at the end of viewing the plans; it is not dropped at this point. |