Thread: ABuff System
View Single Post
Old 07-20-2007, 12:20 AM   #7
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,190

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Quote:
Originally Posted by rain9441
How practical is this on heavy action maps? Can it support 50 units with multiple buffs/debuffs, 100? 500?
I can't give you a direct answer to that. It always depends on what you do with the system and what else is going on in the map. When it comes to more trigger/sfx heavy spells, the system is not the critical component anyway; when the game starts lagging, it's because of the spells, not the system. If you have simpler spells, but a lot more of them, then the system plays a bigger role, but still, to geta lot of buffs you need a lot of units so the graphics and pathing are contributing to lag as much as the system.

You can always turn off some events to increase performance. Turning them all off would limit what you can do with buffs considerably, but turning one or two off would still leave you with enough creative space to make enough buff spells for one map. For example, the map I designed this system for will most likely not use the "other buff" and damage events. (speaking of which, I just noticed that I forgot to add an if statement in there somewhere, so turning off damage detection doesn't stop on damage triggers from being created... it's not critical, I'll fix it later :) )

Consider it like this: most events require two gamecache lookups and then a bit of array access, how much depends on the number of buffs the units involved in the event have but it's not an issue either way, it's just looking up global variables and comparing stuff. Now, if the system finds a buff that has a response function to the event, it takes one more .evaluate to run it and of course whatever the user wrote in that function. Except on common events like attack and damage with a lot of units with fast attack speeds (and probably not even then unless we're talking excessive amount of attacks), the system alone handling a bunch of blank buffs shouldn't be a problem.

Quote:
Is it feasible to use this system with auras? Example: TriggerRegisterUnitInRange on a unit with an action of ABuffApply with duration 0, where the ABuff has a periodic event to check the range of the target with the caster.
I didn't make an aura template because I thought it was impractical but the way you described it's implementation it sounds rather feasible. You could even have a seperate custom periodic event (by enumerating buffs by type) that only runs only once or twice per second to lower the load (or lower the frequency of the default periodic event if no other buff requires it to be smoother), but it might not be neccessary at all, IsUnitInRange() is a native, and getting the two units is trivial. I think I will write that aura template for the next version. :)

Quote:
Whats the bottleneck of the system? I can easily change the implementation of GetUnitABuffData to use Get/SetUnitUserData, would this increase performance (by drastically reducing gamecache usage)?
Gamecache calls seem like a bottleneck considering how slow they are together with H2I but they are only used twice for each event to get the unit's data and then it's looping through linked lists of buffs. Now, if you have many events occuring, but only few units involved in them have buffs or most buffs don't respond to frequent events, then GC calls may have a considerable contribution compared to the rest of the code, but that's because there is almost no "rest of the code". Otherwise, not really.

That's why I decided to go with game cache, I don't need to use much of it so it's not that heavy, but the system is a lot more import friendly as it doesn't conflict with any other system that would use unit custom values. If you change the implementation, however, note that you need to alter GetUnitABuffData(), IsUnitAllocated() and the create and destroy methods of the aBuffUnit struct. I think that's it.

Quote:
Any tips for implementing ABuff's with some sort of Orb Effect Detection engine?
Nope. What specificaly did you have in mind?

Quote:
And regarding your mini Stun System, does it interact well with other non-ABuff related stuns?
If you use the stun system, you should do all your stunning through it. It might not conflict if you use different buffs though.

Quote:
Whats the A stand for?
Rising_Dusk is correct, I afforded myself a moment of vanity when trying to think of a name. I was really out of ideas so it was either ABuff or no buff (I couldn't really start coding if I didn't know how to name the most basic structs :) ).

Quote:
Originally Posted by Ammorth
Nice system, although (correct me if I'm wrong) but it seems that the stunning unit shows it's health bar. Otherwise awesome job!
Not sure what you mean, but dummy stunners have the locust ability so I choose to blame Blizzard (either that, or your sight :P ).

As for the "Just another WarCraft III map", it shows how eager I was to get this out after a month of coding followed by a month of no computer (when I was finishing it up today I realised I should really comment my code more :) ). It's not that important, all the documentation is in the map anyway. I'll fix it with the next version.
__________________
Anitarf is offline   Reply With Quote