Boring code update

Yeah this is one of ~those~ blog posts. Not so sexy, unless you like data structures.

After adding multiple partners to Fucked Up Burger Shack compilation time in the Unity Editor skyrocketed to 14 seconds. There is some overhead to running games inside of Unity for various reasons, but built versions don't have the same kind of overhead. So then every time I changed the source to FUBS I'd have to wait about 14 seconds for the game to compile so that I could play test it. 14 seconds! It was driving me crazy so I had to get hacking.

I put on my old coding cap and drilled down to the root of the issue, an 'indexOf' operation on the underlying passage identifier lookup List. But let me stop right there, because in 101 posts to this Bunkville Blog I've tried to spare readers anything too super specific about programming topics like asymptotic time complexity. I'll summarize it all by saying I did something pretty stupid in the codes, but made it better like now.

After my fixes, compilation time in the editor is coming in around 5 seconds, making my development life much more pleasant. I like to stop at points like these before getting too deep into micro optimization, but I know that there is more work to be done there. I'll get back to it if needed. But then there was something else really annoying me heavily.

As I'm building FUBS I have the need to jump to specific places in the game that I'm currently working in. The most obvious way to do that is to save the game and reload it after making a change. The trouble is that when changes are made anywhere in the FUBS source files, the underlying structure of the game changes, meaning game saves almost always immediately break. This is one reason I chose to use monotonic versioning for FUBS, since it makes the compatibility of releases clear with the number on the left (version 7.15 for example, which is what I'm working on, will be incompatible with 6.14). But this problem sucks more and more as progress made further into the game gets erased. I personally have lost quite a few Randos I was fond of due to save breakage, and it's not cool. -side note- I'm just now realizing that I've created digital creatures that I've grown attached to. Is that a fetish? Anyway, my previous bandage to remedy the compatibility problem was to make a bunch of links into different places in FUBS from the Debug menu. It's a good thing to have, but a lasting solution it is not.

Back with the coding cap on, I figured out a way to stabilize the underlying game structure by caching information about passages and named numbers alongside the game source. FUBS will output a cache folder into the game files directory alongside 'saves' and 'source', which will hold a lookup file to keep a running index of stuff used behind the scenes. Ideally this cache can stay in place across new versions of FUBS to keep game saves working. And it will even work with stuff added via modding, so anyone doing that will have their own personal cache that builds up over time. This is all kind of theory right now, but so far in my tests it looks promising. If all goes to plan FUBS updates will be under the compatibility number 7 for a while.

And that's all I have for now.  I wanted to get rid of these annoyances so that I could focus on more interesting things. More on those interesting things in my next blog post.