A few weeks ago, I released my hobby projet: Asset Cooker. I even made a short release trailer for it.

So, what is Asset Cooker?

It’s a build system. Put very briefly, it has commands that have inputs and outputs (which are files). If the outputs don’t exist, or if the inputs are modified, it execute the command to (re)generate the outputs.

I don’t plan on describing everything in articles, because that would be too much (and not all of it interesting), but I’ll try to do a few (short?) articles about single topics that I find interesting.

In this first article, I’m going to talk about memory and storage. Asset Cooker has to deal with a lot of items. Hundreds of thousands of files, of commands, and of strings. Managing that carefully is very important.

I attended a Game Connection master class this year again. This time it was with Jason Gregory (Lead Programmer at Naughty Dog) on concurrent programming, and it was very interesting.

I won’t give a full account because we saw way too many things (500 slides!).

Instead, I’ll just write about a few spin lock implementation tricks that he showed us.

Strings are often used as identifiers in games: object names, sound effect names, particle type names, etc. They’re a bit like enums with the advantage of allowing your game to be data-driven: you don’t necessarily need to recompile your program to accept new values.

But strings are no fun: storing them efficiently is a headache, they’re bigger and they’re slower than enums.

Fortunately there’s an alternative: string hashes. We like them a lot at Pastagames, and here are our humble solutions to the practical problems that come with them.

I feel like I’ve been saying this a lot lately ‒ at least once per intern we take at Pastagames ‒ so I guess it’s time I write it down. There’s nothing new here, this has been said a hundred times over on the Internet, but since a lot of people are still not aware of it, here is my contribution.