AGDS Overview
| stub page. You can help the Sierra Wiki by expanding it. |
Introduction
The Adventure Game Development System (AGDS) was the development environment Sierra used to create AGI games.
From the Internal AGDS Documention: [1]
Overview
AGDS was developed as a fast means to implement adventure games using a machine portable language. It outwardly resembles the programming language "C".
AGDS is a specialized set of commands which help manipulate objects on a 3-D plane. Before looking at the commands, it is important to understand some basic terminology.
ROOM
we divide our games into "rooms"--locations based upon a map. For instance, if a game is inside a house, room 1 might be the living room, room#2 the kitchen, etc. When the adventure moves outdoors, room #11 might be the left side of a lake and room #12, the right side. The amount of landscape in a room is controlled by the graphics of the room's picture.
PICTURE
Usually, each ROOM has an associated picture. In some cases a room has multiple pictures. In King's Quest 2, Dracula's castle had numerous rooms with two pictures; one with the room lit, and another mainly black picture (indicating the lights were out). Donald uses three pictures within the banner page room, a logo picture, a title picture and the credits screen.
OBJECT
OBJECTs may be either ANIMATED OBJECTS or INVENTORY OBJECTS, the difference being whether they appear graphically on screen or exist only to be carried. Example: in Quest2 there were two objects, the mallet and the bracelet. King Graham sees a tree in the woods that contains a mallet. He can say "GET MALLET" and the mallet goes into his inventory. With the mallet in inventory, he can say "SHOW MALLET" and a window opens, displaying the mallet. The bracelet is seen lying on the beach. When he says "GET BRACELET" it disappears off the screen. Once in inventory, it can be "look"ed at just like the mallet. Because the bracelet appears on screen during the game, it is an "animated object." Since the mallet exists only to be taken into inventory, it is called an "inventory object." "Animated" objects can be "DRAWN" on the screen and animated. "Inventory" OBJECTs can only be held in inventory. Both may be "SHOWn" in a pop-up screen window, once they are in inventory.
CELLS
AGDS works like traditional cartoon animation. If Little Red Riding Hood is seen stooping to pick flowers, she must be drawn as a series of CELLS showing her going from standing up to bending over. At NORMAL speed, AGDS cells are cycled at the rate of 9 per second. If Riding Hood is 20 pixels by 20 pixels, each CELL uses about 200 bytes of memory. Obviously, all CELLS to be displayed must be in memory when the animation begins. A collection of CELLS that form an animation sequence is called a LOOP. Each cell contains the specific bit-maps AGDS displays on-screen. LOOPS -- Each loop contains from 1 to 10 CELLS. Little Red Riding Hood picking a flower is a LOOP, Red skipping is another LOOP, Red walking without skipping is yet another.
VIEWS
Views consist of from 1 to 4 LOOPS. An animated object may have a view consisting of 4 LOOPS: right, left, front, and back. You can only load VIEWS, not just a LOOP. Often, memory constraints will force a character to have only 2 loops, a right and a left. AGDS determines which LOOP is displayed, based on the direction of an object. Only the four directions [r, l, f, b] are supported.
LOGICS
Each room has LOGIC associated with it. This LOGIC is the procedural set of instructions that gets executed describing game play. AGDS always automatically loads, and executes ROOM #0. From there, the logic programmer must handle everything.
ROOM #0 contains the LOGICS that are common to the entire game, low level functions like "SAVE GAME," "HELP", etc. Instead of coding instructions to handle saving the game into every room, put it in room 0.
DYNAMIC LOGICS are used for the same reason. They are rooms that have no picture, but process commands that occur in multiple ROOMs. Every ROOM that needs swimming can load a LGC.SWIM which deals with commands like SWIM, and standing ego up when he is no longer in water. It would be a nuisance and a waste of disk space to code this redundantly for each ROOM with water in it. If it were in ROOM #0 it would occupy ram even in ROOMs without water. Memory is valuable; anything that cuts down memory requirements is good!
LAST LOGICS are simply the last LOGICS executed. Here you handle things like the player giving a command that the other logics don't recognize. For instance, if the player asks the game to swim when there is no water in a ROOM, no dynamic logic is loaded to deal with water. Somehow the player needs to be told we don't understand what he said. LAST LOGICs handles all code trying to provide intelligent responses to input not dealt with by one of the earlier-processed logics.
SOUNDS
Sound effects and music work just like PICTURES and OBJECTS, load them, then call them.
