Archived

This topic is now archived and is closed to further replies.

Krylloan

Cleaning up.

Recommended Posts

I''m interested in how other people deal with the problem of multiply-linked transient game objects dying. ie: If an AI has a target player who is suddenly dropped from the game, how does the AI find out? (I''m using linked-lists to store all entities in my game) The current method I''m thinking of is a linked-list of pointers:
  
struct link {
    link *prev, *next;
    void *target;
    // possibly

    void (*callback)();
}

struct entity {
    linked_list_stuff blah;
    other_stuff blah2;

    link *head, *tail;
}

struct craft : entity {
    craft_stuff blah3;

    link target_player;
}
  
Where each object has a link-head and a link-tail. When the object dies, it moves through the linked-list of links and sets their target to NULL. (And possibly calls their callback) (I''m currently using a minimal subset of C++ - inheritance only) For game design reasons, I don''t want to use a GC. Does anyone have any other methods? Thanks Simon

Share this post


Link to post
Share on other sites
my advice would be to ditch the linked lists, first of all. They are incredibly slow in real-time applications like games.


as for finding out if an object has "died", you should probably have your entities have a boolean "isDead", and whenever it disconnects, it is set to true. You could have a cleanup system that cleans up all the dead guys after it is sure that everyone is notified.

Probably the easiest way would be to to have the AI check to see if its target is still alive every frame. While this seems to be a slow method at first, in reality it doesn''t consume much power in comparison to a lot of other things.

having links all over the place gets very ugly very quickly.

Share this post


Link to post
Share on other sites
I desire dynamic amounts of objects in game. Letting someone on a P1 play simple scenarios while a quad-7GHz-sledgehammer machine should be able to have 30000 AI beating on him/her at once. Scalability is why I chose linked lists. (And the fact that memory is only "used" when it contains useful info).

I understand the ugliness of heaps of links. They have caused a lot of headache already, and my new idea is likely to be worse. One of the reasons I wanted alternatives.

I'm not so sure that linked lists are that slow, if you refrain from referring to objects in the list by position, or from searching the list too regularly, then they are almost as fast as raw arrays. (malloc / free use a tiny fraction of my time - I've checked)

If you're suggesting another (simplish) data type than array, then please do tell.

[edited by - Krylloan on August 14, 2002 1:29:51 AM]

Share this post


Link to post
Share on other sites
One method would to have a IsDead int for the target object.

Like Mithrandirc said, the AI checks to see if this has gone >0, if so the AI sets there target to NULL, or whatever.

The important thing is you only remove the dead object from the list a couple of frames after it has flagged its death. This way everything referencing it can clean up without worrying about accessing a now none valid pointer. i.e.

AI:-

if( Target->IsDead ) Target = NULL;

DeadThing:-
const u32 FRAMEWAIT = 3; // or whatever you want

if( IShouldDie ) IsDead++;
if( IsDead > FRAMEWAIT ) RemoveFromLinkedList();

Share this post


Link to post
Share on other sites
I tend to make sure that the only object that holds a direct pointers is the list or container itself. Everything else would probably hold an ID number or whatever, and searches the container for the object with that ID number. If it''s not there, then it just doesn''t do whatever it was going to do. It''s not always quite as efficient as everything holding pointers, but it''s far less error-prone.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites