• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

StarCraft II Basic Guide to Abilities (Part II)

Level 11
Joined
Jul 20, 2004
Messages
2,760
1. Introduction
In today's tutorial we are going to continue the generic presentation of the main types of abilities and their implementations in StarCraft II. Since this is part II of a series of tutorials, before going any further, I heartily recommend you go through the first part before continuing. If you've already gotten through part I, congratulations! I'm glad to see you're interested in further playing with the Data Editor's capabilities and making new awesome abilities.

The prerequisites remain the same: functional standard Galaxy Editor; I work under version 1.4.2, though the Data Editor doesn't seem to have suffer substantial changes since the game's official release. If you feel you miss some features, it's best you double-check your version. Should the tutorial be outdated (relevant modifications in future official versions of the editor), please contact me so I can perform the necessary updates.

To get started, you can download the initial map I have setup for you to make things a bit easier to implement and test the abilities. And now, arm yourselves with enthusiasm, a cup of your favorite drink (I prefer coffee) and tons of patience. We have a lot of work to do!


2. Boolean Algebra and Validators
Remember that I told you about the importance of validators? Well, unfortunately we cannot go any further at this point before understanding a bit of how they work. There are very many types of validators, and one could argue they are all equally important. However, I would like to draw your attention upon two distinct classes of validators: Combine, and Condition.

But first, let's start with the basics of Boolean algebra. Boolean algebra is practically the universe composed of a set of two values (denoted True & False, 1 & 0, High & Low or any other combination of two distinct elements), and three basic logic operations (and(&,+), or(|,), not(!)). The first two operations can be applied on a set of multiple Boolean values (minimum 2), while the third on one Boolean value alone. They function as follow:
  • AND – result of the operation is true if and only if all the values in the set are true. If at least one value is false, then the operation returns false as well. This kind of operator is useful in situations such as ALL conditions need to be fulfilled in order for the event to occur.
  • OR – result of the operation is false if and only if all the values in the set are false. If at least one value is true, then the operation return true as well. Exemplifying situations are any of the form ANY condition is sufficient to hold true in order for the event to occur.
  • NOT – simply flips a Boolean value – true becomes false, false becomes true. On its own it doesn't do much. It can be combined in expressions with the operators above to obtain powerful results. Imagine an ability that might target anything but certain categories of units (like units with their maximum energy greater than their maximum life, for example). Exclusion is done simply by including the aforementioned category, and then negating it. This is the power and usefulness of NOT for us.

Clarification
While some may argue that AND and OR operators are binary operators (and therefore are applied to a set of two boolean values alone), for the sake of simplicity and connection with Blizzard's Combine validators, we will transform expressions like (A+B+C+D) into a prefixed notation expression like +(A,B,C,D), giving the illusion of the operator applied on the entire set of values. Commutative & associative laws of the groups (B, +) and (B, ∙) enable us to do so.

Let's talk about the Conjunctive Normal Form now. Don't get scared by the freaky name, it's no big deal – really! We simply use it so we can express any condition we want in a very specific way (simplified version here – this is not the CNF itself):
  • +(A1,A2,A3,…,An) – OR on a set of boolean expressions
  • Ai = ∙(Bi1,Bi2,…,Bim) – AND on a set of Boolean values, for each expression A from the set above
  • Bij can either be a direct or a negated condition (depending on the case)

What you need to remember from here is that you can obtain any condition, no matter how complex, simply by thinking of it as making an ANY choice between some ALL subcases. Also note that some Ai expressions may be singular conditions (not composed). Let's take an example so I can better explain to you what I mean.

Example
Let us suppose there is an ability that can affect:
  • Mechanical, flying units (A1)
  • Ground, Organic, Shielded units (A2)
  • Any structures (A3)
  • Any unit type but that of the caster's (ex: Mothership Cloaking Field does not affect other Motherships) (A4)

Some might find this ridiculous, but there will be situations where you will find composite effects useful. It's quite practical to imagine such difficult cases, just to get the hang of the mechanics. In practice you never know what crazy abilities you might end up with.

If you look carefully, you will notice I already did half of the job for you: separating the expressions on which to apply the final OR operator. If we look carefully we can even split them into singular expressions to combine with an AND operator, as follows:
  • A1: Unit is mechanical & Unit is a flying unit.
  • A2: Unit is a ground unit & Unit is organic & Unit's Maximum Shields > 0.
  • A3: Already singular!
  • A4: !Unit is (Caster Type Here) – notice, caster type is a fixed value (predefined, not determined at cast time).

Note
Elementary unit properties can be combined with a single validator via the usage of Unit Filters validators. Simply set as required any non-negated terms, and as excluded all negated terms. Careful though: multiple entries in a unit filter function as if they were under an AND operator.

So how do we actually perform all this mumbo jumbo?, you may ask! The answer is simple: by using the Combine validator of course. A Combine validator functions either as an AND or OR operator (this is actually a property of every combine validator) on a set of sub-validators (that return true if the conditions they are set to test hold on the target object, or false otherwise). A very simple generic solution would be to use an AND Combine validator for each complex term Bi, and finally put all the required validators together via a parent OR validator (using that final validator in place of the condition).

Alternatively, you can use the simplified Condition validator. This simple validator's functionality is as follows: a TEST validator (T) is first run. If T returns true, a THEN validator (A) is run, and its result returned by our Condition validator. Otherwise, the same mechanism is performed but by an ELSE validator (B). In terms of Boolean algebra, this could be described through the simple expression:
V = (T∙A)+(!T∙B).

Warning
Careful how you use this validator! There are situations in which the negated value may not be that which you expect. Suppose you have a validator that checks only for Enemy units. The negated expression returns true for anything that is Not Enemy. Some may be mislead into believing that if it's not enemy, it must be friend; in truth there are also the third-party Neutral units to take into consideration - not to mention sometimes making the distinction between Players' and Allied units is highly important too. Avoid using negated values if you're not clear if you've covered all cases by using them!


3. Selective Target Ability – Psionic Shock (Selective Single-Effect)
attachment.php

Ability Class: Single Target, Selective Effect, Instant

If you've played Warcraft III, you most certainly remember Holy Light. Just like our ability here, it could selectively heal friendly living units, or induce half the amount of damage to undead enemies. Today, however, we play with shields, and with protoss and terran units. Now while making such abilities was awfully annoying to code in Warcraft III, Starcraft II luckily has a very elegant solution. This is the point where we finally start to work with Validators too.

a) Setting up the validators
  • What condition would need to hold true for our ability to be valid? It's pretty simple: either the unit is an enemy protoss, or a friendly terran – neutral units are excluded. If you're still a bit confused after reading the past chapter, here's your chance to get the hang of it.
  • Let's start with the protoss-enemy target. Go to Validators tab. Data – Add Validator.
    - Name: Psionic Shock – I know I have a bad habit of giving every single custom object related to an ability that ability's name (coupled with suffixes). This is a personal approach of keeping things organized. You might choose to give validators a generic name (see suffix name).
    - ID: PsionicShockProtossEnemy
    - Validator Type: Combine
  • Change the properties as follows:
    - Editor: Suffix: (Enemy Protoss)
    - Validator: Type: And – both values need to hold true, simultaneously!
    - Validator: Combines: Search and add the following validators: Is Protoss, EnemyTarget (Unnamed)
  • Now repeat the operation to obtain a Psionic Shock (Friendly Terran) Validator. Note that Friendly Target implicitly excludes Self (meaning the caster cannot target itself with the ability). If you want to modify this behavior, you can always create a duplicate of the Friendly Target Validator, and adapt it as you see fit.
  • Finally create a final combine validator (OR type this time) that combines the two validators created above. This will be the global validator for our ability – any unit for which this validator returns false is not a valid target. In such cases it is indicated to modify the following field too (validators interacting directly with ability objects):
    - Validator: Result – Failure: Can't target that unit.

b) Setting up the effects
  • First the halving shields effect. Go to Effects tab. Data – Add Effect.
    - Name: Psionic Shock
    - ID: PsionicShockHalveShields
    - Effect Type: Damage
  • Properties:
    - Effect: Validators: Psionic Shock (Enemy Protoss) – this effect will affect only the enemy protoss units.
    - Effect: Vital Fraction Current: <Shields: 0.5>
    - Effect: Response Flags: Acquire – this causes units that can attack to respond to the ability. Units that cannot (like High Templars) will not flee (since the Flee flag is not set)
    - Effect: Flags: No Absorb Life – safety measure, to avoid causing any real damage to the unit's life points.
  • Next we move on to adding shields. Setup a behavior that boosts a unit's maximum shields by 50 points, for a duration of 15 seconds (read point 10 – Khaydarin Field- of the previous chapter on how to setup a max vital boosting buff). Once you're done, create an Apply Ability Effect. Here are some of the core properties:
    - Effect: Validators: Psionic Shock (Friendly Terran) – we don't want to add shields to enemy units now, do we?
    - Behavior:Behavior: Psionic Shock (Shields Bonus)
  • Lastly, we setup a Set effect.
    - Effect: Validators: Psionic Shock (Global Target) – the set itself does not discriminate between the two possible types of targets, but it does offer support to the ability in discriminating the correct targets (abilities do not have directly-attached validators).
    - Effect:Effects: Add both Psionic Shock (Halve Shields) and Psionic Shock (Add Shields). Because of the specific branch validators, depending on the type of the target, only one of them will launch (friendly terran and enemy protoss mutually exclude each-other).
    - Target:Target Location Type: Unit – this is very important because it forces the ability to target units alone (not ground).

Note
There is a special type of effect that you can use to substitute the Set Effect in the above solution: Switch Effect. These types of effects work as follows:
- The array of effects from the Set is split into cases (one effect/case) – order is important!
- Every case needs to be validated by a validator.
- The first effect for which the validator returns true is executed.
- If the (Fall Through) value is disabled, the switch effect stops here. Otherwise it continues checking the next effects until it finds one true validator.
- If the effect finishes analyzing all cases and is not locked by any (Fall Through), it is possible to execute a default effect.

Now, the advantage of this solution is that the OR validator is not needed – the exclusion is done by the mechanics of the effect. There is a problem, however, regarding the text message displayed upon an error. If no global validator is setup for the effect and all cases fail (and no default effect is activated), the ability will indeed refuse to run. The catch is that in the absence of a global validator to pass an error message, a simple 'Error' text will be displayed. This can be of course avoided by inserting a dummy global validator (Combine validator with no terms, but correct Error message).

Another advantage is the centralization of the validators. You no longer have to specify individual effect validation independently – all effects are directly validated from the switch. This solution might of course be slightly more efficient too. The affirmation, however, is a mere hunch and remains the subject of experiments.

c) Setting up the ability – I'll leave this up to you. A simple target effect ability linked to the Set ought to do just fine. Use Ability: Target Filters to filter unwanted targets (like dead units, missiles, structures, etc. – you might even consider restricting the ability to affect organic units alone). Keep in mind that the core validation is performed by the validators. Do not limit the ability from targeting enemy or friendly units. Leave both options enabled – once the set is fired, due to the mutual exclusion between the two validators (only one can hold true at a time), the proper effect will be triggered.

Summary
This chapter you have learned how to selectively choose and affect the targets of your abilities through the usage of validators. We have also studied a new case of composite effect, namely the switch.
  • Validators for both types of targets, combined together in a global validator.
  • Ability to allow units to launch the effect.
  • Composite effect that validates the target via the global validator, and triggers the proper effect flow. In the case of the switch, validators restrict the execution of effects. In the case of the set, both branches are triggered, but validators on the branch effects ensure execution only on the right type of targets.
  • Supplementary objects for the actual effects on each branch.

attachment.php

-Set Solution-

attachment.php

-Switch Solution-


4. Channeling Target Ability – Akasha Drain (Channeling Target Unit)
attachment.php

Ability Class: Single Target, Single Effect, Channeling

Channeling effects are tricky, and highly customizable in StarCraft II. Today we are going to mimic the basic behavior of the old Blood Elf "Siphon Mana" ability – Warcraft III players certainly remember it. As it is expected, we will also introduce a new type of effect and take advantage of one of its primary usages.

a) Setting up the ability
Let's start once again with a target effect ability – you've probably gotten so used to it I don't need to give you the basic instructions to how to create it. We will however setup some parameters for it:
- Ability: Cancelable: Channel - this ensures the effect can be cancelled only while channeling. Don't worry! The ability doesn't start executing until the caster is in range with the target!
- Ability: Uninterruptible: Channel – only if you want to lock the caster. If uninterruptible, once channeling starts, it cannot interrupt – it will keep channeling until either the effect stops (at duration or due to involuntary channel breaking), or if the caster dies.
- Ability: Target Filters: Theoretically, Energy Blast valid targets all over again. I also chose to allow it to target Biological units only.
- Stats: Range: 6 – this is the initial casting range of our channeling ability.
- Stats: Range Extra: 3 – from the moment the channeling begins, tells us how much further can the target move without breaking the chain.
- Stats: Flags: The effect will work properly if leaving the standard flags alone, but here are some additional information.
  • Chase – Caster starts following target for as long as it channels. No other action can be executed while chasing, but the channeling ability (it is possible to choose another target to start channeling on it, while still chasing).
  • Best Unit – When you order a group of units to perform the ability, only one of them will respond to the command. Deactivate this flag and observe all your casters responding to the ability command and simultaneously attempting to drain from the target.
  • Transient & Allow Movement – Completely incompatible with channeling abilities (units cannot do anything else while channeling). What's worse, Transient completely disables the functionality of the ability.

b) Developing the channeling effect – Persistent
  • No ability will channel on its own unless a channeling effect is attached to it. For this we will need to make use of Persistent effects. Go to Effects and add a new Effect.
    - Name: Akasha Drain
    - ID: AkashaDrainChannel
    - Effect Type: Create Persistent
  • Predictably enough, now we need to setup the persistent so it works properly.
    - Editor: Suffix: (Channel)
    - Effect: Period Durations: 1 – it is the frequency in seconds with which the drain effect is applied. Think of it as the duration between two cycles of a repetitive buff. Our spell drains mana from the target every second.
    - Effect: Period Count: 6 – The number of cycles to execute. It can be computed as follows: A cycle lasts 1 second, and the spell lasts 6 seconds. Total duration/cycle duration = 6/1 = 6 cycles
    - Effect: Flags: Channeling (this tells the caster to actually channel when he/she casts the ability). If you check Persist Until Destroyed, the effect will ignore the period count field and run until interrupted (of course we want this flag off for our ability).
    - Effect: Periodic Validators: Not Dead – Runs the validator at the beginning of a cycle. If it fails, the channeling is interrupted. Normally you could add a more complex validator here if you want. To reference the unit on which to run the validator (either caster or target, for example), use the Validator: Unit field of the validator. You can make your custom complex validators too if you want (check the sample map for an example of such validator).
    - Effect: Time Scale Source: Normally you would keep this to Global. However, if you choose to play with the Time Scale property of units (like Chrono Boost does), you may choose the caster as reference. That way, if boosted, the caster will drain faster, because for it, one second may mean a real smaller period.
    - Target: Location: Target Unitvery important! Forget to set this field, and you may end up with a spell that targets ground positions instead – frustrating and confusing enough. As I previously mentioned, the linked effects tell Target Effect Abilities what they actually target – unit or point.
  • Don't forget to setup the Effect: Effect field of the ability to point to our effect.

c) Finishing with the Energy Drain Effect
  • Let's go back to Energy Burn. If you remember, we needed a composite effect: one to damage the target based on its energy, and the other one to perform the actual reduction. Today we will do pretty much the same thing.
  • Let's start with the drain effect. Create an effect based off Damage. Setup the following properties:
    - Effect: Vital Bonus: Energy=15 – just like in the case of Energy Burn, we cap the amount of energy to the peak value specified by the ability (if the unit has less, that's fine too).
    - Effect: Leech Fraction: Energy=1 – we want to give 100% of the extracted amount to the caster.
    - Effect: Flags: No Absorb Life, No Absorb Shields, No Absorb Energy – setting these flags ensures that while our effect will leech a vital, it will not deal any actual damage. Keep in mind that leeching does not reduce that particular vital from the target unit too. It just boosts the caster.
  • Next, setup an effect that will reduce the target's energy by 15. You should already be able to do this on your own.
  • Supply the effects to the Persistent via the Effect: Period Effects field – it acts like a Set. Remember to first perform the leeching, and then reduce the amount of energy, just like in the case of Energy Burn.

Summary
This chapter we have learned how to develop a simple channeling spell with a single target unit. We have introduced a new type of effect too and experimented with it a little – Persistent. Here are the objects involved in the solution:
  • Effect Target Ability, properly setup for channeling (Ability: Cancelable, Ability: Interruptible and Range: Extra – fields of particular interest).
  • Persistent Effect for the actual implementation of the channeling mechanism. Also acts as a periodic set effect.
  • Periodic Validator for interrupting the channeling effect (in case the conditions of the environment prevent its continuation).
  • Auxiliary Effects for performing the energy drain – we particularly learned how to drain energy via a Damage Effect without actually damaging the unit.

attachment.php


5. Channeling Area Ability – Gravity Hurricane (Channeling, Multi-Stage, Point Target)
attachment.php

Ability Class: Area of Effect, Multi-Stage, Channeling

While we have already experimented with sets (parallel effects occurring simultaneously as a result to an event) and repetitive effects (buff behaviors, persistent effects etc.), we still cannot execute abilities in stages. While most people must hint that this is the limitation point of the Data Editor – and that it's therefore time to move to a new level and tamper with Triggers -, it is in fact possible to schedule successive effects by using the Data Editor alone.

A solution would be to use buffs, and schedule effects that place new buffs, in chain. However, buffs cannot be related to a channeling behavior and can overload us with the number of objects; we will show how Persistent Effects can override these limitations.

You may have already guessed that this ability is inspired from the Blood Mage's Flame Strike. Flame Strike is indeed a channeling ability – if the casting is interrupted before the gravitational field manifests, the spell interrupts. Once the flames erupt, however, the channeling is complete – hence the multi-stage part.

a) Setting up the ability
  • Since the ability targets an area of effect, we will need to setup an Effect Target Ability. Let's have a look at some of the basic properties:
    - Stats: Range: 6.5 – since the ability targets a fixed ground point, we are only interested in fixed range. Stats: Range Extra should have no effect, unless the caster is moved while channeling.
    - Effect: Cursor Effect: Gravity Hurricane (Area Persist) – search area effect that performs the actual damage. The effect is described at point c).
  • Now before we continue, there are two alternatives that could be used to develop the ability. The first alternative works just like Flame Strike: when the caster begins channeling, both the cooldown and the energy cost fire.
    - Effect: Effect: Gravity Hurricane (Channel Step) – this will be a dummy effect that simply keeps the caster busy. It also ensures that should the channeling not last the whole 2 seconds, the effect breaks. Read point b) for more information on this.

    The following fields need only be modified if you wish for a progress bar to appear over the unit's stats as it channels (similar to Yamato Gun).
    - Stats: Cast Finish Time: 2 – theoretical minimum channeling time. It's also the progress bar's maximum value.
    - UI: Show Progress: Channel – this flag actually toggles the revealing of the progress bar.
    - Ability: Progress Buttons: Set the Channel progress button to that of your Gravity Hurricane ability (if you didn't develop a button for the ability, it's best you do so now). This will display a small icon with a description next to the progress bar. Leaving this field empty displays an empty grey box (which looks really ugly!)
    - Ability: Uninterruptible: Toggle the Channel phase on if you wish to force the caster to channel to the end (forbid voluntary breaking of the channeling). If you wish a close replica to Flame Strike behavior, leave this off.
  • The second alternative uses the same approach as a Battlecruiser's Yamato Gun, to perform the channeling. It will not reduce the energy cost or launch the cooldown before this step is complete, so interrupting comes at no penalty.
    - Effect: Effect: Gravity Hurricane (Field Persist) – point b) covers this effect.

    Just like above, all the following fields are for the progress bar.
    - Stats: Prepare Time: 2 – channeling time.
    - UI: Show Progress: Prepare
    - Ability: Progress Buttons: Set the Prepare channel button.
    - Ability Uninterruptible: Obviously toggle the Prepare phase if you want.

b) Main stages – Persistents again
We will develop three Create Persistent Effects linked in a chain, out of which the first one is used only by the first alternative presented on point a).
  • Gravity Hurricane (Channel Step) – Handles the first part of the ability (actual channeling). There is no periodic effect, but instead at the end of its execution, triggers the second step. Here are the properties:
    - Target: Location: Target Point – Because our ability targets an area, and not a singular unit, it needs to target a point (center of the area).
    - Effect: Period Count: 1 – there is no cyclic behavior so we don't need more than one cycle.
    - Effect: Period Durations: 2 – this actually sets up the duration of the channeling step for the first variant.
    - Effect: Flags: Channeled
    - Effect: Effect – Expire: Gravity Hurricane (Field Persist) – the effect from this field is triggered if and only if the effect successfully channels through the scheduled number of periods. If at any point the channeling is interrupted, the expiration effect will cease to manifest.
  • Gravity Hurricane (Field Persist) – next we need the massive area damage phase. No longer connected via channeling, this effect is scheduled to repetitively damage the units in the area of effect. Upon its completion, the last stage is triggered.
    - Period: Durations: 0.5 – we use this field to setup the damage frequency of the units inside the field. Two times per second gives a good response of the effect, but keep in mind that just like in the case of auras, the larger the number of repetitions per second, the greater the computational overhead.
    - Period: Count: 6 – periods of 0.5 seconds over 3 seconds results in 3/0.5 = 6 periods.
    - Effect: Effect – Expire: Gravity Hurricane (Field Dissipate) – upon the completion of the second phase, trigger the execution of the last.
    - Effect: Period Effects: Gravity Hurricane (Area Persist) – at the end of each damage cycle, runs a search area around the target point to massively damage all targets in range.
  • Gravity Hurricane (Field Dissipate) – effect highly similar to the previous stage. The only difference is that being the end of the chain, no expiration effect is triggered by it.
    - Period: Durations: 0.5 – same as above.
    - Period: Count: 10 – periods of 0.5 seconds over 3 seconds results in 5/0.5 = 10 periods.
    - Effect: Period Effects: Gravity Hurricane (Area Dissipate) – cycles are followed by a search area to lightly damage all targets in range.

c) Finishing touches – a bit of Area Search and Damage
  • Gravity Hurricane (Area Persist) – an obvious Search Area effect. Scans the area around the target point (during the persist phase), selects the proper targets, and launches the damage effect.
    - Search Areas: <Arc: 360>, <Effect: Gravity Hurricane (Damage Persist)>, <Maximum Count: -1>, <Radius: 3> - if you wish to limit the number of targets you can set the maximum count field.
    - Target: Impact Location: Target Point
    - Search: Search Filters: <Excluded: Buried, Dead, Hidden, Invulnerable, Missile> - modify this field to alter the units damaged during the second phase.
  • Gravity Hurricane (Area Dissipate) – just like the effect above, but with a lesser damage amount – therefore a different effect – Gravity Hurricane (Damage Dissipate).
  • Gravity Hurricane (Damage Persist) – performs individual damage on individual units as response to Area Persist. Deals simple spell damage.
    - Combat: Amount: 25 – this is easily obtained from the formula "150 damage points split into 6 cycles = 150/6 = 25".
    - Effect: Flags: Notification
    - Effect: Response Flags: Acquire, Flee
    - Target: Impact Location: Target Unit
  • Gravity Hurricane (Damage Dissipate) – just as above, but with the damage amount modified to 60/10 = 6 points.

Note
For the area selection, please check the solution from Part I, 9c.

Summary
Multistage abilities are not that complicated to develop, though a bit tedious from the point of view of objects. A generic target multistage ability consists of:
  • Effect Target Ability to issue the execution of the spell. In our particular case, the ability is enhanced so it actually powers up for stages 2 and 3.
  • A Persistent Effect for each stage of the ability, linked in a chain – the expiration of a persist triggers the execution of the one following it.
  • Auxiliary Effects for performing the appropriate actions on a stage. In our case, stages 2 and 3 are almost identical: scan units with a Search Area, and then Damage the targeted units.

attachment.php


6. Channeling Aura – Blissful Capacity (Channeling, Aura, Instant)
attachment.php

Ability Class: Instant, Aura, Channeling

Remember tranquility from Warcraft III? Well fear not, now it is back in StarCraft II. It is the perfect example of channeling aura ability: the spell indiscriminately heals friendly units around the caster (aura effect) for as long as the caster keeps channeling (interrupting the spell breaks the aura). Making such an effect using scripts can be in fact less painful than having to develop an aura. We will see in a few moments, however, that it is possible to develop this ability two ways – using an already made aura, or simulating the entire behavior.

Before we continue, however, here are a few supplementary specifications regarding the aura:
- Range: 4 - I target a wide range, so the spell actually covers a circle of diameter 8.
- Regeneration Rate: 0.25 seconds – time interval between two heals.

Solution #1 – simulating the aura
a) Setting up the channel effect – Blissful Capacity (Channel)
  • Create a new Create Persistent Effect that will actually be responsible with the channeling of the aura. Setup the following properties:
    - Effect: Flags: Channeled – it's a channeling effect, so it locks the caster while channeling.
    - Target: Location: Caster Point – the persistent is centered on the position of the caster (all subsequent area searches inherit the location from the persistent).
    - Effect: Period Durations: 0.25 – we want our effect to heal units every 0.25 seconds (this is the actual healing rate of the spell).
    - Effect: Period Count: 60 – computed as 15 seconds duration/0.25 period duration = 60 periods.
    - Effect: Period Effects: Blissful Capacity (Area Search) – the healing is performed via repetitive area searches.
b) Setting up the healing effect
  • We start with a Search Area Effect that detects the units to heal – Blissful Capacity (Area Search)
    - Search: Areas: <Arc, 360>, <Effect, Blissful Capacity (Heal)>, <Radius, 4>
    - Search: Search Filters: <Exclude: Dead, Destructible, Hidden, Invulnerable, Item, Missile, Statis>, <Required: Biological, Visible>, <Factions: Ally, Player>
  • Now we complete the effect by setting up the healing, a simple Modify Unit EffectBlissful Capacity (Heal)
    - Effect: Vitals: <Life, Change = 1.25> - computed as 5 points/second x 0.25 seconds/cycle = 1.25 points/cycle

Notes about this solution
  • This solution works with the effect channeling alone. There is no way to let the unit do anything else while the effect is still in place (temporary aura).
  • Multiple auras stack. While deactivating stacking can be done, it is rather tricky. The actual aura approach is more much suitable if you wish to deactivate stacking.
  • To actually display an aura buff on the target, a dummy buff must be temporarily applied on the target.


Solution #2 – using an aura
a) Setting up the aura – follow steps from Part I, chapter 11 (Energy Rift). Here are some guidelines to help you setup the aura:
  • Blissful Capacity (Caster) Behavior – do not implement this. Because our aura is not passive, the area search will not be triggered by a permanent buff!
  • Blissful Capacity (Area Search) Effect – you can adapt the one from Solution #1 (read above), but it needs to trigger the Apply Effect instead of the Heal.
  • Blissful Capacity (Apply) Effect – use it to apply the behavior on the target. Remember it needs to have Extend flag set with no duration bonus, and a period of 0.25 seconds (regeneration period). For my implementation I also assume a duration of 0.3 seconds.
  • Blissful Capacity (Target) Buff – handles the repetitive triggering of the Heal Effect.
  • Blissful Capacity (Heal) Effect – you may use the effect from the solution above.

b) Triggering the aura – Blissful Capacity (Caster) Effect
  • We need an effect that triggers the periodic presence of the aura. As you might've expected, we need a Create Persist Effect that performs both the channeling and takes the place of the aura buff on the caster. So go ahead and create a new Create Persist effect so we may link it to the aura.
    - Effect: Period Durations: 0.2 – refresh rate of the aura. Doesn't affect the regeneration rate anymore.
    - Effect: Period Count: 75 – computed as 15 seconds duration/0.20 period duration = 75 periods.
    - Effect: Period Effects: Blissful Capacity (Area Search) – to refresh the aura for units around the caster. Takes the role of the passive buff on the caster.
    - Effect: Flags: Channeled – it's a channeling effect, so it locks the caster while channeling.
    - Target: Location: Caster Unit – the persistent is centered on caster (if the caster could hypothetically move, the persist would 'follow').

Notes about this solution
  • This solution, though more complex, is much more adaptable. The aura can be not only channeled, but also activated like a temporary aura (Guardian Shield – like).
  • The stacking of multiple auras can be tuned via the target buff.

Common Objects
a) Setting up the ability
  • Since our spell has no target (point or unit), it's time we finally get our hands on those Effect – Instant abilities. So go ahead and create one, setup the button, costs, cooldown, and all that shiz. Lastly, don't forget to link its Effect: Effect field to the persist (depending on the solution of your choice). Might also be best to toggle the Best Unit Flag on, in order to avoid multiple selected units from channeling all simultaneously.


attachment.php

-Version 1-

attachment.php

-Version 2-


7. Toggle Ability – Telekinesis (Toggle, Cost-Free, Static Buff)
attachment.php

Ability Class: Toggle, Single-Effect, Cost-Free

Moving towards a new range of abilities, we begin to analyze the potential offered by Toggle abilities. The simplest scenario is inspired from Warcraft III's Defend with a small validating condition to prepare us for more complex versions. Like we've already gotten ourselves used to, there are two version to every spell. I will present the shortcut (which from what I can tell at this point, works like a charm), followed by the longer (yet more flexible) alternative.

Version #1
a) Setting up the ability
  • Create a new Behavior AbilityTelekinesis
    Behavior abilities toggle a behavior on the caster. They seem to be particularly designed for toggle abilities, as they present a two-state behavior and link the current state to the presence or absence of the behavior. Should the behavior disappear for some reason, the ability shall be deactivated too.
  • Before setting up the properties, make two buttons (one for the On state, and one for the Off).
    - Ability: Commands: <Turn On, Default Button: Telekinesis (On)>, <Turn Off, Default Button: Disable Telekinesis> - this part actually connects the correct buttons to the corresponding state of the toggle ability (on/off).
    - Ability: Behaviors: Telekinesis – here you can link the ability to the designated behavior. Read below for actually setting up that behavior.
    - Stats: Flags: Transient (so that the ability can be activated without interrupting whatever order the unit might have been executing in the meantime – like moving, attacking, channeling etc.), Toggle (without it, there is no off state for the ability – the button simply disappears until the behavior disappears). Toggled On toggles the ability on by default when the unit is created. Best Unit functions like in the case of standard abilities (if set, disables groups of units from activating the ability simultaneously).

Note
Be careful when adding the buttons to the unit's command card! You will need to add the on and off buttons separately (I prefer to usually put them on the same position – old Warcraft III style). Both will be linked to the same ability (Telekinesis), but a different Ability Command.

b) Behavior time
  • Create a new Buff Behavior which we will use to modify all necessary stats of the affected unit.
    - Behavior: Alignment: Positive
    - UI: Display Shield: Self, Ally – you can use this flag to allow only certain players to see the buff on the UI. In our case, I chose to allow only friendly players to be aware of the buff.
    - Stats: Duration: -1.00 – unless you plan on deactivating your toggle ability automatically after a while, always set the duration of the buff to infinity (-1), so that the player may choose when to deactivate it.
    - Behavior: Modifications: Movement – Movement Speed Multiplier: 0.6 – this reduces to movement speed of the unit to 60% (reduction by 40%).
    - Combat: Damage Response: <Chance: 1> (every time unit is attacked), <Modify Fraction: 0.5> (only 50% damage dealt – reduction by 50%), <Maximum: 19.9997> (activates only for damage less than 20 points).
    - Behavior: Validator (Remove): Telekinesis (Caster Life) – again, read below for the implementation. Always use a remove validator for situations that would deactivate the toggle ability. Disabling the behavior does not remove it, and therefore keeps the toggle state on. Remember, the behavior is removed if the validator returns false!

c) Validator – create a new Unit Compare Vital Validator.
- Validator: Compare: Greater Than Or Equal To (returns false for less than value).
- Validator Type: Fraction – vital computed is fraction of current out of maximum amount.
- Validator Value: 0.25 (or 25%)

Version #2
a) Setting up the effects – we need two distinct effects, one for activating and one for deactivating the behavior.
  • Create an Apply Behavior Effect for turning on the ability – Telekinesis (Enable)
    - Behavior: Behavior: Telekinesis (use behavior implemented at Version #1)
  • Create a Remove Behavior Effect for turning off the ability – Telekinesis (Disable)
    - Behavior: Behavior: Telekinesis (just like above)

b) Setting up the requirements – next we need two separate requirements for each state. Requirements are special objects used (at least by us now) to condition the visibility of a button on a unit's Command Card. Without the attached button, it is impossible to give the command of activating the designated ability.
  • Create a new RequirementTelekinesis (On).
    - Edit Categories: Tech Type – Ability
    - Requirement: Check the Expression radio button at the top of the window. Modify the Show expression like this:
    JASS:
    CountBehavior(Telekinesis,InProgressOrBetterAtUnit) == 0
    (Telekinesis is the ID of the Telekinesis behavior – modify it if necessary)
  • Create a similar Requirement – Telekinesis (Off). The only difference is the Show script:
    JASS:
    CountBehavior(Telekinesis,InProgressOrBetterAtUnit) > 0

Further explaining
The scripts check for the presence, or absence, of the behavior on the unit. The two expressions are mutually exclusive (only one available at a time), which means that only state is visible at a time (either On, or Off, but not both!).

c) Setting up the abilities – setup two Instant Effect abilities, one for the on state, the other one for off. I will present only the first, the second one being highly similar (simply replace the Effect and Requirement with the other one we just made).
- Effect: Effect: Telekinesis (Enable) – to add the behavior on the caster.
- Stats: Flags: Transient – same use as in version #1 of the ability.
- Ability Commands: <Execute: Default Button – Telekinesis (On), Requirement: Telekinesis (On)> - this links the ability to the on button, and the on requirement (behavior absent on the unit).

Now add both abilities and buttons to the unit and you're done. If you wish to obtain a non-toggle behavior (like in solution #1), only create the first branch (turning on the behavior). Once the behavior is active on the unit, the requirement of the ability fails, and will be removed from the unit's command card.

attachment.php

-Version 1-

attachment.php

-Version 2-


8. Toggle Ability – Psionic Lash (Toggle, Energy Cost, Dynamic Buff)
attachment.php

Ability Class: Toggle, Periodic Effect, Energy Cost

Let's change our development direction towards yet another ability inspired from Warcraft III, more specifically Immolation. We add a small twist, and allow the caster to drain 25% of the damage dealt. We will see that on the long run this makes little difference. For our solution we will choose Version 2 of toggle abilities, though it is possible to apply version 2 too.

a) Setting up the effects
  • Create a new Search Area Effect that searches the units around the caster on which to perform the drain. Watch out for the range and the flags. Should trigger the execution of the Damage Effect (detailed next) for each valid target.
  • Create a new Damage Effect to deal damage and drain some of the life points. I have tweaked the effect of the spell such that it affects only the life of the units (penetrates shields). For the same reason, I chose not to let the effect kill any units (you may tweak the flags to let it perform normal damage – first lower shields, then life points, or even give shielded units complete immunity).
    - Effect: Vital Bonus: <Life, 4> - this is essential, because it scales the drain to the current life of the unit. Should the unit have only 2 life points left, the drain percentage (25%) is applied to that amount.
    - Effect: Leech Fraction: <Life, 0.25> - transforms 25% of the dealt damage into life for the caster.
    - Effect: Flags: Live (cannot deal fatal damage), No Absorb Shields (penetrates shields when dealing damage).

b) Setting up the behavior
  • Create a new Buff Behavior to toggle on the caster – Psionic Lash (Caster)
    - Stats: Duration: -1.0 – just like last time, the effect is not temporary.
    - Stats: Period: 0.5 – period to perform periodic effect (aura-like). Same restrictions as for auras apply (period too small = higher computation, but smoother damage reduction).
    - Effect: Effect Periodic: Psionic Lash (Area Search)
    - Behavior: Validators (Remove): Has Energy (Current Energy > 0), Can Spend Energy (does not have energy usage disabled) – both standard for any energy-consuming toggle abilities.
    - Behavior: Modifications: Unit – Vital Regeneration Bonus: <Energy, -4> - drains 4 points of energy each turn, simulating the energy consumption of the toggle ability.

c) Setting up the ability – just like last chapter, create a behavior ability, link the on and off buttons to the commands, and set the behavior to the one created above. Do not forget to turn on both the Transient and the Toggle flags.

Summary
We have developed a toggle ability with an energy cost both initial and over time. The objects generally involved when developing such an ability are:
  • Behavior Toggle Ability – contains the toggle mechanism and connects a behavior (buff) to the ability. Also contains the initial energy cost.
  • Caster Behavior – directly connected to the toggle ability. Handles both static and periodic effects. Is responsible for shutting down the ability in the absence of a validating condition. Also implements the 'energy drain over time' mechanism.
  • Area Search & Drain Life Effects – perform the actual effects of the ability (periodically triggered by the buff). Search in an area for valid units, and transfer a portion of their life to the caster.

attachment.php


9. Conclusions
Today's abilities were a bit more complex than last time; you can probably grasp by now the basic mechanics of the editor's objects and how powerful it can be. For those of you who are still taken aback by the time necessary to develop all these abilities, I tell you one thing: practicing with the data editor will greatly reduce the amount of time spent on developing a more complex ability. The examples here are meant to help you understand how the various objects in the data editor work – what is their purpose, how can one use them, how do they interact with one another, etc.

Next time we will continue with new classes of abilities and mechanics. Once again, if you have any suggestions, questions or concerns regarding the tutorials, feel free to contact me and I will do my best to take your message into proper consideration.

Have fun developing awesome abilities!
 

Attachments

  • AkashaDrain.jpg
    AkashaDrain.jpg
    10.4 KB · Views: 2,432
  • BlissfulCapacity(Version 1).jpg
    BlissfulCapacity(Version 1).jpg
    11.9 KB · Views: 2,436
  • BlissfulCapacity(Version 2).jpg
    BlissfulCapacity(Version 2).jpg
    17.1 KB · Views: 2,362
  • GravityHurricane.jpg
    GravityHurricane.jpg
    25.9 KB · Views: 2,479
  • PsionicLash.jpg
    PsionicLash.jpg
    14.2 KB · Views: 2,518
  • PsionicShock (Set Case).jpg
    PsionicShock (Set Case).jpg
    20 KB · Views: 2,456
  • PsionicShock (Switch Case).jpg
    PsionicShock (Switch Case).jpg
    17.5 KB · Views: 2,448
  • Telekinesis (Version 1).jpg
    Telekinesis (Version 1).jpg
    12.9 KB · Views: 2,392
  • Telekinesis (Version 2).jpg
    Telekinesis (Version 2).jpg
    18.8 KB · Views: 2,640
  • AkashaDrainScreenshot.jpg
    AkashaDrainScreenshot.jpg
    25.2 KB · Views: 2,386
  • BlissfulCapacityScreenshot.jpg
    BlissfulCapacityScreenshot.jpg
    25.1 KB · Views: 2,384
  • GravityHurricaneScreenshot.jpg
    GravityHurricaneScreenshot.jpg
    34.3 KB · Views: 2,363
  • PsionicLashScreenshot.jpg
    PsionicLashScreenshot.jpg
    26.4 KB · Views: 2,356
  • PsionicShockScreenshot.jpg
    PsionicShockScreenshot.jpg
    30.9 KB · Views: 2,429
  • TelekinesisScreenshot.jpg
    TelekinesisScreenshot.jpg
    30.9 KB · Views: 2,341
  • (Daelin) StarCraft II Basic Guide to Abilities - Final Map (Part II).SC2Map
    30.8 KB · Views: 213
  • (Daelin) StarCraft II Basic Guide to Abilities - Initial Map (Part II).SC2Map
    22 KB · Views: 184
Top