I’ve been spending my time taking my single threaded game and making it multi-threaded in an effort to improve performance. I honestly thought that I could get away with the entire game being single threaded, but it gets noticably choppy late game and I’d like to fix that.
I think if this game was strictly turn based like most 4x games then it’d have been fine, but it’s not. You press one of the speed buttons up top, and then turns start happening automatically on a set interval depending on the speed chosen. On the fastest speed, turns happen about once every 600 milliseconds, so when the game was a single thread those 600 milliseconds were essentially wasted. The game was waiting until the 600 milliseconds were up in order to calculate the next state of the game world. It led to a noticable pause every time a new turn occurred.
It’s been a good learning experience, though I do wish I did this sooner.
I’m also taking this time to refactor other aspects of the code. For example, the code responsible for the grid is something that I wrote in 2012, and I was making things up as I went along back then. I still am to be honest, but I’ve got more of an idea nowadays. The grid was entangled too much with code specific for this project. What I want instead is something independent which can be reused in other projects. It’d also be nice if it supported multiple grid types (square, isometric, hex).
So I spent some time making that happen. Code is now cleaner and more flexible. Also now supports square, isometric, and I spent about an hour last night adding in hex support. The game is mostly agnostic to what type of grid it takes place on, so I can now generate a world using any of those grid types, which is pretty cool. I’d have to do some work to make it truly playable on a hex grid (AI code would need to account for the different grid type for instance), but curiosity of how this would look as a hexmap got the better of me.
Copyright © - Daniel J. Petersen