Overview of the toolset

From Dragon Age Toolset Wiki
Revision as of 01:24, 26 January 2010 by Eshme (Talk | contribs) (Remove nosaying builder to player info.)

Jump to: navigation, search

The Dragon Age toolset is, with just a few omissions and changes, the same set of tools that was used internally at BioWare to develop the main Dragon Age: Origins campaign. It's a very powerful toolset, and therefore very complicated in many ways. This page is intended as a general overview to help put the complexity into a simpler context.

Where the game looks for resources

When the Dragon Age executable is run and a new game starts up, the game loads a set of resources that define every aspect of the campaign world and the story that the player will experience within it.

All resources are marked as belonging to specific modules or packages (such as the single-player module that's the main campaign of Dragon Age: Origins).

Modules and packages can be set to inherit resources from other modules (called their 'dependencies' since they depend on the resources in them). This allows modules to build on each other and interact in an organized manner; each level in a module hierarchy can add to or supplant the contents of previous levels. At the root of this hierarchy is a special group of resources called "core" resources that all modules inherit from, consisting of basic features such as the game's combat scripts and the default behavior of interactive objects.

Each module or package will also have an "override" directory that can supplant the contents of that package. This is the directory where the toolset exports playable content during development.

As an example, you could create a module named "Dwarven Madness" that takes place in an area that the player visited in the main single-player campaign. You want to make use of the same area layout that was used in the single-player campaign, but add your own resources in the form of different creatures to fight and a new plot to follow. You would therefore set your module to inherit the resources of the single-player campaign, which itself inherits core resources. When the game starts and tries to load a resource it looks in the following places, in order:

  1. Dwarven Madness' override directory
  2. Dwarven Madness' module directory
  3. Single Player's override directory
  4. Single Player module directory
  5. Core resources override directory
  6. Core resources directory

(See Source directory priorities for a complete listing of all the places the game can look for resources.)

While you're developing the module in the toolset, exported resources will be placed in the Dwarven Madness override directory.

Toolset resources

There are three basic sorts of source resource.

  • Art resources - things like creature models, visual effects, sounds, and levels. These are stored as ordinary files in your file system.
  • Database resources - in general, the instructions to the game on how to use art resources. This includes scripts, dialogue, cinematics, plots, placing objects in area layouts, and so forth.
  • 2DAs - "two-dimensional arrays", tables of data that are referred to by scripts or by the game engine. These are defined by ordinary Excel spreadsheets.

The following diagram illustrates the general outline of how each of these types of resource is edited, processed, and used by the game:

Overview.png

The designer toolset exports playable resources to the override directory. To use a programming metaphor, the toolset is a compiler and the objects that go into the override directory are the compiled executables. The "source code" for these finished products is stored elsewhere in a wide variety of formats.

At the time of writing, the End User Toolset contains the Excel processor for creating 2DAs and the Designer Toolset, but does not contain most of the Art Toolset. Most notably, it doesn't contain a level editor, which means that only pre-existing levels can be used in the Designer Toolset at this time. We intend to release more art tools to the end user as soon as we're able but cannot commit to a schedule at this time.

Sharing designer resources

If you're collaborating with other builders, you'll want to share the "source code" for your game resources instead of just the "compiled" finished product from the override directory.

For the art resources and 2DAs this is simply a matter of locating the files on your hard drive and making those available. Designer resources are a bit trickier and can be shared in two fundamentally different ways:

  • "Builder to builder" export, which exports selected source resources from the database in a non-playable XML format suitable for importing by another builder's toolset.
  • Shared access to a single database. The toolset supports simultaneous access to a single database by many different toolsets, but setting this up can be somewhat tricky and depends on the availability of the database server.