KDTree in ECS

Hi there. This post actually dates back to last week, however I have been occupied with a game jam and only now have time  to do some updating.

MAAAAN is this the most interesting project that I've ever undertaken! It really challenges my knowledge about programming; doing it in a data oriented way, I really have to think about my memory in ways that object oriented is happy to let you be oblivious to.

The last devlog, I said I would start working on a KDTree so I could query to my boids in an optimized way. Err... in normal English: KDTree is like a neatly sorted cabinet whilst no KDTree is like a pile of rubbish that was rolled into a ball then shot out of a cannon. 
Protip: programming is a lot more fun when you imagine things being shot out of a cannon.

To get me started, I stole borrowed this code from github. (After all, "Fast KDTree for Unity, with thread-safe querying" was kinda exactly what I needed.) Without even trying to understand it, I hooked it up to my ECS boids and coming as no surprise to anyone it didn't work. See, if I wanted to make the KDTree work with ECS, it had to be made out entirely out of structs (excuse the oversimplification). I also couldn't have references and I had to work with NativeArrays, eeeeeh.... long story short a lot of stuff needed to be refactored, reprogrammed and retested.

Now I reeeeaaaally don't think anyone cares about that whole process, so I'll say this; I did it. I refactored the entire KDTree to be able to work with ECS. I then did the same for a radius query, which let me find all other boids around a single point and further enhanced it to allow me to specify a maximum number of results (if you'll remember my physics test, things were only more performant if boids didn't swarm too close to each other). I also hooked up rebuilding the KDTree, which needs to happen every frame, as a Job so it can even take advantage of ECS on its own.

And you know what, after all was said and done? Race conditions and errors. Race conditions and errors that I haven't looked at yet and that will probably make me have to rewrite my KDTree from scratch AGAIN!

Feeling not too psyched about that, I instead opted for something else; clean up this project so that I can shelf it and come back to it at my own convenience. After all, there was a game jam coming up I had signed up for and I could NOT be also thinking about boids every waking moment I was working on (another) dialogue system. You'd think designers would've learned by now >:/

So cleanup was what I did. I removed all my redundant code and put my debugging tests into their own assemblies (which is like putting it in your attic because you "might need it someday'"), I wrote some comments in places where I should have done that, and I query to my boids now and use the query to loop through jobs! It really spreads out the logic more evenly, and as an added bonus I can ignore boids that didn't move last frame (though they will all probably be moving always, but if I do start toying with that someday then it's free performance!)

Though this might seem like a failure, as with everything in science: there is no failure, only 'progress'. And I definitely made a lot of it! After all, my KDTree may not work, but I DID learn how to refactor object oriented code to data oriented code. That, in its own right, is a HUGE success! It even all works with the burst compiler! The errors I'm getting are about something new. That will be my next challenge. But every challenge I undertake, whether if I surmount it or not, gives me a closer understanding of this new beast of programming. And that's still progress.