RTS Engine

When I first started to learn C, as soon as I finished with learning the syntax I jumped straight into trying to make an RTS engine. I'd written enough of an engine including a server and a client to move units around on both screens and have them collide with each other and pathing blockers. I'd also written a map maker for placing pathing blockers. The whole thing was very crude, basically it was just a lot of colored rectangles that could be selected and move around. After a little over two weeks of working on it, I got bored and moved on to working on an MMO engine (partially shelved at the moment, it's on my GitHub)

Recently, I decided I wanted to work on my RTS engine more. Fortunately I was using git at the time and found an old backup. I hooked up my old repository to GitHub and started working on it about a week ago. Fortunately my coding was neat enough so I didn't have to spend a while figuring out what it all meant.

Over the last week, I focused on implementing pathing. In most RTS's, units automatically find paths around obstacles. I don't know how other RTS engines deal with it, but I decided to break the map up into a grid of rectangular nodes, each of which has a flag for occupied or not. When a unit is ordered to move, it runs the A* search algorithm using euclidean distance as a heuristic to find the optimal path. The current version is a little glitchy, but it seems to work. At the moment it is very crudely coded and would break if multiple units existed on the game or if the pathing blockers moved. I need to clean it up a little, but it's a good proof of concept right now.

Path 1

Path 2

Oops

I'm not sure how well A* will work as my game becomes more complicated. Right now the engine assumes units can only move to nodes adjacent to the node it's currently in. If I implement any sort of teleportation, I have no idea how to deal with it yet. If teleportation is done by a fixed teleporter, I guess I could test paths to the teleporter and see if they're shorter than direct paths. That doesn't scale very well with large amounts of teleporters, but it might not matter if I can assume there are always few teleporters. There are a few other tricks to A* which I don't entirely understand yet which might cause A* to get non-optimal paths.