Procedural Music Redux, and More Memory Leaking

Hey Folks! Did a bit more work on Josh's procedural music for the space game, as well as returning to more memory leak fixes.

Since the procedural music was having timing issues due to my code, Josh and I agreed he'll continue on the other, more traditional tracks. And in the meantime, I'll try a few more things to see if I can get it to work. No need to make Josh wait for me to fix stuff when he has other tasks cleared for development.

So to help execute that plan, I formalize the official soundtrack specs in a spreadsheet, so we could see the specs and current status of each track. He's returned to working on the in-flight tracks for now.

On the mobile project, Tiago's been blasting through the bug list today. Just one right after the other. Plus, I think he was able to source a new iPad in his hometown after much searching, so can can resume testing locally!

Since he's making all that progress on the task list, I've decided to try and tackle the next largest memory leak: player conditions. These things are getting spawned left and right, and I think much of the time, it's just being done wastefully where I was trying to check things on creatures. I've started reworking the way they're added/removed or checked, and hopefully that can start us down a path to more responsible memory usage.

Oh, and I've decided to try and update the software on my dev MacBook. After months in the closet, the last thing I need is to open it up in an emergency and wait 4 hours for OS and software updates. I think OSX will be done today. Windows tomorrow.

That's all for today. Catch you all tomorrow!

Comments

ra1's picture
ra1

Maybe I'm misunderstanding, but wouldn't the max number of player conditions be a relatively low number (like 50)? If so, why not just pre-allocate 50 objects before the game starts and (re)use those?

dcfedor's picture
dcfedor

There are a couple things going on under the hood that one wouldn't expect.

For one thing, PlayerCondition is a deceptive name. It really just means "condition," and every object that needs conditions uses PlayerCondition.

A condition has properties like "stack count" and "start date," and these are unique to each instance. Player might have "wearing light shirt" with stack count 1 (1x effect from wearing 1x shirt), while an AI might have the same condition with stack count 2 from 2x shirts. Or Player might have "poison" which started 1 day ago, while AI has "poison" starting 1 hour ago. They'll each advance at different times.

And there are a lot of conditions used for invisible things. They're used to track encounter choices, skills, wound status (for each wound slot), vital stats...not to mention the one-off conditions which apply effects, such as those used in battle or when using consumables.

Each campsite has a unique condition, too. Since one ruined building might have different camp stats, it uses a unique condition with those stats to apply to the player.

Basically, NEO Scavenger is a beast when it comes to data. And conditions might actually be the heart of that beast. As I'm discovering now while trying to rearchitect them, they're everywhere.

Dan Fedor - Founder, Blue Bottle Games