To follow on with my approach, let's take a look at how it can be used to solve your specific problem.

We need to create a stacking buff. Let's do that real fast. This will allow us to keep track of how many times a buff is stacked up. When you stack a buff, it will reset the unstack timer. The unstack timer will determine how many ticks we will wait before decreasing the stack level. If the stack level reaches zero, we remove the buff. If the stack level reaches max stack level, we simply reset the unstack timer, but don't add any more stacks.



Alright, let's get this show on the road. Let's see how you'd use this to make something usable on-click 5 times before triggering a long cooldown.



That's all there is to it. You've just got to initialize an instance of the two types of buffs/debuffs and add them to the player's buff tracker. From there, the buffs themselves will do the legwork.

Also, in this case, you might want the event to occur on MouseDown/MouseUp rather than on Click if you want to avoid the double-click problem.

also the pseudo code is fine enough haha i do appreciate your honesty though.

Not sure I follow. This isn't pseudo-code. This is a full implementation. I haven't compiled it, but if there's any adjustment needed, it's minor. It's just more simplistic than the actual one that I use.

The one I actually use would probably not be of any help to you, because it has a lot of very advanced patterns that in order to understand, you'd have had to have run into the limitations of this approach first to even start to grasp why I do some of the things I do in my approach.

The patterns I use in my version are the observer pattern and jagged lists for subtype storage.

Basically, I want to be able to have multiple buffs with the same ID, but with a different source entity sometimes not override each other, but rather have a mutual effect. I have to use jagged lists for this if I want to be able to get a copy of all effects with the same ID, but with a different subid.

I make buffs mutually self aware of one another by having them listen for buffs being added, removed, expiring, stacking, unstacking, etc. I do this through the observer pattern.

These patterns actually bloat the code of my version of this by about 400 lines even with the most optimized version I've managed to come up with so far.

I'm not sure I'd name the buff "clicktracker" or "clickcooldown", because those names would apply to all such clickable items. It sounds like this same technique might be needed across multiple clickable items. And if that's the case, I'd go with a different approach.

Definitely not. The names were just for the sake of example.

Actually, our examples are entirely different concepts. Yours seems to be tied to the object itself, while mine is tied to the player themselves. What I'm demonstrating is a concept called "global cooldowns". And given the nature of my approach, I'd argue that mine can do quite a lot of things that yours can't that are common in games, while yours can do a single thing that mine can't --which is incredibly uncommon in games.

I thought I'd take a minute to outline some of these problems:

The global cooldown problem:

In MMORPGs such as WoW, there's a concept called the global cooldown. Basically, this cooldown applies to all abilities, all items, etc. Some abilities trigger the global cooldown, some don't. A global cooldown is usually very short, maybe a half of a second or so, but it prevents you from spamming 5-6 attacks that are all on different cooldowns, and it allows you to implement a one-at-a-time attack setup without having to spend the time developing the code to track when a player is channeling an attack. You just use the existing cooldown system to prevent the player from doing anything until the attack channel time is done.

The shared cooldown problem:

In MMORPGs, some attacks or items share the same cooldown. In your approach, I'm not sure that would be possible. This is to help prevent players from collecting a large number of items that deal direct damage on-use, or swapping their on-use trinkets to stack up bonuses. In my approach, you could prevent the drinking of a small health potion after drinking a large health potion simply by having small and large health potions use the same cooldown id.

Problems with my approach:

The per-instance cooldown problem:

In MMORPGS, nobody ever makes it so that an instance of an item has a separate cooldown from a second instance of the same item type. I suppose if you wanted to make this possible using my approach, you would need to set up some kind of a uniqueid system for item instances that persists between hosted sessions of the world and also avoids overflowing.

The item-swap cooldown problem:

Players can trade items with one another, and since the cooldown is associated with the player, not the item, the item will be immediately usable by the player. This means that you could potentially share trinkets between two or more characters and end up with buffs being applied to the player as though each player had their own version of the trinket. This wouldn't be possible in your approach, but it would be possible in mine. That could be a good thing, or it could be a bad thing depending on how you look at it.

This could be addressed with my approach by keeping track of the buff on the specific item itself, and when the player drops/destroys/trades the item, the buff will be removed but the cooldown will stay with the player. That'd be one way to pull it off.

Another way MMOs handle this, is making it so that any item that has a cooldown is usually soulbound and thus can't be traded.

And finally, you could also get around this problem by just keeping track of the global time of the current cooldown on the item itself, then when the item enters their inventory, apply the cooldown to the item.

Many MMOs also trigger the cooldown of an item when you first equip it without applying the buff, or when you first acquire it, making it so that you have to wait until it expires to use it as well.



Our approaches definitely do different things entirely. I don't care for tying cooldowns to the item itself mainly because cooldown behavior is something that I see being associated to the player rather than the item/skill itself. To me, "not being able to do something" is most often a player concern rather than an item concern. Then there are the design concerns I mentioned with both of our approaches. Overall, I think my approach more closely mirrors useful gameplay mechanics that have been well established in the MMO genre, while your approach solves a single limitation of my approach (one that is not normally represented in the MMO genre), while bricking off some very common mechanics.

Wow this is all a ton of great information. Thanks guys wish I could best response all of it.