3. Designing your first Item

Creating an item is easier than creating a tower, because you need no model. Many steps are similiar to those of towers. For each similiar step, only a link to the corresponding chapter about towers will be given.

First set up your development environment, just like for towers: Setting up your developement environment.
The only difference is that, instead of opening the tower template, open "YouTD_ItemTemplate <VERSION>.w3x" in your DevKit's YouTD folder.

If you have already created a tower, creating an item will be very easy. However, note that items should not be created in whole families. Create only single items. Of course, especially for common items with very common abilities, you can make different versions of your items (then you can also use the same icon), but they won't be linked as a family but treated as own items.

Note that most items should be unique, there is no need for many versions. Only for very common effects, you can make some versions (up to 4) of one item. However, since items are distributed randomly, there is no reason why an item should be available in many different strength levels.

Like for towers, you see your item in the middle of the map. Enter the object editor, here you will find one custom item named "YOUR ITEM". This is, surprisingly, your item. Note that you are not allowed to change most values for your item in the object editor (they will just get ignored by the script). The only values you can and should change are:

  • Name: The name of your item
  • Tooltip - Extended (Ubertip): The flavortext or short description of your item. Either insert one or two sentences to shortly describe your item's effects (no numbers) or add some story information about it. Remember that also the ability descriptbion of your item's effects will be in the item's description, so there is no need to precisely explain its effects here.
  • Interface Icon (Art):The icon for your model, if you design more versions with different strength, you can use the same icon for all.
  • Abilities (abilList):Abilities of your item. NOTE: For almost all effects, you should use the engine and thus event triggers or the modification table. Only things that are not doable with the engine should be hardcoded as abilities. However, it then has to be checked if those abilities are compatible to the engine. So remember:Use raw abilities only if no other solutions exist and prepare that your item gets declined if your abilities are not compatible with the engine. Note that all limitations and rules from the chapter Adding abilities to your tower are also used for item abilities.

Of course there may be items with very special triggered abilities. However, many items will just alter a tower's statistics (for example grant bonus damage).

There is a trigger comparable to the modification table for towers in the category "YOUR ITEM CONFIG" called Modification Table. These are modifications that will be applied to a tower wielding this item. Check the corresponding tower chapter, it is exactly done like there (only some available values differ from the modification table for towers).

First, read these chapters for towers, items are similiar:
Triggering stuff for your tower
Reacting to events
Tooltips for event reactions

There are some small differences to towers:
Items have some other effects they can react to (onItemCreation,onItemPickup,...). However, their names should be enough to explain what they do.

Next, the event reaction functions do not take a variable of type Tower but a variable of type Item (of course).
Here is the item struct:

strut Item //Real numbers attached to this item that you can use for whatever you want. //Note that their values are undefined until you define them real userReal real userReal2 real userReal3 //Integer numbers attached to this item that you can use for whatever you want. //Note that their values are undefined until you define them //You can also easily save other stuff like Units, Dummies, Buffs,... in these values //since they can be casted to integer and back without any effort integer userInt integer userInt2 integer userInt3 //The unit carrying this item (or 0 if it is not carried by a valid unit at the moment) method getCarrier takes nothing returns Unit //Gets you the type of this item method getItemType takes nothing returns ItemType //Gets the item that is wrapped by this Item method getItem takes nothing returns item //Gets the Playor that owns this item method getOwner takes nothing returns Playor //Gets the charges remaining on this item //If this function returns 0 this item either has 0 or an infinite amount of charges method getCharges takes nothing returns integer //Sets the charges remaining on this item //If you insert 0, the item will have an infinite number of charges method setCharges takes integer num returns nothing

So as you see, you have userReals and ints like for your towers to store values for your triggers. The most important function is the getCarrier function that returns the unit (tower) carrying the item and the getOwner function that gets the owner of this item.

So basically, you do the same stuff you would do for towers, but you have to get the tower by calling getCarrier.

Note that items cannot have more than one autocast, because autocasting an item means using it and there is no way to use an item in two ways.

Just like for towers, you can use the balance constants table also for items.

The final difference to towers is that all triggers have a "@goldcost=" value in their trigger comment. This value is used to balance the item. More about that in the next chapter.

Towers are balanced by setting their abil_factor that alters their damage. Items cannot be balanced in this way since they deal no combat damage.
Items in contrast are balanced by setting balancing their goldcost. Note that "goldcost" is a misleading term since items cannot be bought or sold. That goldcost is just a measure for the items strength. The more goldcost an item has, the stronger it is and thus it will appear only at later levels.

Good news first: The values you modify in the modification table are balanced automatically, i.e. their goldcost is calculated by the script. So you must only set goldcosts for your triggered stuff. This is done by setting the "@goldcost=" for your used triggers to the gold value that they should cost.

This is done by estimating how much gold the triggered ability is worth. I.e. how much would a tower cost that only has this ability and abil_factor 0.0, i.e. that puts its whole strength into its ability. For example, a spell that deals around 100 dps should cost, according to the tower balance 1dps/gold formula, 100 gold.

For other abilities just imagine (or check towers in the webscript) towers with similiar abilities. For example, a +30% damage aura would be placed in a 2500 gold tower with a 0.6 abil factor, so the ability was worth 0.4*2500 = 1000 gold.
The script will display which goldcost and level an item has.

Note that the goldcost you enter for your item in the object editor is ignored, only the goldcosts of the triggers count.

If an ability uses more triggers, you should accumulate its goldcost in one trigger and set the other trigger's goldcost to 0.

Note that the max price for common items is 1100 gold which equals an item that will drop around level 80. The more rare an item is (the same rarity grades as for towers exist), the more gold it may cost. Unique items may cost up to around 2700 gold. If your item is to expensive, the export script will throw an error. Note that the goldcost can raise quickly when using some modification table values that are very strong.

Basically, you have to do the same as for towers. Insert values in the settings trigger (rarity, author,...) and save your item.

Then do the same things as you would do for a tower (Exporting your tower and testing it). However, you don't have to provide a screenshot of course.
Once you have parsed your item with GMSI, a testmap will be created where you can build some different test towers which you can hand your item to test its effects