Difference between revisions of "Module"

Revision as of 07:04, 31 January 2010

Modules are the campaigns that players can embark on. They contain the resources needed for the adventure they encompass (though you can also have modules inherit the resources of other modules).

Overview

A Module is a single collection of Resources, that can be the building block for another Module (Addin) or function on its own (Standalone). A set of Properties tell the game how to integrate the Resources it inherits. A Resource tells the game how it finally behaves.

The Single Player Campaign and Core Game Resources are each one of such modules. Modules can be setup hierarchical, for example the Singleplayer Module is connected to the Core Game Resources and thus can use its resources. Custom Modules can be connected to any other Module.

Core Game Resources is however special in a way, that it is the foundation of any other Module, and any Module can use its Resources.

Working with a Module

What are the possible options you have when creating the basis for your Content? Generally one can say a Module can either be standalone, or addon to the existing Campaign. Standalone is a Module which from hitting "custom campaign" in the main menu starts completely fresh into a custom campaign (like the Demo module for example). A Module is an addon, if content is added or perhaps changed to the existing campaign so that it influences the existing campaign but doesnt remove it (like Shale for example).

• Standalone is pretty straightforward, in that you need at least a starting Area and a Waypoint in which the Player spawns. You can use any Core Game Resource while making this Module, basically the premade Houses, the Monsters, mostly anything. But the Area still has to be created ,NPCs placed, Dialogues written etc..
• Addon is something initially tricky to do and perhaps unknown to most, even when doing something simple. You need at least one entry point that hooks into the main campaign, and from there it can be a simple added weapon, or unfold into big things. And that entry point is called "PRCSCR". See below.

A slightly dirty method is changing a Resource of the Main Campaign. This is plainly achieved by editing a Designer Resource from the Toolset and export it under the same name, which is then a override Mod, and undesired effects can potentially reflect back at the Main campaign and other Modules. This should be left for when you know really well what the consequences are.

Outlining a few general steps involved during developement. The first an foremost is logically to create a Module.

See Article: Creating a module

This is where further work should be done. Testing a Module, on a single by single Resource basis ,things must be exported first. Since Designer Resources are normally inherited by the Database.

See Article: Exporting a module

Since exported Resource only work on your PC, the Toolset has functionality to allow these to be packaged into a installable Filetype DAZIP

See Article: Builder to player

PRCSCR - Pre Release Content Script

Modular File structure

Modules are organized in the Filestructure as such the Game can read the correct files, and to allow a modular environment. The Singleplayer Campaign and Core Game Resources use a fixed set of Filefolders.

The Singleplayer Module and the Game Core Resources respecivtly (this is the actual installed content) are located in:

*DragonAgeInstallDir*\modules\single player\
*DragonAgeInstallDir*\packages\core\

These base Folders accompany all Resourcetypes specific to that Module. However this is a fixed set, and should be of value to modders only when extracting Resources.

Modularity is made in your users folder, where the Toolset exporter distributes Resources into the respective Modules override Folder, as well as creates or stores "builder to player" packages from those Folders. A 3rd Moduletype called Addin is created there which similarily has a "module" Folder for any Resources for that Module alone, and a "core" Folder for any Resource to be accessible by other modules. It looks like this:

*My Documents*\BioWare\Dragon Age\AddIns\*Modulename*\module\
*My Documents*\BioWare\Dragon Age\AddIns\*Modulename*\core\

alongside a double of

*My Documents*\BioWare\Dragon Age\modules\Single Player\
*My Documents*\BioWare\Dragon Age\packages\core\

The Toolset exports any Resource into each of these Folders, or specifically the override Folder beneath it, depending on which Module the Resource belongs to. When packing the Resources into an installable DAZIP file, you have to specify any of those folders to include. Thus it is to great part important where Resources are located, and especially where files shouldnt be located.

When you have not worked with the Toolset before you may not have adhered to that structure before, as Resources will get read from any Override anyway. However, this is to a great part organizational for the Toolset.

Properties

Variables

The module_var variables 2da contains a number of variables that are only used by the original main campaign for Dragon Age. Most of these can be ignored when creating other modules. In fact, the vast majority of the variables in this table are only referred to by core scripts; most modders will likely not need to worry about these.