Tracking targets

[Bear]

If an object has been deleted, and you follow a pointer to it, it's not a problem -- unless the object has also been deallocated.  If an object has been deleted, you discover the fact by reading the "deleted" flag in the object.  If it's been deallocated, then you cannot discover the fact; your program will segfault the minute you follow the dangling pointer. This is why you need a reclamation queue and a cooldown period before the record is reused; If you're keeping pointers to records, then unless you can prove that every pointer to a record has been NULL'ed, you don't ever deallocate that record.

I handle it with a hash table, so a reference from one item or creature to another item or creature is always an ID, never a pointer.  So I can check for ID mapped to NULL before I follow a pointer and segfault.  I think this is actually pretty important considering all the places where I can want to have references to items.  It's far easier than keeping track of all the different pointers that might need to be NULL'ed when something is deallocated. 

Basically, I guess there's three choices;

1) one "owning" pointer to an item or creature, probably from the map, and all other places where you need it you have to iterate to find it;

2) one "owning" pointer to an item or creature, from a hash table, and all places where you need it you consult the hash table; or

3) multiple pointers to items and creatures, and you can't deallocate ever unless you can prove that every pointer in every possible place is NULL.  Instead you have to keep the record around in a deleted state and may eventually reuse it subject to the risk of more minor bugs.

[elwin]

I'd have it look around every turn for items worth picking up.

I don't know how it would be possible to travel to a specific target without storing some information about it, because making that evaluation in every turn would make the monster chase between two items, never reaching either one of them.

Always move toward the closest one.

[guest509]

  Go through the decision making process for the NPC every turn. Unless the decision is influenced by a random factor the NPC should be walking toward the item every turn. If something changes in the environment the NPC might change its path, as it should.

[MrMorley]

Why not give every object an "OnDestroyed" event of some description? That way, whatever needs to know about them registers onto that event and they just trigger OnDestroyed.

How you implement that would depend on the language of course. In any Object-orientated language (C++, .net, java) You could have an "IWatchDestruction" interface, or .NET or C++ you could use delegation (boost/std::function for C++, delegate for .NET).

[Krice]

Go through the decision making process for the NPC every turn.

I don't know. I like the idea of selecting a task and then trying to follow it. If the decision making is going to be as complex as planned it's also faster. The changes to target (someone picking it up etc.) are possibly easy to notify with the targetter list.

[roguedjack]

I agree with some advices given here:

1 You should use entity IDs for storing logical relationships between game objects not pointers.

2 The entity initiating the relationship is the one responsible for managing it, not the other way around (eg: AI decides to target an item, so AI is holding the targeted Item ID and will check for the item validity and status).

3 An AI planning over many turns is not as interesting as it sounds. You have to explicitly code reactivity to game state changes or the AI will appear even dumber than a purely stateless reactive AI as the planned AI risks persisting in doing irrevelant actions (eg: AI keep trying to get a far away item while under fire; sounds easy to fix but you will have lots of situations like this to think about and code proper reactions).

There are a lot of benefits in doing 1 and 2 with only the negligible overhead of using a hashtable for ids.

[Krice]

I don't really follow advices. Besides.. isn't pointer a kind of id anyway?

[Ex]

1 You should use entity IDs for storing logical relationships between game objects not pointers.

There are a lot of benefits in doing 1 and 2 with only the negligible overhead of using a hashtable for ids.

There is still overhead for using a hashtable with IDs, whether or not some would consider it negligible. There is zero overhead for using a pointer.

[Bear]

I don't really follow advices. Besides.. isn't pointer a kind of id anyway?

Yes, it is.  It's the kind of ID that can force your program to segfault if you check it after deallocating an object. That's why I want only one  of it per item, and in a single known place where I can keep track of it.  Most places I want object ID's, I want to be able to check them without crashing.

Bear

[roguedjack]

I don't really follow advices.

Why do you ask for other people opinions then?
If you have already make up your mind go ahead then.

Besides.. isn't pointer a kind of id anyway?

Game ID != Memory ID (pointer).

For instance, how will you save to disk shared references to game objects that rely exclusively on pointers?
You have to have an ID on top of that, whether you call it "shared pointer" (smart pointers in boost for instance) or hand-made ID.

[roguedjack]

There is still overhead for using a hashtable with IDs, whether or not some would consider it negligible. There is zero overhead for using a pointer.

If you never share your pointer of course a pointer is the best thing.

[Krice]

Why do you ask for other people opinions then?

I like to know how others do stuff.

You have to have an ID on top of that, whether you call it "shared pointer" (smart pointers in boost for instance) or hand-made ID.

There is an id for each object, but it's mainly for save game and in some places where speed is not important.

[roguedjack]

Allright then.

Your "targeted by" solution is basically the observer pattern :
An object notify another object something has happened to him (eg: the item is taken by someone else).
http://en.wikipedia.org/wiki/Observer_pattern

If you run into pointers problems (eg: item "targeted by list" might hold invalid pointers at some point) and still don't want to use IDs for storing game object references you could consider using smart pointers:
http://en.wikipedia.org/wiki/Smart_pointer
Assuming you program in C++ the Boost library is a good complement to the STL :
http://en.wikipedia.org/wiki/Boost_C%2B%2B_Libraries

[Krice]

I don't use boost or smart pointers. I don't like how vague they are. I like to know what I get. Also, I'm puzzled when someone is talking about patterns. So what if some idea or part of the source code is a "pattern"? They don't own these ideas, whoever they are. I don't even care.

[Bear]

It's okay, Krice; you don't have to care about design patterns. Just do good software design, and your particular set of design patterns will eventually emerge.  Some of these will be the same as some of the patterns named in the "Design Patterns" book (whether you care about the names or not) and others won't be.