When writing a game, should you make objects/enemies/etc. have unique ID numbers?

I have recently encountered some issues with merely passing references to objects/enemies in a game I am making, and am wondering if I am using the wrong approach.

The main issue I have is disposing of enemies and objects, when other enemies or players may still have links to them.

For example, if you have a Rabbit, and a Wolf, the Wolf may have selected the Rabbit to be its targe开发者_JAVA技巧t. What I am doing, is the wolf has a GameObject Target = null; and when it decides it is hungry, the Target becomes the Rabbit. If the Rabbit then dies, such as another wolf killing it, it cannot be removed from the game properly because this wolf still has a reference to it.

In addition, if you are using a decoupled approach, the rabbit could hit by lightning, reducing its health to below zero. When it next updates itself, it realises it has died, and is removed from the game... but there is no way to update everything that is interested in it.

If you gave every enemy a unique ID, you could simply use references to that instead, and use a central lookup class that handled it. If the monster died, the lookup class could remove it from its own index, and subsequently anything trying to access it would be informed that it's dead, and then they could act accordingly.

Any thoughts on this?

---

One possible approach is to have objects register an interest with the object they're tracking. So the tracked object can inform the trackers of state changes dynamically. e.g. the Wolf registers with the Rabbit (that has a list of interested parties), and those parties are notified by the Rabbit whenever there's a state change.

This approach means that each object knows about its clients and that state is directly tied to that object (and not in some third-party manager class).

This is essentially the Observer pattern.

---

You approach sounds reasonable, why not? Registering all your objects in a hashmap shouldn't be too expensive. You could then have sort of an event bus where objects could register for different events.

Other than that, there is another approach coming to my mind. You could have the rabbit expose the event directly and have the wolf register on it.

The second approach is appealing for it's simplicity, however it will to some extend couple the event publishers to the subscribers. The first approach is technically more complex but has the benefit of allowing other kind of lookups too.

---

In practice I hardly ever find situations where I ever need to hold a reference or pointer to game objects from other game objects. There are a few however, such as the targeting example you give, and in those situations that's where unique ID numbers work great.

I suppose you could use the observer pattern for such things to ensure that references get cleared when necessary, but I think that will start to get messy if you need more than 1 reference per object, for example. You might have a target gameobject, you might have gameobjects in your current group, you might be following a gameobject, talking to one, fighting one, etc. This probably means your observing object needs to have a monolithic clean-up function that checks all the outgoing object references and resets them.

I personally think it's easier just to use an ID and validate the object's continued existence at the point of use, although the price is a bit of boilerplate code to do that and the performance cost of the lookup each time.

---

References only work while design stays monolithic.

First, passing references to other modules (notably, scripting) leads to security and technical problems.

Second, if you want to extend existing object by implementing some behavior and related properties in a new module - you won't have a single reference for all occasions.