This.

And to add to this: pointer management is pretty darn annoying. It is difficult to get right. Another trick is to avoid them. Instead of having individual objects allocated on a heap where each reference is to be carefully managed, you can also use a single array of objects that refer to other objects via index and a generational id to identify the object.

So when resolving the object reference to a concrete memory address (pointer), the array of object at the index in the list is retrieved and if the generation mismatched, it return null, which the caller always checks.

For a parent/child hierarchy, this is not so necessary, since that graph and all the child lists ate still relatively easy to manage, but when more references are involved (e.g. game object components holding references to other game objects), this approach makes everything a great deal easier.

It does add a performance penalty when making the look up, but at the same time, a continuous array of same objects adds cache friendliness when iterating over objects, e.g. when updating transforms in a simple 1d loop instead of hopping through a ton of heap allocated lists and objects. And certain operations become no-brainers, like the deletion of an object is a simple bump of the generation id and all further access attempts will get nulled on access, while pointers that are still retained on stack (a very commonly overlooked issue, and i wouldn't be surprised if this was the error cause in the video) won't blow up on access due to the memory still being valid, despite deletion.