When you write a game, you must create objects / enemies / etc. have unique identification numbers?

Question

I recently ran into some problems just passing links to objects / enemies in the game I am making, and I am wondering if I am using the wrong approach.

The main problem I encounter is to destroy enemies and objects when other enemies or players still have references to them.

For example, if you have a Rabbit and a Wolf, the Wolf may have chosen the Rabbit for its purpose. What I do is the wolf has GameObject Target = null; , and when he decides that he is hungry, the target becomes Rabbit. If Rabbit then dies, for example, another wolf killing him, he cannot be removed from the game, because this wolf still has a link to him.

In addition, if you use the untied approach, the rabbit can strike with lightning, reducing its health to zero. When he updates, he realizes that he is dead, and he is removed from the game ... but there is no way to update everything that interests him.

If you provided each enemy with a unique identifier, you could simply use the links to it instead, and also use the central search class that handled it. If the monster is dead, the search class can remove it from its own index, and subsequently everything that tries to access it will be informed that it is dead, and then they can act accordingly.

Any thoughts on this?

Answer 1

One possible approach is for objects to register interest in the object they are tracking. Thus, the tracked entity can dynamically inform the tracking state changes. for example, Wolf registers with Rabbit (which has a list of interested parties), and these parties are notified by Rabbit whenever a state change occurs.

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

This is essentially an observer pattern .

Answer 2

You approach sounds sensibly, why not? Registering all your objects in a hash map should not be too expensive. Then you may have some kind of event bus where objects can be registered for different events.

Other than that, a different approach comes to my mind. You could have a rabbit expose this event directly and a wolf will register on it.

The second approach is attractive for its simplicity, but it will, to some extent, expand the number of event publishers among subscribers. The first approach is technically more complex, but has an advantage for other types of searches.

Answer 3

In practice, I almost never find situations where I will ever need to keep a link or pointer to game objects from other game objects. However, there are a few examples, for example, the example of targeting that you give, and in those situations where unique identification numbers work fine.

I suggest that you could use an observer pattern for such things to make sure links are cleared when necessary, but I think this will get confusing if you need, for example, more than 1 object reference. You can have a target game object, you can have game objects in your current group, you can follow the game object, talk to it, fight it, etc. This probably means that your monitoring object should have a monolithic cleanup function that checks all outgoing objects referenced and resets them.

I personally find it easier to just use the identifier and check the integrity of the object at the point of use, although the price is a bit of the template code to be done and the performance of each search process.

Answer 4

Links work only when the design remains monolithic.

Firstly, passing links to other modules (in particular, scripts) leads to security and technical support problems.

Secondly, if you want to expand an existing object by implementing some kind of behavior and related properties in a new module, you will not have a single link for all cases.