I guess I’m trying to figure out how it helps you with de/serializing subsets of your object graph at different points in time. Looking forward to the blog post!

The quick answer is that you can serialize the contents of the handle manager. The pointers are irrelevant, but the handles aren’t. At load time, when you re-create the objects, instead of adding them to the handle manager, all you say is “update this handle with this new location”. It’s pretty much the same as doing a pointer fixup, just through the handle manager (but the good thing is that you only have to do it for the object itself, and any other data that contained that handle will be valid after loading).

Or are you simply referring to a serialization scheme that *also* stores every single object currently pointed to as an array?

I would mention though, that we’re currently tending to question mutable structures in general. For multi-threaded code, we’ve found that it is much clearer (and simpler!) to always generate new data instead of mutating the old. This is in the spirit of functional programming, but it works out really well. So, instead of modifying/deleting/tracking old pointers – all you need to care about is how to build up your arrays/structures (including “updating” your state) at every frame. The con of that approach is that you might use a little more (temporary) memory, but the simplicity and speed advantage more than compensates for that.

Sure, for the uint32 v/s uint32_t, I’m with your there — I used to hate the trailing “_t”, but I’ve just sucked it up and I’m now using the standard types everywhere, even on MS’s platforms…

I think the main thing today is that I’ve left a lot of the ticks behind, I don’t *have* to have all the variables lined up in the same column, or neatly aligned in a row. I guess I’ve just become better at reading code and can tolerate a wider range of inputs

Indeed, smart pointers can cause some data to hang around, but I don’t think it is such a bad thing, it is only a symptom of something going wrong somewhere else in the code. Without smart pointers, the data would have been deleted and there would now be a dangling pointer somewhere that might or might not crash any time later. So I tend to use reference counting to determine if it is safe or not to destroy an object, but I still keep the destruction itself explicit, within a manager. Best of both worlds, imho.

The only big problems I see with this system are due to cyclic references. But in my experience, it has been relatively easy to track down the leaks, and it gives me better confidence about the code being free of dangling pointers.

Just my two cents anyway

All too often, I’ve seen objects hang around just because their ref count hasn’t reached zero (either because of a logic error, or because of crazy structures designers created). It’s no fun tracking down why invisible explosion effects are hanging around indefinitely, trust me.

But my main objection is that you never have a good sense of how your memory is used, and how much there is left. Will the console run out of memory after the Nth enemy is spawned? Who knows. On the other hand, if you’re controlling in code explicitely memory allocation and destruction, you know for sure how much there is, when it goes away, and when there’s more, which for a game runtime, I think it’s pretty crucial.

For tools on the other hand, ref counting seems perfectly fine if you’re into that. No objections there.

1. Free the data immediately after the reference count reaches zero.

2. Free that data at anytime, regardless of how many things are still referencing it.

Aren’t there ways to solve either of these problems?