I saw my laziness, and I said neigh, I shall not continue on in such manner. Thusly, I was prompted to once again begin work on personal projects. Not only have I gotten back on the wagon, I have jumped headfirst onto the horse pulling it forward, all the whilst screaming and digging into its flanks with spurred boots, shouting 'ONWARDS' and diving into some nice, meaty concepts. What hath conquered my interests this time? Oh, it is my old foe, my nemesis and friend, Mr. Multi Agent Path Planning!

In modern English, I got bored with only programming at work, and I've started doing game development again, in a very serious fashion. Specifically, I'm back on my long dream of making an RTS.

So what have I completed currently, and where do I plan to go from here?

To answer these questions, we have to first ask something else. That question is, what is my minimum viable product? For each individual piece of the project, what is an acceptable level of completion by which I can work on other parts of the project? I merely need for that feature to be dev-complete, to work well enough to move forwards. Proper implementation can come later, with all the bells and whistles.

At the core of any RTS is pathfinding. I don't know how many people here have dived deep into the strange and wonderful realms of graph search and optimization, but as far as core parts goes, pathfinding is a doozy. However, there is a strange and wonderful joy that the dev-complete minimum viable product for pathfinding is simple - if you ignore unit collision. A strange thing to ignore, I do realize, but it greatly simplifies the problem of pathfinding, until you have a real, final implementation. What you care about is getting units from point A to point B - unit avoidance is not actually necessary.

So that is essentially what I have done. Instead of focusing on the pathfinding and algorithms itself, I went and developed a wicked fast, highly variable pathfinding interface, behind which I can change whatever the heck I want. It automatically has queueing and callbacks, runs on a separate thread, supports one-to-one and one-to-many with custom goals, uses a payload system so that it can have a consistent back end and has a very fast A* implementation with its backbone done in C. Heuristics/goals/metrics are all done via anonymous functions or function pointers, and my priority queue is a binary heap - my own implementation with a strange amount of optimization put into it. Basically, I made it flexible and easy to use.

Then, I also have gotten a decent chunk of work done towards the in-game filesystem. Obviously one needs a way to package and load various things, keep track of file versions and such, so I went and built a file caching system to do all of this for me. It even has a bit of CRC32 in there to detect file fuckery and such. It works well with my file package format that I'm using for resources, and I'm hoping to expand it a bit to automatically instantiate types of objects from requested files - which would be awesome. The only downside is texture atlasing - since textures would be attached to their various file packages as standalone stuff, I'd have to do the texture atlasing manually, at runtime. However, the positive side is that this will let me do runtime image compositing, so stuff like unit player-color and decals will be a snap.

So what does all this blather actually mean? Well, I can basically load a really shitty sample map, and have things run around in it avoiding walls, but not each other. So not much for a few weeks of effort. On the other hand, its a start, and I have enough pathfinding to build more complicated stuff. Who knows where the rest will take me? Once I get buildings in and stuff, this may start to look like a game!