Dev Blog 32 - In Base 4, I'm Fine

Ahoy, fellow traveller. ‘Tis a rare treat to meet another on this weary road. I take it you be searching for the Dev Blog? Well… I’ll be honored to take you to it, friend. Oh, foolish, foolish! I’ven’t even gone and introduced myself. My name is Brandon ‘BitesDev’ Johnson. Let’s set this ship asail.

…I’ll be the first to admit - that intro sucked, and this devblog isn’t a whole lot better. We’ve actually been working on something internal for the past few weeks, and have had little time to dedicate to practical progress on the game. However, this little internal thing may lead to a very, VERY interesting announcement in March. Let’s just get into the dev blog, though!

Big Ass Slide.

big ass slide

Pringle Platforms.


this time the level name is actually straps

Linked Blocks. Spoiler: this is actually a very old level of mine, but one I had forgotten about until recently. When I saw it again, I thought… wait, this is actually sick. I’ll use it in Rolled Out!

linked blocks

We’ve got some awesome background related work being done behind the scenes, but it isn’t quite ready to show off. Soon, hopefully!

We also recently brought on a new SFX designer - the wonderful and skilled ViRiX Dreamcore.

ViRiX Dreamcore on SoundCloud

ViRiX Dreamcore on YouTube

He’s kind of awesome.

Moving on, we have a little writeup from CraftedCart, our local technology and programming genius. Have I ever mentioned how much I admire their programming skills? It blows me away every time I think about it. Please enjoy!

On automated testing

Testing, a necessary part of software development, can be can be quite a slow and laborious process if you’re a human - also very easy to overlook how changes in one part of the codebase may have affected another part. Well, what if we could automate that…!

I’ll be the first to admit that I hadn’t really looked into automated testing for software until just somewhat recently - mostly I didn’t know where to start or what to test (which sounds silly in hindsight, but… eh). Test coverage for Rolled Out! is still fairly small right now, but since we’re in the middle of a lot of code cleanups (yes, still - this takes even longer than I thought it would), it’d make sense to put in a little extra effort to make sure systems like the stage loader or the local stage database don’t explode when you, say, try and load a stage with a malformed texture, or when the game tries to index a stage with invalid metadata.

(That terminal screencast can also be viewed at if it looks slightly wrong here)

Certainly not as pretty as, say, Factorio’s testing, but hey it’s something.

So why today do I decide to bring this up? Well, we’ve just had a regression (a formerly passing test that now fails) and I feel like I’m back to fighting C++ again (wooo). You may remember from dev update 10 that we have our own hand-rolled reflection system, to try and make C++ a bit more dynamic. That has been relying on a rule in C++ for us to differentiate types: static data only exists once.

…except when it doesn’t…

template<typename T>
static const FTypeTag* From()
static FTypeTag Tag = FTypeTag( // <--- static data!
return &Tag;

The way templates work in C++, is that you can write some generic code, and then when compiling, the generic code will be duplicated for every type you want to use it with, and the placeholders will filled in. So calling, for example, FTypeTag::From<uint8>(), FTypeTag::From<FString>(), and FTypeTag::From<FSceneNode>(), would duplicate the above code block three times, each time specialized to operate on the types uint8, FString, and FSceneNode. This was great, since we could store static data inside that function, and we’d know that there is only that one piece of data for each type we wanted to work with…

…and then I split our tests out into their own module, separate from the main game (where a module is a DLL, DYLIB, or SO file on Windows, Mac, and Linux respectively). Usually, with static data, this would be fine, as only one instance of the static data would ever exist, stored somewhere in exactly one of the modules. When working with templates however, templated code isn’t de-duplicated across modules. It’s possible to end up with duplicate data if both our main game module, and our test module, are loaded at the same time, so that’s fun.

Now at this point, you might be expecting me to explain how I solved this… but in fact, I’m still trying to figure out the best way handle it. Should we allow duplicate type tags but implement an operator== to check for equality? If so, how should be check that? Name comparison? Or could we do some macro trickery to define static data outside of templates with some funky generated name, and ensure that the static data only exists in the main game module? I’m still toying around with it.

Anyways, that’s all from me for now - back to head scratching.

Seriously, though. Next month is going to pop off. If it doesn’t, you can write mean words at me on Twitter, and I won’t even yell or scream or cry.

See you on March 1st!