Dragon Age Toolset Wiki - User contributions [en]

Area tutorial

2009-12-16T17:25:22Z

GameVoid: /* Creating the area */

== Creating the area ==

Once you have created a new module (see [[creating a module]]), the first thing you will likely want to do is create one or more areas where your adventure is going to be set. There are several ways to reach the "new area" command; you can right-click on the resource palette window, or select "new" from the file menu.

[[Image:New resource.png|thumb|center|New resource menu]]

<br clear="all" />

Areas are represented with the [[Image:IconArea.png]] icon. When you select it you'll be presented with a "Create New Resource" window:

[[Image:Create new resource.png|center|]]

{{sidebox|
* Resref names should be useful to the designer
* Set the "area layout" property to assign terrain to an area
* "Resource Name" and "Tag" are only seen by developers
* "Name" may be seen by players
}}

Most of the fields are already filled in with good defaults for the module you're working with. You'll need to supply a "ResRef Name", which is the name by which the resource will be known internally to the toolset. (This is the "Name" field on the "Create New Resource" dialog box.) You'll probably want to use a name that will remind you, the module designer, of the purpose or important features of the area. Changing a resource's name is difficult to do later. We're going to call the first area of the tutorial "hut_exterior".

After creating the area you'll be presented with a completely blank area editor. There will be no environment or objects of any kind. To specify what environment you'll be placing objects into, open the object inspector and select the "Area Layout" property. There will be an ellipsis button ([[Image:ellipsis.png]]) in the property's data field that will bring up a resource selection window where you can select an environment to use for this area. The environment we wish to select is in the area layout file "ost101d.arl". Once we select it, the area layout appears in the main area window.

The resource's internal resource name is hut_exterior but the player will not see this when he's playing the game. To give the area a name meaningful to the player we'll set the "Name" field to "Deep in the Swamp". All of the other defaults are fine for now, we will leave them as is.

[[Image:Area tutorial 1.png|thumb|600px|center]]

== Area Basics ==
{{sidebox|
* See [[3D control]] for camera and movement controls
* You can double-click on an object in the area's object list to zoom in to it.
}}

Moving the view around inside the area layout can be somewhat non-intuitive and frustrating at first. The toolset has a number of different control schemes it can be set to; see [[3D control]] for a summary of the various options. By default, you can:

* zoom in and out by using the mouse wheel
* rotate the camera around the target it's focused on by holding the middle button down or by holding down the Ctrl key and the right mouse button while moving the mouse
* translate the camera by holding down the Ctrl key and the left mouse button while moving the mouse

To see where you are a bit better, it is helpful to deactivate real lighting or turn on full brightness. Above the area viewer, the sun-like button should be toggled so that it isn't highlighted; see [[Area]] for a more complete summary of various options within the Area Editor.

Sometimes the Area Editor may show your level as a wireframe when you create it. You can switch from a wireframe view to a normal view by going to the View menu and choosing View/Environment/Render Mode/Normal.

Before we move along to placing a starting location, it is important to touch upon Pathfinding points. All BioWare areas include walkmesh or pathfinding information. To view pathfinding information for your area, goto View, then Environment, and then toggle Pathfinding Points on. The green dots represent areas where characters can walk. Note, in this map, the area that is walkable is quite small compared to the entire area. When placing your starting location, you should ensure it is in a walkable portion of the area.

== Setting the start point ==

{{sidebox|
* Create a waypoint to mark where the player starts the game
}}

This is going to be the starting area for the adventure, so we're going to want to define a spot within the area where the player will first appear. This is done by setting a [[waypoint]]. Waypoints are very simple objects that mark locations in an area that other objects in the game can refer to; they are not normally visible to the player. To create a waypoint, right-click somewhere in the area and select "Insert Waypoint" from the resulting menu. A waypoint will appear at the location of your mouse pointer and follow it around along the area's floor; move it to the approximate place you want to have the player appear and left-click to place it. By default the waypoint is named "Waypoint".

The waypoint will be automatically selected, indicated by a yellow wireframe box surrounding it. You'll also see the waypoint listed in the area's object list, to the left of the display window. If you lose track of the waypoint later a good way to find it again is to right-click on the waypoint in the list and select "Zoom to Object" in the resulting menu or double click on its tag to center the object in the display window. The waypoint's properties will be shown in the object inspector. We want to change the waypoint's name to something more informative, in this case to "start". More importantly for the game itself, though, we'll also want to change the waypoint's tag to "start" (it defaults to blank). An object's tag is how scripts and other resources will refer to the waypoint. Since this particular waypoint is never going to be visible to the player it's likely that the waypoint's name will never be seen at all.

The player will also start out facing in the same direction that the waypoint is facing (indicated by the arrow-shaped base of the waypoint object). If we don't want the player to start out facing in the default direction, we'll want to rotate the waypoint to point in a new direction. To rotate an object, use the toolbar to switch from standard selection mode ([[Image:Standard selection mode.png]]) to 3-axis rotation mode ([[Image:3 axis rotation mode.png]]).
When you select the waypoint in this mode you'll see a set of circles around the waypoint's base with various orientations; clicking and holding the mouse button on one of them will allow you to rotate the waypoint around its center.

[[Image:Waypoint rotation.png|center]]

Now that we have an area and a waypoint to start at, we can now tell the module that this is where the player is to appear. Reopen the "Manage Modules" window (available via a command under the File menu), select your module, and click the "Properties" button. This opens the module's properties. For the "Starting Area" property, click on the ellipsis button ([[Image:ellipsis.png]]) and select the starting area from the areas available in the module; since we've only put one area in so far "hut_exterior" will be the only available option. Once the area has been selected we can then select the starting waypoint from the waypoints currently placed in the area. Note that the list will show waypoint tags rather than names. Again, we've only put in one so this will be easy. You can also set the player to appear at the origin of the map (coordinates 0,0,0), but this is generally a poor choice and available only as a default in case there are no waypoints defined yet.

== Area transitions via doors ==

Adventures almost always have more than one area in them, so we'll create a second area to demonstrate travel between the two. The area "hut_interior" will use area layout ost102d, which is a cosy little room that represents the interior of the small hut present in the hut_exterior area.

{{sidebox|
* [[Door]]s are special placeables
* Doors can attach to "hooks" pre-built into the area layout
* Area transition doors use a different "appearance" than within-area doors
}}

Next we will need to create some doors. We'll create a default door placeable using the "New Placable" command, reached in a similar way as the "New Area" command explained earlier (placeables will be covered in the [[Placeable tutorial]], but the core game resources will come with a variety of default doors usable in many situations like this) and place it in the area near the empty doorframe built into the hut's exterior. For an area transition, use one of the "Area Transition" appearances for the door. To place the door, click on it in the palette; the mouse cursor will turn into a crosshair; then click in the area viewer near the doorframe.

As a side note, if you accidentally use one of the standard door appearances it won't work as an area transition: the door will simply swing open when clicked on instead. Each standard door appearance has a matching area transition door appearance in the resource database so this can be an easy mistake to make, but it's also easily correctable - just go back to the door's placeable resource and swap in the correct appearance, and all copies of that door in use throughout your game will be updated. The "Area Transition" doors are at the top under the Appearance list, e.g. "Area Transition, Ferelden Small" as apposed to "Door, Ferelden, Small".

You may notice that when the door you placed in the area is selected a small blue sphere will appear at one edge in addition to the yellow wireframe bounding box. This is the door's "hook". Area layouts come with hidden "hooks" pre-installed to place doors on, and doors have matching hooks of their own. If you click on the blue sphere it will turn red, and all of the compatible door hooks built into the area's layout will appear. The following image illustrates this:

[[Image:Door with door hook selected.png|400px|center|thumb|Drag the red sphere near to the blue sphere to automatically position the door]]

To hook a door up with its frame, simply click and drag the door's hook to a location very close to the matching frame hook. You don't need to get the positioning exact; if the two hooks are close enough together when you release the mouse button they'll automatically snap together. The door will be positioned and reoriented to fit correctly into the frame. Make sure you're still in the 'Standard Selection' mode ([[Image:IconStandardSelection.png]]) for the snap to occur, if you're in the more advanced 3 Axis Movement tool, the snap will not happen.

Note that door hooks are only there to make it easy to get exact matches on frames and walls that need a snug fit, to ensure that Artists and Designers don't have to spend a lot of time putting it in place. Doors will function just as well off of hooks as on them.

{{sidebox|
* Area transition effect is defined in the door's "Variables" property
}}

Next, we'll tell the game engine that the door is an area transition door and that when the player clicks on it he will be transported to another area of the game. This is done by setting two of the door's [[variable]]s. Select the door (either in the area's object palette or directly in the main display window) and right-click on it, selecting "properties" from the resulting menu. This will open the door's properties in the Object Inspector window. Select the "Variables" property and click on the ellipsis ([[Image:ellipsis.png]]) button. This will open up the variable browser for that particular instance of the door object.

There are two key variables in this list that we'll need to set:

*PLC_AT_DEST_AREA_TAG - tag of the destination area
*PLC_AT_DEST_TAG - tag of the destination waypoint within the destination area. This is a waypoint that you must add. It is NOT added automatically when you create the door.

Once we've set these the door will become an area transition door, and when the player interacts with it they'll be transported to the target area.

The destination area is "hut_interior". We'll create a waypoint just inside the hut's interior door, tagged "hut_door_interior", to serve as the place where the player appears.

Here is how the exterior door's variables should look:

[[Image:Area tutorial door variables.png|frame|center|Area transition door's variables]]

And here is the interior door, with the destination waypoint:

[[Image:Area tutorial interior door.png|frame|center|Interior door with destination waypoint]]

The interior door is set up in the same manner, with a destination area of "hut_exterior" and a matching destination waypoint of "hut_door_exterior".

{{sidebox|
* Use invisible area transition "doors" when the transition is already built into the area layout art
}}

If you want to create an area transition that doesn't look like a door, or is otherwise already represented by the level art, you can use an invisible 'door' instead. Appearances for these invisible placeables are named "Area Transition, Invisible". Set its variables the same way as was done for the visible door.

[[Image:Area Transition, Invisible.png|frame|center|Invisible area transition]]

The player won't see this 'door' in the game, but when he moves the mouse pointer over it it will change to signify that an area transition lies there and it can be right-clicked to be activated just like a visible door.

== Area transitions via triggers ==

{{sidebox|
* Triggers use variables with a different prefix for setting their area transition effect
}}

Finally, you can also create an area transition that triggers automatically when the player walks into a predefined area. This is done using [[trigger]]s. ([[Image:IconTrigger.png]]) You'll first have to create a trigger resource, much like how you had to create a placeable door earlier, but trigger resources are much simpler and for area transitions you won't need to change any of the defaults. Create a default trigger with "New -> Trigger" (either by right-clicking the resource palette or from the File menu) and give it an informative name such as "trigger_area_transition".

Go back to your area map, select the trigger from the resource palette, and then click on the map to define the corner points of the area the trigger will occupy. Double-click the last vertex to complete the polygon. A trigger can have any number of vertices, and vertices can be moved, added, or deleted after the trigger is created so don't worry if you don't get it exactly right. Note that the blue plane the trigger uses to show the enclosed area will pass through the ground and may not be entirely visible in the toolset, but it extends infinitely upward so the trigger will still take effect if the player enters its boundaries.

To set the trigger's destination, you'll find a familiar pair of variables in the trigger's default variable table:

*TRIGGER_AT_DEST_AREA_TAG - tag of the destination area
*TRIGGER_AT_DEST_TAG - tag of the destination waypoint within the destination area

(Note the prefix "TRIGGER" instead of "PLC")

Below is an example where we've placed both a trigger and an invisible door across a pathway. Note that this is redundant, only one or the other is really needed. For most purposes a placeable area transition is probably best. (''It is worth noting that placeable area transitions prompt a popup asking the player if they want to transition when bumped, but not when clicked upon - effectively acting as either a door or a trigger.'') The waypoint shown is the arrival spot for the player when coming in from the other side; note how it's placed outside the trigger area, allowing the player to immediately back up and retreat through the area transition if he chooses.

[[Image:Area Transition, invisible with trigger.png|center]]

== Grouping Placeables ==

{{sidebox|
* Two or more placeables can be grouped together using Associations.
}}

Often the placeables within an area are related. For example, a firepit placeable probably has an associated sound emitter. The toolset needs to be told that these two objects are related.

# Create a new Placeable and change its "Appearance" to "Firepit (Dialog)", then place it in your area. Remember that if you can't see the new placable, make sure you have the correct module open.
# Next, click on the musical note icon in the Palette for "Sounds".
# In the folder tree, go to global_amb_fade > 3D_placeables > 3d_emitter and select the amb_ext_smfire1_lp and place the emitter in your area.
# Right-click on the firepit to bring up the menu and choose "Add Associated object." The cursor changes to a cross-hair.
# Click on the sound emitter placeable.

Now when you drag the firepit placeable around the area, the sound emitter will automatically follow. Use the "Managed Links" menu item if you want to remove an association. Note that associations are uni-directional; you can still move the sound emitter without moving the firepit. Examples of other useful associations: a table and all of the items on top of the table, a table surrounded by chairs, etc.

== Sound ==

Sounds are placed using the Area Editor. For more details see [[Sound]].

[[Category:Areas]]
[[Category:Tutorials]]

Level Editor Tutorial

2009-12-16T15:21:14Z

GameVoid: Just some minor clean up and spelling corrections.

=Building your room (Interior Level)=
How to create/lightmap a [[Level]] for use in an Interior [[Area]]:
Objective: Following along with this tutorial, you should be able to create a simple room from scratch in 10 minutes or less

This was lifted from a posting by St4rdog http://social.bioware.com/forum/1/topic/8/index/150840
It needs some additional formatting love, but is as good starting place for people to create usable
interior levels

File > New > Level > Room Level

* Click on "New Area" in top-left list > Object Inspector in bottom-right > Layout Name > anything under 8 characters no spaces or special characters (*,&,%, etc).

*Right-click in 3D view and select Insert > New Room.
*Click Models (blue box) in the Palette in the top-right. These folders contain everything such as floor tiles, walls, etc.
*Enable Grid Snap with the magnet icon to make sure they line up.
*The "prp" folder contains things like beds/barrels to clutter your Level.
Hint: Use [[DATool]] (3rd party tool downloadable at http://social.bioware.com/project/41/ )to browse
through these quickly to find the floors/walls you want.

Note: If you get "Cannot spawn models into the selected parent object" when trying to place a model
then you don't have "New Room" selected.

==Working with multiple rooms==

In general it is best to define each building room as a new room in the level. This becomes important when you work on lighting. To physically connect rooms you need to slide them together to get the doors to line up, they do not line up automatically. It takes some trial and error but becomes easier with practice.

==Adding lights==

* Right-click on "New Room" in top-left list > Insert > New Light

* Move it up off the floor a little. In Object Inspector > "Color
Intensity" 2 or more > "Light Type" Point - Static (lc) > Choose
any bright color.

*Copy and paste. In Object Inspector >"Light Type" Ambient - Baked (this light stops your shadows being pitch
black) > Choose a dark blue colour and keep the Color Intensity under 2/3.

Note: I'm not sure what the mix of Baked/Static light is supposed to be.
If you just put a Baked + Ambient it complains about not having Static, but if
you put a Static + Ambient it seems to work fine, but the wiki says Static is
the most expensive.

==Rendering Lightmaps==

*Press the Render Lightmaps icon (you need ActivePython 2.5 installed to default location). When it's done click the Display
Lightmaps On/Off icon in the top-left to refresh the results.
*Uncheck the "View Models Fully Lit" icon in the lop-left. You should see shadows from any objects you've dropped in.

Note: Lightmap-atlas messages might appear the first time you render. That seems normal.
Sometimes re-rendering the lightmaps messes them up badly when Display Lightmaps On/Off is on. It
doesn't seem to use the latest lightmaps. Try pressing Display Lightmaps On/Off a few times to
update it. If they're still messed up sometimes one of these fixes it (don't know which)
unloading/reloading your Area or Level/changing your Area's layout property/posting your Level to
Local.

==Exporting==

*Press the Do All Local Posts icon to the right of the lightmapping icons. It will export the name you typed into the "New Area" "Layout Name". If there's a complaint about walkable/player start then delete your old start then place a new one on a flat area.

*Save your .lvl file. It's not used by the game and the name/location doesn't matter. Only the exported/posted files are used.

==Using this in an Area==

File > New > Area > Any Name

*In the Object Inspector > Area Layout you should get a "..." box (make sure it's Checked Out) > click then select your "Layout Name" which should now be there.

* Now you have a pretty lightmapped level inside an area.

=Building your terrain (Exterior Level)=
How to create/lightmap a [[Level]] for use in an Exterior [[Area]]:
Objective: Following along with this tutorial, you should be able to create a simple terrain from scratch.

File>New>Level

* Choose Terrain (Landscape) Level and then click Next.

* Accept the default values for the purpose of this tutorial and click Next and then click Finish. You can learn more about what the different terrain options do at the [[Level editor]] page.

You should now see a flat, dark piece of terrain. To move around you hold down the mouse wheel. If you want to rotate the view press the Alt key while holding down the mouse wheel. You will want some light so you can see what you are doing, so we will generate a light source next.

Tip: When choosing the size of your terrain level think about where you are going to put horizon and vista objects, like distant mountains and tree lines. You may need to allow for extra space around your adventure area to place those items.

==Grid Size==

If you want to work with a larger grid than the one provided by default you can change the grid size by going to:

Tools/Options/Level Editor/Grid Square Size.

This will not change the actual dimensions of the terrain level that you created, it only changes the size of the squares in the grid.

==Define an area==

Must be done before rendering the lightmap.

* Click on the purple +-sign and click Define Area. Start in one corner and draw the green square to define the area that you will export.
* Fill in the box Layout Name, max seven characters.
* Fill in the box Name.

==Lighting==

* Right click on Terrain World to the upper left and choose Insert>New Light. This will spawn a light source in your area. Make sure you change the Light Type to Ambient - Baked (L). Be sure to click on the Render Lightmaps button if you want to see how your ambient light is working.

Now that the terrain is lit we can modify it.

==Modifying Terrain==

The [[Terrain mesh]] tools allow you to modify the terrain by changing elevations, smoothing edges, flatting terrain, or painting textures.

==Water==

Please note that as of build 1.0.982.0 water is broken. You can see it in editor, but it is not making it into the game.

First use the [[Terrain mesh]] tools to make a hole. It doesn't have to be deep. Then right-click on Terrain world and select Insert -> New Water Mesh. Double Click on the Water Mesh to zoom to it. By default it gets placed in a corner. Using the 3 Axis Movement tool [[File:moveTool.png]] grab the water and drag it to your hole. Depending on the size of the hole, you might have to adjust the water mesh size by changing the Size X and Size Y property values. Once you have the mesh placed, it's time to create the light probe. Right-click near the water mesh and select Insert -> New Light Probe. Using the move tool again, drag the light probe so that is roughly centered over the water mesh and slightly above it. Click on Render Lightmaps, then Render Light Probs. You might have to toggle Display Lightmaps, but you should now see your water looking like water and reflecting things around it.

==Placing Models==

* Click the blue box in the Palette Window to access the models that come with the game. The [[Model list]] shows pictures of many of the models available.

* The [[Model]] page has more details on how to work with models.

Tip 1: I had to change the Snap Options to make the models go where I wanted them. The settings I use were 0.10 for Snap to Grid and Snap Z Size. I also had to turn off Enable Snap to Surface whenever I wanted to change the vertical position of something (like creating the second floor of a building). Enable Snap to Surface is not applied globally, so once you turn it off and position an object vertically, turning it back on will not move that object unless you select it (or have it selected when you turn it back on).

Tip 2: When placing premade cottages be aware that the door frames you can see attached to those buildings DO NOT have built in door hooks (see [[Area tutorial]] for information on placing doors). You can place a door frame model (for example, fhe_doorfrs_0) over the built in door frame to generate a door hook. The door frame model has to be placed from the Level Editor.

==Adding Vegetation and Wind==

The [[Vegetation]] page includes a list with pictures of the various plants available for placement. If you do not see the plants once you place them with the Scatter Object Tool then you may need to adjust your SpeedTree Rendering Distance Selector. This is a drop-down that you will see in the Tool Bar. It lists the distances at which plants will be visible. I set it to Very Far and left it there.

Each level can have one active wind object in it. The location of the wind object doesn't matter. The wind object defines how wind behaves on this level, which is used for such things as flapping banners and swaying trees.

Image:Level editor wind object.png

The Wind Object may be found by right clicking on Terrain World and selecting:

Insert>New Wind Object

==Visual Effects (VFX)==

Placeable visual effects like flames or smoke are considered to be art assets in the Dragon Age toolset, so you need to place them from within the Level Editor.

The [[VFX Tutorial]] provides guidance on creating and placing visual effects.

==Path finding and Obstructions==

The path finding process lays down a grid of points that are marked "accessible" if they can be reached from a path finding start spot via passable terrain. This is essentially a flood-fill algorithm.

You must create an Exportable Area before you can generate any path finding data.

* Click on the purple + in the tool bar. This will open an Area Properties window. The [[Level editor]] page has more details on this process, so I will just keep these steps very basic.
* Name your Exportable Area in the Layout Name field of the Area Properties window. The name of an exportable area layout is limited to seven characters. BioWare uses the following naming system:
** Three-letter prefix that describes the region or plot the layout is for. For example, "ost" for Ostagar and environs.
** Three-digit number that uniquely identifies the layout within that region. Increments of one hundred are commonly used for major areas to allow sub-regions to be grouped together.
** A single character identifying variants of the layout. For example, a "d" suffix for the "daytime" version of an exterior layout. "d" is also often used to mean "default", for areas where day and night are irrelevant (deep in a cave, for example).
* Define your walkable area. Do this by clicking the Define Area button in the Area Properties window. The green box must include any areas that you want players to be able to walk. If you click in a corner of the level the green box will appear there. You can then expand it by dragging the corner.
* Close the Area Properties window.

In most cases you will want to block off certain areas of your terrain.
* Turn on the Build Terrain Blocking tool. It is the middle mountain icon.
* Using left-click to place and right-click to end chains/delete, place down blocks or 'walls' around areas you don't want the player to enter
* Be sure to provide visual clues if it isn't obvious why the player can't walk there.

Now that you have your exportable area you can generate path finding data.

* Place a Starting Point in your level. I found that path finding does not work if you place the Starting Point before you have an Exportable Area. To place a Starting Point click on Setup Start Point in the tool bar.
* Record the name of your Starting Point by clicking on it and looking at the name in the Object Inspector. Do not change the name - changing the name can prevent path finding from working.
* Click Exportable Area Properties in the tool bar to open the Area Properties window. Put the Start Point name in the appropriate field and close the window.

You should now be ready to generate pathfinding data by clicking on the Generate Pathfinding for Active Area button in the tool bar.

==Converting Levels into Areas==

Click on Do All Local Posts (you can avoid problems by generating a lightmap and pathfinding before doing local posts). This can be found in the menu at Tools>Export>Do All Local Posts

Your level has now been converted and can be used to make an area. The [[Area tutorial]] will walk you through what to do next.

[[Category: Tutorials]]

Module tutorial

2009-12-15T17:33:09Z

GameVoid: The casual reader might not realize that they need to be following along with the demo module included with the game, adding links to hopefully clear it up a bit.

The simple [[demo module]] that is included with the Dragon Age Toolset is intended to show off a variety of methods that will be commonly used in real stand-alone modules. The documentation on this website will walk you through the major steps required to set it all up, but the [[demo module]] itself also has documentation embedded within it in the form of comments; it is intended to be explored in the designer toolkit and dissected to see how things tick.

One thing that this demo doesn't demonstrate is the art of writing. As such the 'plot' of the adventure is somewhat nonsensical.

This tutorial also assumes that you've read many of the other basic tutorials elsewhere on this site and are familiar with the basic functioning of the toolkit. Links will be provided directing you to more specific information if needed.

== Organization ==

There are two major groups of resources that are used when creating a Dragon Age module; designer resources and art resources. Designer resources are housed in a database whereas art resources take the form of conventional files on your file system.

For your art resources the most convenient approach it is probably to create a directory tree with subdirectories sorting your art resources by what regions of the game they appear in. The directory tree should be someplace easily accessible and with full read/write priviledges - somewhere in your "My Documents" folder is a good place to put them.

In our example we're going to have three areas:
*A swampy outdoor area with a small tavern in it
*The tavern's interior
*An outdoor roadway

=== Naming conventions ===

For the most part the names you give your resources will matter only to you, there are very few situations where the toolset pays attention to the specific form that a resource name takes. So provided you're working on your own, any naming convention that suits your particular style will suffice.

Dragon Age is a large and complex game to create content for, however, so establishing ''some'' form of naming convention and adhering to it from the outset is important to ensure you don't lose track of things later on. A consistent naming system is very useful for debugging and if you later choose to collaborate with other builders it allows you to find your way around other peoples' work without needing to know it intimately.

The convention used in the main Single Player campaign of Dragon Age is as follows:

*Three-letter prefix indicating which large-scale area of the game the resource begins to (particular origin story, prelude, etc)
*three-digit number unique to a particular area, generally starting with 100 and incrementing in hundreds for major areas. Accessory areas are given numbers within the block of one hundred that their 'parent' area belongs to. "global" resources are often given the number 000.
*two-letter code indicating what general type of resource it is (for example "ar" for area, "pl" for placeable). A major exception here is event scripts, which have exactly the same name as the resource they're the script for. Dialogue files are also generally named exactly the same as their owner resource.
*An underscore.
*The remainder of the name is free-form and human-readable, a descriptive term to remind you at a glance what the resource is.

Designer resources will have a three-letter extension, much like a regular file system file, but this is not editable and does not frequently come up.

Resources in the designer toolkit can also be placed into folders, again much like a regular file system. Unlike most file systems, though, you don't need to explicitly create a folder in order to put a resource into it. Just edit the resource's "folder" property and if the folder didn't have anything in it before it'll be created automatically. Folders that don't have any resources in them are removed automatically.

Here's a preview of what we're going to put into the demo module, to illustrate how this naming convention looks in practice. We'll be using the four-letter prefix "demo" instead of the usual three-letter one for clarity.

[[screenshot of demo resource palette]]

== Setting up character generation in a new module ==

The most basic steps of creating a new module are described in "[[creating a module]]". A Dragon Age module, when first created, lacks many very basic components such as the ability to generate a character or an area to start in.

Note that you can actually start creating areas and testing content before you set up character creation if you prefer, the game will provide a player with a simple (and very weak!) default character if character generation isn't performed. You can also override the default starting area and waypoint every time you export for testing purposes, using the "Export Options" found under the "Tools" menu, so you can skip directly to the area you're working on without needing to write debugging scripts.

We're going to follow the flow of the finished game for now, though, so after creating the module the first thing we'll want to do is create a module script that triggers character generation.

Once you've created the initial empty module you'll need to create a module script. We call it "demo_module". The event that we'll want to handle character generation in is EVENT_TYPE_MODULE_START, which is sent to the module script only once when the game is first started up.

To call the default character generation system, simply have this event call the following functions:

<pre>
PreloadCharGen();
StartCharGen(GetHero(),0);
</pre>

PreloadCharGen causes the game to load up various resources that will be used in character generation, and StartCharGen causes the game to show the character generation GUI to the player.

== Creating our areas ==

This module will be very simple, consisting of only three areas - only two of which will have any signficiant amount of detail. They will be named:

* demo100ar_wilderness
* demo200ar_tavern
* demo300ar_road

Three level layouts ([[LVL]] files) are included with the module for use in these areas; ost101d (a swampy wasteland with a small wooden structure), hrt002d (a small tavern interior), and lgt600d (a section of roadway). The naming convention for level layouts used internally at BioWare is specific to the single player campaign, the meaning of these filenames is not relevant to this basic tutorial.

The area editor (and the game itself) cannot use a LVL file directly, it must be compiled into a more efficient form for use. Open up each LVL file in the level editor and, under tools, select "Post to local" to compile the level and export it to an appropriate directory where the game and toolset will be able to find it.

Once you've done this you can select the layout in the area editor's "Area Layout" property field.

== Placing area transitions and setting up the world map ==

See the [[Area tutorial]] for details on how to link areas up with level transitions. The transition from demo100ar_wilderness to demo200_tavern is straightforward and is basically the same as what's shown in that tutorial.

The transition between demo100ar_wilderness and demo300ar_road, however, is going to be handled via the world [[map]] instead. The demo's map is a resource named demo000mp_world.

To create an area transition that sends the player to the world map, set the PLC_AT_DEST_AREA_TAG to the string "world_map". The placeable_core script recognizes this string as a special override that triggers a map transition by sending the module script an EVENT_TYPE_BEGIN_TRAVEL event.

Note that you can have multiple world maps in a module, but under the default code you can't directly specify which one an area transition will send the player to. Instead, you will need to call the script function WR_SetWorldMapPrimary to specify which world map is the currently active "primary" one. In this demo the code that performs this is also in the EVENT_TYPE_MODULE_START event of the module script, since we only have one map and it only needs to be set as primary once. If you have multiple maps in your module you'll need to call this function again later from some other scripted event to change it.

Here, then, is the complete code for the demo module's EVENT_TYPE_MODULE_START event:

<pre>
case EVENT_TYPE_MODULE_START:
{
object oMapId = GetObjectByTag("demo000mp_world");
WR_SetWorldMapPrimary(oMapId);

PreloadCharGen();
StartCharGen(GetHero(),0);
break;
}

</pre>

Although the default placeable_core script has code in it to recognize that the "world_map" string should lead to a world transition and generates an EVENT_TYPE_BEGIN_TRAVEL event, the default module_core script doesn't actually do anything with this event. This is because the map transition code used in Dragon Age's single player world map transitions is rather complex and has to handle many special cases that depend on plot elements specific to the single player campaign, so BioWare never implemented a basic default - it would have had to be overridden completely anyway.

Fortunately it's quite easy to add one, though there's a slight hitch; the area transition code needs to be split over two different events.

* In EVENT_TYPE_BEGIN_TRAVEL you'll be able to get the target area and waypoint tags from the event object, and then call the <pre>WorldMapStartTravelling</pre> function to cause the map to start animating the map trail path the player is following.

* While the map trail animation is playing, the EVENT_TYPE_WORLDMAP_PRETRANSITION event is called. This is the event where you'll want to call the <pre>UT_DoAreaTransition</pre> function to start the loading process of the destination area. The area will load at the same time that the map trail animation is playing, making the transition seem more seamless for the player. Note, however, that EVENT_TYPE_WORLDMAP_PRETRANSITION's event object ''doesn't'' contain the destination area and waypoint tags as members; you'll need to use local variables in the module's variable table to preserve these strings and pass them on from EVENT_TYPE_BEGIN_TRAVEL.

The basic code to handle map travel, then, is:

<pre>
////////////////////////////////////////////////////////////////////////
// Sent by: The engine
// When: the player clicks on a destination in the world map
////////////////////////////////////////////////////////////////////////
case EVENT_TYPE_BEGIN_TRAVEL:
{
string sSource = GetEventString(ev, 0); //area tag source location
string sTarget = GetEventString(ev, 1); // area tag target location
string sWPOverride = GetEventString(ev, 2); // waypoint tag override
if (sSource != sTarget)
{
//store target area's tag to a local module variable
SetLocalString(GetModule(), "WM_STORED_AREA", sTarget);
//store target waypoint tag
SetLocalString(GetModule(), "WM_STORED_WP", sWPOverride);
//initiate the map's travelling animation. The engine will
//send EVENT_TYPE_WORLDMAP_PRETRANSITION once it's started.
WorldMapStartTravelling();
}
}

////////////////////////////////////////////////////////////////////////
// Sent by: The engine
// When: the world map has begun its "travelling" animation
////////////////////////////////////////////////////////////////////////
case EVENT_TYPE_WORLDMAP_PRETRANSITION:
{
//retrieve the target area tag we stored in EVENT_TYPE_BEGIN_TRAVEL
string sArea = GetLocalString(GetModule(), "WM_STORED_AREA");
//retrieve the target waypoint tag
string sWP = GetLocalString(GetModule(), "WM_STORED_WP");
//execute the area transition to that target.
UT_DoAreaTransition(sArea, sWP);
break;
}
</pre>

We'll need to come back to the module script later on to add some plot-specific code, but for now this is all that's needed to enable a basic adventure to stand on its own.

== Introductory cutscene ==

After the player has finished character generation we play an introductory cutscene for him before the game starts.

The cutscene itself is quite simple, consisting of a few camera movements and an actor (substituted by the player) playing a walking animation. See [[cutscene tutorial]] for how to create a cutscene.

To make it play when the game begins we need to call it at the appropriate time with the CS_LoadCutscene function. The appropriate time has to be after the area that the cutscene is located in as loaded, otherwise the cutscene won't be able to play. The event that's best suited for this is EVENT_TYPE_AREALOAD_SPECIAL, which is called on an area's event script after the area has loaded but before any of the other game systems (AI and so forth) have been enabled. So in this case we want to insert the function call into the area script for the starting area, demo100ar_wilderness. We only want the cutscene to play the first time we enter this area so we've wrapped the function call in a plot flag check;

<pre>
case EVENT_TYPE_AREALOAD_SPECIAL:
{
if (!WR_GetPlotFlag(PLT_DEMO000PL_MAIN, DEMO_INTRO_COMPLETE))
{
CS_LoadCutscene(R"demo100ct_intro.cut");
WR_SetPlotFlag(PLT_DEMO000PL_MAIN, DEMO_INTRO_COMPLETE,TRUE); //sets the plot flag to ensure we don't repeat the intro cutscene.
}
break;
}
</pre>

== The main plot file ==

For this demo module, all of the major events relating to the development of the plot are kept track of in the demo000pl_main plot file. This also allows for a centralized place to put scripting that deals with these events.

The plot outline of the demo module is:

#Player encounters the innkeeper outside his inn and speaks with him, receiving the quest to retrieve the innkeeper's sword.
#Player enters the inn. As he approaches the lever that will open the door to the room the sword is in, the bandit that's taken over the inn initiates conversation with the player. This leads to combat.
#Player pulls the lever, blowing up the door to the room the sword is in
#Player retrieves the sword
#Player returns the sword to the innkeeper, who offers to join the party. A new area also opens up on the world map at this point.

We'll cover each of these events in a separate section of this documentation.

You may also note that many of the constants used in the code have been separated out into a "demo_consts_h" script file, even if they are only currently used in one particular place. This is not strictly necessary, and in fact the toolset doesn't recognize the "_h" suffix as having any special significance; whenever you save an _h script the toolset will try to compile it and complain about the lack of a main() or StartingConditional() function (you can ignore this complaint). However, it makes typos much easier to find and debug, and should you need to change a constant later on this approach ensures that you can always catch every instance of it.

== Giving the player an item ==

The first thing that happens if the player talks to the barkeep and accepts the quest is that the barkeep will give him a key. The key is a "plot item", meaning it will be shown in a separate section of the player's inventory and can't be given away or destroyed by the player, but the mechanism used here can give the player non-plot items as well.

The function UT_AddItemToInventory takes a resource variable as its parameter. It causes a new instance of the item to be created and added. If you call it multiple times with the same resource, earlier copies won't be affected - multiple copies of the item will be created. You'll see one way of removing an object from the player's inventory at the end of the quest when the innkeeper takes back his sword.

== Using a trigger to initiate conversation ==

We want the bandit and his loyal patrons to attack the player before the lever can be pulled. A trigger has been placed in such a manner that the player will have to pass through it before reaching the lever; the trick is now to use that trigger to make the things we want to have happen, happen.

When a trigger is entered by any entity the trigger's event script is sent an EVENT_TYPE_ENTER event. Note that this is sent ''every'' time the trigger is entered, by ''any'' entity, so the first thing we'll need to do in the event script is a test to ensure that the triggering entity is the player or one of his party members.

The IsPartyMember function tests to see whether an object is player-controllable, which is true for the player's character and for any creature currently in the player's party. We call it on the event's creator to check if this is the right person; if it's not the event script does nothing.

If we wanted the bandit and patrons to simply charge and attack the player, we'd have the trigger call UT_TeamGoesHostile(BANDIT_TEAM); directly (the bandit and patrons' creature templates are all set to the same team so that we don't need to set each one hostile individually). In this case an unexplained attack would be strange, so instead a conversation has been set up that has the bandit and patrons explain themselves before attacking. So we've set the trigger script to call UT_Talk instead.

Once this has been called, we never want the trigger to fire again for anyone. It is important to note that setting a trigger to "inactive" will ''not'' work; an inactive trigger still fires EVENT_TYPE_ENTER whenever an entity enters it. There are several approaches that can be used here:

*Set the event script to check the trigger's active status and not perform any action if it's inactive
*Use a plot flag to make the code only fire once
*call Safe_Destroy_Object(OBJECT_SELF, 0); to destroy the trigger entirely

Since there will be no circumstances where we'll need the trigger to become active again in the future, destroying the trigger is the simplest and most foolproof way of accomplishing this.

== Using a placeable to call a script ==

The lever placeable has a "use" option that allows the player to flip it from one state to the other. When this happens an EVENT_TYPE_USE event is sent to the placeable's event script. We've added a custom event script to the lever to intercept this event and do something special; demo200pl_security_lever.nss.

Rather than handling all the details of what should happen when the lever is pulled right in this script, though, we've instead put them into the main plot file's script. The custom placeable script serves only to set the appropriate main plot file flag.

== Troubleshooting ==

=== Failure to exit combat mode after defeating the bandits in the inn ===

Try clearing out the folder My Documents\BioWare\Dragon Age\packages\core\override. As of version 1.0.982.0 of the Dragon Age Toolset, the export process deposits certain files to that override folder, which is currently causing conflicts within the game. One immediate indication of this may be that the player character is initially in their undergarments during character generation.

[[Category:Tutorials]]