koobas.hobune.stream
Best Practice: Object referencing itself at various places
Hi all,
I have a somewhat open problem. In my game I have a class called Obj and literally everything in the world is a derivative of this. Apart from basic features like position, rotation, etc, the Obj class also holds information on "target" (i.e. is the object targeting another object?) and "visibleObjects" (what other objects are in viewing range of this object). Both utilize the same Obj class to reference these objects in question.
Unfortunately this leads to situations where the garbage collection will never release the instance, even if the object is officially destroyed, simply because it might still be referenced as "target" or within "visibleObjects" of another object. I did some basic tests and it should not be a problem to have 100K objects in memory, which is much more than I need, though I feel this may not be a clean solution.
A second solution I thought of would be to refer to every object by its ID (all objects have unique IDs). This would fix the GC problem, however, it would require me to use an additional step in getting to the object in question, which previously was very easy to cross-reference. I feel this may not be the most performant operation, since I require several hundred thousands of such cross-checks per second.
What do you think would be better?
I'm a bit confused--did you make a new class called "Object"? This could cause all sorts of headaches as that is a built in type that, well, everything extends.
you're right, it was Obj, not Object. Sorry about the confusion.
Ok, that makes sense--you wouldn't have been allowed to call it "Object" anyhow.
Still--do you have a specific problem? If you were to destroy an instance of an object referred to in other scripts, the reference simply points to a null object and there shouldn't be any real problems--save for you needing to check for null.
no not really. But the amount of objects would grow in memory, since it doesn't really get deleted, no? Note I am not using a $$anonymous$$onoBehaviour class, but an own class, which may complicate the problem, since somehow I can't seem to null it, which would be done automatically with $$anonymous$$onoBehaviour.Destroy(). I may need to use refs for this and I get a feeling this could affect the GC logic?
It's not (well, not really)! This is what garbage collection is, it recognizes which bits of allocated memory are no longer in scope and frees them on the heap.
If you're not running into memory leaks or having an abundance of null errors what you simply need to be doing is checking (if Obj != null) do stuff with obj; else scream about the error;
The primary way to solve this is for each object to be able to "notify" other objects that it is destroyed, and hence, they should update their "target" and "visible" lists.
This can be done in two ways:
1) Every destroyed object sends a broadcast message, and every other object that can respond updates its list. CONS: Expensive if you are destroying objects frequently.
2) The trick is to use two-way lists. So Each object would have a "target" and/or "visible" list, as well as "targeted by" and "seen by" list.
Every time an object is added to another objects "target" list, the "targeted by" is updated. When the object is destroyed, it notifies other objects in its list that it is being destroyed. CONS: Larger memory overhead.
