Single target spell -> Area of Effect spell. Very efficient Method.

12-27-2003, 08:29 AM

Attached is a map with an AoE banish and an AoE shadowstrike.

The basic method, like all Single Target -> AoE is hidden casters, however instead of constantly recreating the hidden casters a single bunch is created at map start and added to an array, then when a spell is cast each hidden caster is moved to it's target, it's side is switched to the casting unit and it is ordered to use the appropriate spell.

The AoE banish is a 3 level ability, each level the banish duration goes up, this means there are 3 custom banish abilities. All of the abilities are added to all the hidden casters at the start, then the correct one is chosen by disabling all the versions except the one that should be cast, it seems to be a clean efficient method.

The AoE shadow strike is a 3 level ability, each level the radius goes up, but the same ability is used at all levels.

Both spells seem to work very well. The two demo abilities are on different players heroes (shared control) so you can see it works for multiple players, with the same bunch of hidden casters. Hopefully between the two demo spells you'll be able to figure out how to turn any ability into any type of AoE.

If you're confused about what's going on in any of the triggers, feel free to ask for I do use a few tricks and some custom script.
Also this hasn't been stress tested (ie multiple players casting multiple spells at once) so I can give no guarantee how well it will work in that situation.

01-06-2004, 05:05 AM	#2
dataangel	And what happens if multiple units cast AOE shadowstrike at the same time. Ah sheeeite... emote_sweat If you only use one group of casters without creating new ones, they could be in mid cast and get moved. Lots of units simultaneously casting it will screw it up.

01-06-2004, 06:22 AM	#3
Grater	Quite right there. I have two ideas, the first is to use a different group for every player, the second is to use some sort of circular queue system of prehaps a hundred units.

01-06-2004, 06:51 AM	#4
Grater	Circular queue version. If the array size is set large enough it should be able to handle any combination of AoE spells. edit: Some fixes and improved again. For many abilities once set to 0 cooldown, cast time etc they can be "spammed" by just 1 hidden caster as many times as nessecary. The AoE shadowstrike demonstrates that.

01-13-2004, 02:08 PM

Hivemind

Not to downplay what did here but wouldnt it be a more efficient method to have a premade caster for each hero. Assuming you may only have one hero of each type on the map. Each caster would have all the skills needed to cast all the spells of that hero. When the hero is chosen the caster is assigned to that player. This would prevent the dual casting problem and still avoid creating a lot of new units.

If you use multiple copies of the same hero then you could create a caster unit for the hero when chosen. That way you only have to create it once. This is the method we use and it works great. Less lag and no multi-cast problems. Also it is much easier to implement since it doesnt use (and keep track of) massive arrays or queues. Instead it uses a caster unit group to select, move and activate ability for that players caster.

Simplified example:

Pick evey unit in ((Caster) owned by (owner of (casting unit))) and do multiple actions
-Move (picked unit) to location of (casting unit)
-Order (picked unit) to (ThurmonuclearKillerDeathBomb)

01-15-2004, 01:14 AM

Grater

I guess I should explain the situation in which my system is useful.

Many abilities can be chaincast, things like shadowstrike, invisibility, fairyfire, when given no cooldown and added to a unit with no cast animation time can be cast an infinite number of times by the single caster in the same moment. In this case, it is best to use a single caster per player/hero/whatever.

Abilities which cannot be chain cast include:
Chain Lightning & next of kin.
Many AoE skills - they do the correct damage when chaincast, but do not display the effect correctely. (Flamestrike, stomp...)
Any channeled skill by virtue of it's nature.
Actual attacks.

So if the hidden caster is using the above abilities then the benefits of an array based system become readily apparent, my system is merely an optimization over the simplist array systems, in that it shares casters between players and uses a circular queue.

01-15-2004, 10:12 AM

Hivemind

We still think holding them in a unit group would be better. If you need more than one caster per spell you could still use a group of premade casters and share them between players. The casters in the group would be a pool. When a caster is needed you remove it from the pool and give it to the owner of casting unit. Then you give it the skill needed to cast the spell. When the spell is done you remove the ability and put it back in the pool.

Come to think of it you wouldnt even need a unit group. You could just pass it to neutral passive when not in use....

Code:

Event-
Unit casts spell

Conditions-
Ability cast = Dummy Spell

Actions-
For each intiger from 1 to 4 (if number of (units owned by (neutral passive) of type (Caster)) is less than 4 then (create 1 (Caster) for (neutral passive))) else do nothing

Pick 4 random units from (units owned by (neutral passive) of type (Caster)) and do multiple actions
  Change ownership of (picked unit) to (owner of (casting unit))
  Move (picked unit) to location of (casting unit)
  Give (picked unit) (Bomb) skill
  Order (picked unit) to (Thurmonuclearkillerdeathbomb)
  Remove (Bomb) from (picked unit)
  Change ownership of (picked unit) to (neutral Passive)

...Not exact syntax but you should get the basic idea.

With that you would always have enough casters and there would be no problems with two units using the same ability. This would have to be modified to fit the conditions of the spell you use but the basic structure should work fine. A channeling spell would need it to be split into two triggers. One to start the spell and one to end it. You would add conditions as needed depending on the situation you use it in.

The only real difference is that we use ownership to create a pool of casters and you use a array system. We cant think of any advantage for using arrays over what we suggested. Both systems should work and they would both be a improvement over most caster setups people use.

01-15-2004, 10:05 PM

Grater

hmmm you have a point, I got to thinking outside the box and the solution hit me like a message on a piece of paper tied around a brick and thrown through my window.

All it needs is two Unit Groups IdleCasters and BusyCasters

Then two triggers

Code:

Starts Casting
    Events
        Unit - A unit Begins casting an ability
        Unit - A unit Begins channeling an ability
    Conditions
        ((Casting unit) is in IdleCasters) Equal to True
    Actions
        Unit Group - Remove (Casting unit) from IdleCasters
        Unit Group - Add (Casting unit) to BusyCasters

Code:

Stops Casting
    Events
        Unit - A unit Stops casting an ability
        Unit - A unit Finishes casting an ability
    Conditions
        ((Casting unit) is in BusyCasters) Equal to True
    Actions
        Unit Group - Remove (Casting unit) from BusyCasters
        Unit Group - Add (Casting unit) to IdleCasters

Finally, the implementation of a spell looks like this:

Code:

Actions
    Set TempPlayer = (Owner of (Casting unit))
    Custom script:   set bj_wantDestroyGroup=true
    Unit Group - Pick every unit in (Units within 300.00 of (Target point of ability being cast) matching (((Matching unit) belongs to an enemy of TempPlayer) Equal to True)) and do (Actions)
        Loop - Actions
            Custom script:   set udg_TempUnit=FirstOfGroup(udg_IdleCasters)
            Set TempLoc = (Position of (Picked unit))
            Unit - Move TempUnit instantly to TempLoc
            Custom script:   call RemoveLocation(udg_TempLoc)
            Unit - Change ownership of TempUnit to TempPlayer and Retain color
            Unit - Order TempUnit to Orc Far Seer - Chain Lightning (Picked unit)

But in short, whenever you need a caster, you just grab one from idlecasters with "FirstOfGroup" or you can grab a bunch with "Random N units in unit group" and the first two triggers I posted make sure you get a free caster, and if you were serious about using this [and need more functionality] it would be fairly easy to write a function to use instead of FirstOfGroup that will create new hidden casters as required if the idle pool is empty.

PS: I hope you don't really use that example code like it is there because all that counting leaks unit groups like crazy.

01-15-2004, 11:57 PM

Hivemind

Yes thats what we where talking about. Except instead of idle and busy unit groups we just give idle casters to neutral passive. If its owned by neutral passive its idle. If its owned by a player its busy. You might think about posting it that way since it easier to copy into a map if doesnt need unit groups. It would only create problems in maps that make special use of neutral passive. If they are using neutral passive to that degree they probably know enough to be able to modify it to fit their map.

The psudo-code we posted was just to get the general idea across not for actual use. As you pointed out it has no cleanup functions and isnt accurate syntax anyway. It was just easier to understand in psdo-code than explaining the function. We had used the single caster per hero system but we will be switching to this since it allows seamless use of multiple casters.

01-16-2004, 01:19 AM

#10

Grater

Actually your wrong about it being easier to copy without using unit groups, as long as "automatically create unknown variables" is ticked the triggers will seamlessly copy'n'paste into a map and there is less reliance on specific unit types.

There may be very slight performance benefits of using a player (perhaps the "is unit in group" function is slow... but it is native so shouldn't be).

I also much prefers using unit group variables to temporary unit groups "Units owned by NP of type caster" because it avoids a unit group creation (and subsequent deletion), this is true everywhere, counting available units, isEmpty... much less memory leak cleanup code is required with variables.

I think the concept is the important thing and it would be easy enough for anyone making triggered skills to adapt it to Neutral Passive Ownership or Unit Groups as per their preference or needs.

01-16-2004, 02:15 AM

#11

Hivemind

Good point. We forgot about the auto adding of variables.

We notice you dont give ability to the caster then take it away. Does that mean your casters have every ability that could be used? If so does giving a unit a large amount of abilities cause any problems? If it does cause problems then you would have to have a bunch of casters to cover each spell type (or small number of spell types) and then specify which caster type you want for each spell.

01-16-2004, 03:00 AM

#12

Grater

AFAIK adding many abilities to a unit doesn't cause problems, with passive abilities I've added thousands without problem but I havn't tried adding a great many active abilities.

One reason I like pre-adding abilities is so different versions of an ability can be switched between by using enable/disable ability for player, I like using as few function calls as humanly possible - but the add/remove method also has considerable merit.

I think it's very much a case of each for their own - just use whatever your comfortable with because the differences are likely to be negligible.