How Quest Works
Quest uses a few strategies to make game and simulation development easier and more efficient. Quest takes advantage of current industry standards and proposed standards that make it easier to create tools that can edit game content as well as engines that can display many different games.
The Quest development philosophy has two major differences from current game development processes. First, Quest projects are built in such a way that reuse is both practical and easy. Second, all of the development tools are closely integrated,making it easy to keep everything up to date and synchronized and ensuring that you only need to create things in one place. Design documentation is closely tied to development, allowing you to create pieces in the design document that can become part of the game later, and allowing you to link completed game parts with the associated documents to stay on track, make sure everything you wanted to include gets included, and create a manual that is always up to date with the game.
Standards
Standards provide a structure and set of principles that can be used to describe many similar products or programs. Because standards have a well defined structure, it is possible to create a single viewer or browser or editor for many significantly different types of content. Supporting standards in game and simulation development is a step on the way to making the development process easier, more efficient , and cross-platform compatible.
Quest built projects are compliant to the following set of standards and proposed standards:
- High Level Architecture (HLA)
The United States Department of Defense standard for the development of distributed simulations. HLA handles the collaboration aspects for both authoring and play.
- Magnetar Extensible Scene Graph (XSG)
A proposed set of HLA compliant standards for organizing data into a hierarchical scene graph. Quest uses XSG to fully describe each game and simulation. The standard data organization encourages the separation of the description of game content from its presentation, allowing the same data to have different representations. To learn more about XSG, visit GameXML.org.
Layered Development
Quest projects are built in a layers, where each layer contains reusable pieces of the layers below it. This strategy maximizes the reuse you get from each piece of work you create. The Layered Development process breaks things down into small reusable component parts. You can find examples of reusable components in the repository.
The major development layers are:
- The ontology
- Atoms
- Patterns
- Prototypes
- Scenarios
The ontology is a dictionary of terms and their definitions, classified according to facets, or distinct aspects, of a game or simulation. The ontology is used throughout the project to help maintain consistent terminology from documents to code to digital assets. It allows team members to quickly check their understanding of any project terms, and see the relationships between project terms.
Atoms can be used to evaluate statements as true or false, cause events, move objects, or define attributes. They are reusable pieces of code created by programmers that can be linked together to make behaviour patterns. Atoms are the smallest pieces of code that form the building blocks for artificial intelligence, story creation, and interactions between characters.
An element that occurs frequently can be generalized as a patterns. There are two types of patterns used in Quest; these are behaviour patterns and object patterns. Behaviour patterns describe a general behaviour, such as, "when 'area' is entered 'dialog' starts", where the generic 'area' could be an area from any scenario, and 'dialog' could be any conversation. Behaviour patterns are organized into scripts of atoms that define how an object or non-player character (NPC) behaves. Object patterns describe those objects and NPCs. Complex object patterns are made up of simple object patterns; they form the major component of a prototype. Simple object patterns generically describe part of an object, that may be used in many objects.
Prototypes are representations of the objects in a project. A prototype describes all the features and attributes that each object can have, such as magic level for an RPG wizard or number of wheels on a EMT fire truck. It also associates the artistic representation of the object with the logical representation described by a complex pattern, and can have attached scripts that define its behaviours.
The scenario consists of a map as well as all the opening position and state of all the game objects. Scenarios can be though of as the beginning of a level or a new situation. Scenario specific rules can be added during scenario development. The Scenario is contains prototypes, with the plot and behaviours being created by atoms and patterns. It is the major piece, the part that can be played.
All of these pieces come together to create the final product, with many pieces being used in multiple places. Reuse occurs both within projects and from project to project.
Integrated Documentation
One of the major differences between Quest and traditional game development is the integration of the documentation with the rest of the development process. Unlike other game authoring systems, Quest allows changes that are made to the ontology, atoms, patterns, blueprints and scenarios to be reflected in the design document, help documents, or the manual as appropriate. It is possible to attach sections of the design document to there relevant implementations so that changes to one are reflected in the other, and the documents stay current.
Likewise, Changes made in the document can be reflected in the ontology, scenario, etc. Besides making it easy to track changes, having assets attached to the document makes it easier to tell what parts of the game or simulation still need to be developed. This method is a nice complement to workflow as a method of keeping every member of your team up-to-date.
The integrated documentation system helps you keep your documents up to date. This is especially helpful if you want new team members to join into the project late, or if you are pitching the game and want to use your Quest copy as a mock-up.