   Object Manager design difficulties
  Hey all,I'm designing an object manager for my engine (C++, OpenGL).  It handles memory management and object tracking at once.  However, my difficulty is how to design this manager.  The basic structure I've come up with is very simplistic:Object Manager|___Object  |___Object  |___...All classes that have a bearing on the game itself (players, cameras, bullets, etc) derive from a base object class, which has a static reference back to the Object Manager.  My problem is this: when I need to find a certain object (for example: I have three cameras floating around, and want to get the main camera to update its state and/or switch the view to that camera), how do I search for that camera?  When I search the object manager for said camera, I need to know a)if the object I'm currently looking at in the search loop is a camera and b)if it's the right camera.  I've come up with a few designs:+ Object Manager contains other object managers, which whittle down the types in a tree-like structure until you've gotten to the leaf (most derived type).  This is quite obviously very inefficient, since I have to loop through each object manager looking for the proper type, then the proper instance.  I scrapped this one.+ Use the above-diagrammed method, searching through the objects until I find the proper one.  This is still very inefficient, as it requires (or could) a complete search through the object manager to find the proper instance.The worst part is that these both rely heavily on RTTI and total hacks (a name member variable for the object base class, uniquely assigned at every *instance* creation of *any* object derived from the base object class that needs to be known by whatever is looking for that instance) to determine whether or not the instance I'm looking at is the one I want.  I'm trying to make this design as simplistic as possible.  It needs to be very clearly done (this will be worked on by many other programmers), very efficient, and very simple.  I have looked at Richard Fine's Enginuity series, and of course it was very well done, but I'm looking for much more in the way of a message-based system, where everything talks through a central location (such as through a kernel).  This design is for students who may not be able to understand the complete hacks that I'll go through in building this.  Simple, extensible, and robust is what I'm going for.I'm not asking anyone to design this object manager, or even give me code, I just need a push in the right direction.  I really appreciate any help you can give!Thanks,Aviosity   
  What do you want to search on? Are you going to have a unique string name attributed to each instance? If so, then you could just maintain a list of the unique objects in a map. I'm not sure how map performs its searches, but if it keeps the list sorted and does a binary search, then I don't think performance will be an issue.   ;  What if you maintained a list of all active cameras? In the constructor of your camera class, have the camera add itself to an std::vector of camera pointers -- perhaps a static member of the camera class.   ;  Hey guys,Thanks a lot for the quick responses.  The issue is, this isn't just limited to objects of the same type (where it would be easy to maintain a static vector of those objects amongst the camera types).  Player1 may need to say to the camera "Hey, I've moved over here - here's my new position, you should update!"  This won't work with a static vector, since they're all different derived types with different member functions and variables, although they all do derive from the base class Object.  I want to avoid tagging objects with names, if at all avoidable.  That technique requires that the calling object searching for another object knows the name of the object it's searching for.  For example: Player1 is looking for Tree2, where Player1 is a NPC.  Player1 needs to get Tree2's position from Tree2, which requires Player1 to know the name of Tree2 so that he can find Tree2's position and head towards it.  That gets messy, especially when you have 5000 instances, each with a unique name, and lots of searching going on for updated positions, physics, etc.  I want every object to be part of this object/memory manager, but I'm kind of at a loss of how to organize it so that information can flow and be updated without RTTI or naming classes.Thanks so much,Aviosity   ;Quote:when I need to find a certain objectWhy is this ever a requirement? An explicit reference or shared/weak pointer will save you tons of time and headache. If a player knows about a Tree or whatever to move to it, why do you need to search for it?However, you might want to include some sort of unique identifier in the base object. Quite useful for network play and can lead to a nice hash table of uid->object for when lookups are required.   ;  Well, I think if you want to be able to uniquely identify an instance of a class using no unique information, then be able to search for it later knowing absolutely nothing about what you want to find, other than the type of object it's going to be, you're out of luck :(.You're going to have to assign SOME kind of unique identifier to each instance. Searching through a sorted array is not too slow. Each object can have a name associated to it and a 32 bit hash generated from it. Keeping those hashes in a sorted list will be very efficient to search. Ogre uses string identifiers for entities in the scene and I don't think ogre could be considered slow.   ;  Smr, Telastyn,You guys are absolutely right.  I was thinking that UID/name identifiers were a messy way to do things, but when I think about it, if the UIDs are generated at runtime and kept in a sorted array, I don't have the particular problems of speed or associated processing (like finding the object closest to another one), and they're all grouped together.  I just couldn't conceptualize doing this without RTTI in a clean manner.  I suppose it would be even more efficient to sort that array first by type, then by numerical/alphabetical order.  I suppose if OGRE can run these calculations every frame and it works, it should definitely work for me :-P.Thanks all for your help - if anybody wants to add additional ideas, I'd be more than happy to hear them :-).Thanks,Aviosity   ;  No problem. There's no need to try to find one single paradigm which solves all of your organization problems. You can keep a tree which maintains the hierarchial relationships between objects, a map/hashtable which indexes the objects by name/guid, a linked list which sorts them by render order (for example to minimize opengl state changes) all at the same time. The memory footprint is negligible compared to the amount of memory available in the standard machine, especially considering the performance gains you will be able to achieve.   ;  Why not store objects in the object manager in multiple lists, one for each derived type from the base object? You can easily manage these arrays by creating an enum that has a value for each type of object, and ends with a value that represents how many types there are.enum OBJECT_TYPES { CAMERA, PLAYER, ..., NUM_OBJECT_TYPES };Create an array of lists, vectors or whatever storage you are going to use:vector<BaseObject *> objects[NUM_OBJECT_TYPES];If the base object maintains a type member, using the enum, for what type of object it actually is (can set this in the constructors), you can just iterate through one of these smaller lists much quicker than through one giant one and find the instance you're looking for much faster, as long as you know what type you're looking for. Adding new type of object is as easy as adding it to the enum. No RTTI needed!If I understand your problem correctly, this may be helpful. It's what I usually do for large-scale object management, and it works pretty well.;  Having a type enum is still RTTI, even if it's user made, unreliable, tedious to maintain, and generally a poor design.