A question about Unit Indexer Systems

[neku99]

I have a question for all the knowledgeable map makers out there:

What are the advantages and disadvantages of using Unit Indexer Systems vs. Making Standalone spells/systems with their own indexing?

I'm trying to decide if I should switch to using and indexer or just make my own standalone systems/spells but I don't know what I'm getting into with using indexers so can someone help me with this?

I also believe answering this could help people with the same thoughts questions.

Thanks in advance!

 

[HappyTauren]

The most important part is onIndex and onDeindex. It is important to have control over what happens when a unit gets deindexed. Unit indexing systems also give you a handy 0-8191 index for units that can be used in arrays, but it is advised not to use it like this, using structs/classes is better anyways.

If you are removing units, or they are dying, you want to have control over what happens when they are no longer in the game. Unit indexing systems usually allow you to add a callback function to be called when a unit is deindexed, in order to remove the instance referring to a now removed unit.

Implementing this on your own for every system would be pointless, making your own event to detect unit being removed from the game would be pointless, and so on.

When you are programming, you want to have a system that does one specific thing, not implement the same thing in 100 different places, it is stupid and hard to debug. If you have a bug in an indexing system, you can solve it in one place and you're good to go, if every one of your spells and systems has its own per-unit indexing system, then you'll eventually have bugs that you cannot fix in one place, that happen in multiple places in multiple lines of code.

This is the same reason why it is better to have one configurable projectile system, instead of each spell implementing its own projectiles, with collision, with triggered movement, with terrain collision, and so on.

You should aim to make all code you have as reusable as possible, without bloating it too much with implementation-specific things. Unit indexers do just this - all they care about is giving an index to a unit when it enters the map, and removing it when it leaves, calling callback functions you assign to both those events. That's its purpose and that's what it does.

 

[neku99]

hmmm I think I understand now. Then it would be more efficient to use an indexer. And the major drawbacks of not using it is the hassle of coding.

I do have a question on deindex though. You say "...you want to have control over what happens when they are no longer in the game" what kind of control would that be?

Thank you for answering really just want to figure things out.

 

[HappyTauren]

Let's say you have a custom inventory system. You have defined which unit types or which units get to have which setup of that inventory system.

So normally, a unit is created. You want it to have this inventory on itself without you coding it explicitly. You do this by detecting when a unit is indexed, then you create an instance of the inventory and associate it with that unit. When the unit is removed from the game, that inventory instance is basically a leak if you do not remove it right away. At this point, you have no way to directly reference it, and it will stay in memory, new units will be created, new inventory instances will be created, and so on, but the upper limit is 8192 and you are bound to reach it sometime because you are creating, but not DESTROYING instances.

Now, if you have a unit indexer system, you can use the onIndex functionality to give the unit the inventory as soon as it enters the map (is created), and destroy the inventory instance as soon as the unit is removed from the map (either explicitly removed, or dies and decays). This makes sure that instances associated with units are removed in a consistent manner.

Spell instances are the same, if you have a spell instance or a custom buff that does something to the unit periodically, you want it to be destroyed when the unit is removed from the map (sometimes as soon as it dies). You can trigger onDeath behavior yourself, but still leave the onDeindex behavior to the indexing system because it knows how to detect unit removal.

If you don't remove this instance, and it periodically does something to the unit, eventually it will start referencing a unit that no longer exists, and you are going to get bugs. With an indexing system, this won't happen as long as you add an onDeindex callback for your system, that destroys the instance(s) associated with the unit that is getting deindexed (removed from the map).

UnitIndexing is a good example of separation of concerns in coding, which is important to make the code clean and easy to debug, as well as make sure that your scripts do what they need to, and not more, as well as make as much code as possible - reusable.

 

[neku99]

This is a goldmine of information. Thanks so much! +rep