Memory Leaking Camps, Encounters, and Skill Items

Hey Folks! I continued my memory leak investigation today, and I think I found some culprits. It appears campsites, encounter items, and skill selection are behaving badly.

The skill selection is an odd one, as I use a temporary skill item to check if the player has completely filled their skill or trait boxes. And for whatever reason, those test items remain in memory even after quitting. This doesn't have a huge impact, but adds-up if you play multiple new games in a session. This wasn't too hard to fix.

More worrying was the campsite leak. Each hex explored by players or NPCs loads the one or more camps for that hex. And those camps never get removed from memory. Fair enough during a single game, as they all must exist along with their hexes. However, when quitting, they remained in memory. And for longer games, this can mean a lot of unnecessary camps in memory. I think I've got a fix ready for this, too.

Even worse, every encounter item on every encounter page is getting stuck in memory. When you think about how many encounter screens you see in a game, and how many choices come up, this is a lot of items we're talking about. And that's not counting combat. If this includes combat, we're talking dozens of items per-turn! That's fire-hose leaking right there.

And unfortunately, this is harder to fix. Those same encounter items include a mix of temporary items specific to each encounter and more general items from the player's inventory. (Or more accurately, clones of them for encounter use only.) Simply destroying all of them can accidentally destroy important player items (like skills, tools, etc.).

What's worse, the way that encounter screens are resolved, I can't just destroy them each turn without getting null pointers. (Usually from trying to discharge any used tools during the turn advancement.) So I have to be really careful about when I destroy them, not just which ones. Sheesh!

But if this is as bad as it seems, this could mean plugging a major hole in memory management. So there's at least that silver lining. Here's hoping we can find a fix for it!


ra1's picture

Have you considered any type of semi-lazy garbage collection? (just in cases like this where you have a moving target)

Malacodor's picture

Doesn't Haxe have smart pointers?

Ran around with a clown mask before it was cool

dcfedor's picture

@ra1, do you have an example? We do have some gc stuff, both automatic and manual, but it's hard to say if it covers what you're describing.

@Malacodor, I'm pretty sure the answer is "yes," but I'm no CS graduate. Haxe is supposed to release objects when nothing references them any longer, and has garbage collection routines that run periodically.

However, there are a lot of complex objects in NEO Scavenger that might confound the gc. (Or due to human error, block the gc from doing it's job.) E.g. an item might not be in-game any longer, but some property of it might still be referenced by an in-game object due to design error.

I also seem to recall gc's having trouble with large "islands" of interconnected objects. So if an object referred to lots of other objects, but nothing in the game referenced them, the gc might still let it live because it assumes it's being used by something.

But that might be Flash knowledge seeping into my Haxe knowledge.

Dan Fedor - Founder, Blue Bottle Games