Creating Non Player Characters
Any unit that is not a hero can be referred to as a "Non Player Character" (or "NPC" from here on). Examples of NPCs are couriers, summoned units, and wards. There are specific requirements for them that differ from items designed for heroes. Hero items can rely on the pre-existing hierarchy of joints, attachments, effects and selection volumes, and animation. NPCs will need all of those things to be custom tailored around their needs and goals. You can use any of the various models we've already shipped to see examples of how we have authored any of the following below.
Because NPCs are a bit more technical in nature than hero items, each category below has a link to more info on it at the
Source Developer Wiki's Modeling section.
Download the
Donkey Courier model (6.1mb)
Download the
Ward model (675k)
General NPC Requirements
There are many summoned units in the game that can be replaced by an economy item, and the complexity of these can vary. A replacement for Beastmaster's Boar will need attack animations unlike Juggernaut's Healing Ward, but otherwise they share an identical base set of requirements. NPCs looking to pass the submission process will need to meet all of these requirements:
The Skeleton
Every NPC will need at least a root bone to which we not only skin the geometry to, but also use as an anchor for the attachments and hitboxes. Chances are good however that you will need or want to use additional bones, just remember that there is a limit of 52.
Attachment Points
An Attachment is a point with a static position and rotation in relation to a bone in the skeleton. We use attachment points to inform the particle effects how to behave. The names and number of attachments your NPC will depend on what your NPC does. This is the list of attachment points you'll need, and when to use them. These names are specific and case sensitive.
"attach_hitloc"
This attachment is required for every NPC item. "hitloc" stands for "Hit Location" and is used by the particle system to determine where projectile effects should travel to. For creatures or other organic NPCs, the best place for "attach_hitloc" is attached to a bone in the chest area. Placing it in the root, which usually resides in the waist area, results in projectiles traveling low towards the ground and is less appealing. For inorganic models, choose a location that makes the most sense. An "attach_hitloc" should never be placed on the ground.
"attach_attack1"
This attachment is required for NPCs that can attack or cast spells. It is used to determine where projectile effects will be created and launched from, but is also needed for melee units as well. If your unit has a ranged projectile attack, place the attachment where you want the effect to emit from. For melee units, place it in the "hand" the unit attacks with.
"attach_eye_l" and "attach_eye_r"
These attachments are only required for couriers. Use them to mark where on the courier their "eyes" are located. "attach_eye_r" marks the couriers right eye, "eye_l" the left. Make sure that the X axis points in the direction the eye looks.
Get more info at the Source Developer Wiki section on
Attachments.
Hitboxes
Hitboxes are invisible cuboid volumes that are assigned to a bone. In DotA2 they are used for particle effects as well as defining the selection region of a character.
The hitboxes used for effects should encompass an NPCs geometry with a little bit of excess room to spare. If they are too small or just barely fit, then the effects will mostly be hidden from view. The effects hitboxes also need to be split into different hitbox sets that are used by different types of gameplay effects. Different hitbox sets are not created at the exclusion of others. You should have both a default AND head hitbox around the head geometry for example. The names of the sets you will need cannot be changed and are:
default
Default hitboxes are used to represent most of the effects heroes can cast on a unit. Nearly every bone in your NPC should have a "default" hitbox attached to it surrounding the geometry associated with that bone. The only time a bone should not have a default hitbox is if the geometry skinned to that bone can easily be covered by the hitbox of another joint. An example of this can be seen in heroes spines. The bones are small, close together and don't rotate much individually. Thus though there may be 4 of them, we can cover a heroes torso with only 2 hitboxes that still represent the shape formed by the geometry no matter the orientation.
head
The head hitbox should cover the head. However if your NPC has elements of its head geometry that extend far from the main element, for example long horns, you may let these extend outside the head hitbox.
hands
These go around the hands of an NPC and are used for effects related to attack speeds.
feet
These should encompass the feet and are used for effects related to movement speeds.
weapon
If your NPC has a weapon, surround it with a hitbox with this set name.
select_low
This hitbox should be associated with the NPCs root bone. "select_low" refers to a hitbox used for selection with a low fidelity. It is used to determine the area a player can use to select the unit when it is not in close proximity to any other units. This single box should encompass the entire model generously. Roughly by another 1/2 model width all the way around. Be careful with how tall you make it though or it may begin to overlap other models undesirably. It's usually safe to cheat the top of this particular box down a bit from the geometries true height.
select_high
Again all hitboxes in this set should be bound to the NPCs root bone. This time however they are created very tightly to the model, oven just within the main "torso" area. This box(es) should conform to the model right down it's center and are used when 2 units "select_low" boxes overlap. This way when 2 or more units get very close to each other for melee combat, a player can be guaranteed to select the desired unit by clicking in the center of it.
custom
Custom hitboxes are used in the case you would like to create your own unique effect and assign it to an area on your NPC.
Get more info at the Source Developer Wiki section on
Hitboxes.
Animation
NPCs will need at least 1 of each of the following animations. You can do any number of variations for these categories. The list below is of the "activity" names you will need to tag your animation sequences with. The name of the sequence you author can be anything you like; however, it must have the relevant activity name attached to it. The animations are:
ACT_DOTA_SPAWN
Spawn animations are played when an NPC is first created. This animation should be kept short, 30 frames maximum. The reason for this is that if the NPC is given a command immediately afterwards, the animation for that behavior will stomp the spawn. So a 3-second animation of your NPC arising from the ground would likely get cut off immediately.
ACT_DOTA_IDLE
This activity should be assigned to any animation that your NPC will play while it idles, waiting for something to do.
ACT_DOTA_RUN
This activity is for the animation your NPC will use when it moves between 2 locations. The animation should travel forward at a rate of its movement speed every 30 frames. It should then be "motion extracted," along its forward movement axis. See the developer wiki for more information on motion extraction.
ACT_DOTA_DIE
This animation is used when the NPC is killed.
ACT_DOTA_CAPTURE
This is the animation that will play in the portrait frame. Here at Valve, this usually starts as the Idle animation, but often the Idle can move too dramatically for the small portrait frame. So we soften the Idle and then create alternative animations with less activity weight so that they play less often. These shorter alternate animations help break up the feel of the portrait and make it less static.
Depending on the NPC you are replacing, you may also need animations of the following type, labeled as follows:
ACT_DOTA_ATTACK
If your NPC can attack another unit, it will need at least one of these.
ACT_DOTA_CAST_ABILITY_#
If your NPC has active abilities it can cast, you will need to label it with this activity. The "#" should be replaced by the integer of the associated ability. So if you look at the unit in-game, the # is which ability it is, starting with 1 on the left.
You can also choose to add these animations, but they are not required:
ACT_DOTA_IDLE_RARE
This animation(s) will play randomly if your NPC has sat idle with no commands for a while.
Get more info at the Source Developer Wiki section on
$sequence.
Couriers
All of the above applies to the creation of a courier, but couriers have some additional requirements.
First is that they be submitted with both a walking AND flying model. Both models must share the same 512H x 512W texture. The walking courier moves at a speed of 300 units per second. The flying version moves at 350, but can move up to 522 when it is Bursted.
The walking courier's animation is straight forward, however you should animate the flying version as if it was flying on the ground in all but the death animation. This is necessary because the courier is raised off the ground via the code by 160 units. So if you want your unit to crash back to the ground, you should end the death animation with the root of the model -160 units in the vertical axis from where the idle begins.
There's another requirement for flying couriers that crash to the ground on death - you will need to animate the dead flying courier sinking into the ground. Once the courier has crashed and become still on the ground, hold it there for two seconds, then sink it well below the ground over the course of two more seconds. The ground sinking does not happen automatically for flying couriers because some of them fly up into the sky on death.
In order to help keep things organized, please maintain our file structure:
- Model source content resides in \content\dota\models\courier\courier_name\maya\
- Animation source content resides in \content\dota\models\courier\courier_name\maya\animation\
- Exported model content resides in \content\dota\models\courier\courier_name\smd\
- Exported model content resides in \content\dota\models\courier\courier_name\smd\animation\
- Compiled model binaries belong in \game\dota\models\courier\courier_name\
- Material source content resides in \content\dota\materialsrc\models\courier_name\
- Compiled material binaries and .vmt belong in \game\dota\materials\models\courier\courier_name\ and should be named the same as the model
Inside the
courier's zip file you'll find a sample .qc file which should help get you started. There are many comments inside the .qc file (signified by a // at the beginning of a line) which explain it's contents, and you can also check out the Source Developer Wiki documentation on
.qc files for more information.
Wards
You can think of Wards as very simple NPCs. They have a geometry budget of 1500 triangles and need some animation, but not a run animation which is often the most time consuming and difficult.
They do however require multiple skins. One used for the observer ward, and another for the sentry ward. Inside the .qc file you'll find instructions on how to set this up.
In order to help keep things organized, please maintain our file structure:
- Model source content resides in \content\dota\models\items\wards\ward_name\maya\
- Animation source content resides in \content\dota\models\items\wards\ward_name\maya\animation\
- Exported model content resides in \content\dota\models\items\wards\ward_name\smd\
- Exported model content resides in \content\dota\models\items\wards\ward_name\smd\animation\
- Compiled model binaries belong in \game\dota\models\items\wards\ward_name\
- Material source content resides in \content\dota\materialsrc\items\wards\ward_name\
- Compiled material binaries and .vmt belong in \game\dota\materials\models\items\wards\ward_name\ and should be named the same as the model
Inside the
Ward's zip file you'll find a sample .qc file which should help get you started. There are many comments inside the .qc file (signified by a // at the beginning of a line) which explain it's contents, and you can also check out the Source Developer Wiki documentation on
.qc files for more information.