It Usually Ends In Nuclear War

[Sub]

That looks so cool and nice! Good luck in development! Hope "it will end in enjoyable game" (not a nuclear war ) How do you make this "terra incognita" effect? (unexplored areas are not shown)

Thanks!

I don't know if I have a great answer for you.  I don't think it's doing anything fancy or clever.

The map is currently a giant VertexArray which has its vertices set once immediatley after map generation.  I have a variable representing the unexplored map color (I think its currently at an rgb of 22, 22, 22), which is what the background color of the window is set to, as well as what each vertex color on that array is initially set to.

I keep track of a few vision related things for every nation.  Each tile has a VisionCount associated with it for every nation.  If for instance a unit moves (or is created / destroyed), this VisionCount is updated for every relevant tile.  In that way I know whether or not to draw a given unit or city. 

But yeah, when a tile goes from unexplored to explored I update the VertexArray, changing the relevant vertex colors from the unexplored color to that tiles actual color.       

Originally the vertex array only contained the tiles on screen, and I was reconstructing the array each time the camera panned or a game update happened,  I'm not sure if there's a meaningful difference in terms of performance between the two.  Eventually I'd like to convert it to a vbo so that there's not a ton of data continually getting sent to the video card each frame, but it runs fine on my old laptop at the moment so I haven't bothered.

I also used to do some crazy stuff with the background color and map edge, where I wanted the background color to be this certain shade of blue, but I couldn't set the background color at the start of the game to that, because then the player would be able to easily see where they were on the map by panning the camera around. 

So to solve that problem, when a player explored any map edge, I'd cast a ray along that edge to either the actual end of the map if it was explored, or it'd continually cast to the edge of the screen if not explored.  I'd use the two points on this ray to draw a shape filling out the remaining skybox of the screen. 




So the camera is at the same spot in both of these screens.   The top left edge isn't drawn in the first screen because the player hasn't explored a tile on the top left edge yet.

So in that first screen, the blue in the top right is a shape explicitly drawn.  Like I said, it allowed me to have a separate background color and unexplored terrain color, and it's the type of thing that I personally appreciate and think is cool, but uh, on reflection it's a bit insane to focus on things like that when the actual gameplay needs work.  That code currently isn't even in the game anymore as I commented it out during a refactor one day.

Tangents like that are partly the reason why this game is taking me so long to make.  I've been trying to focus purely on the things that actually matter now.  Which, as an aside, I implemented the above city location code and it looks like it's working well enough.  Pretty happy about that. 

[Sub]

I've been refactoring the codebase lately with the goal of increasing performance, mostly from multithreading it. 

Prior to now everything was a single thread.  I had no proper experience with multithreading, but I knew that it added a lot of complexity and I honestly thought that I could get away with the entire game being one thread. 

I think if this game was strictly turn based 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. 

As I've started to add in more complex AI behavior and the number of units and cities grew, it became clear that I'd need to make the game multithreaded.  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, as 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.

So that's how I've been spending my time lately.  Truthfully it's not as bad as I thought it'd be, though I do wish I did this sooner. 

Since I'm refactoring the codebase to allow for that, I've also taken this opportunity to improve other aspects of the code.  The grid for instance is something that I wrote in 2012 when I was much worse at programming than I am now, and it could really be better.  Notably I had entangled it too much with code specific for this project.  What I want 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 working on that and it's been a pleasant success.  It's now faster, more flexible, and you can set the grid type at initialization.  Currently 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 (for instance, some AI code would need to account for the different grid type), but curiosity of how this would look as a hexmap got the better of me. 

I'm hoping to get back to actually implementing more gameplay soon.

[eXpl0it3r]

Nice work! Keep it up.

[Sub]

Not much to look at yet, but I started work the other day on a tech tree GUI.  Each technology is defined in a json file, and the game generates the layout of the tech tree based on the order of the tech unlocks.  This was slightly harder than I thought it would be, but I've now more or less got the positioning down. 

It used to be a simple list


The WIP Tech Tree


The blue box is what's directly unlocked by researching the moused over box.
The red box is what's directly required to unlock researching the moused over box.
The purple box are what is indirectly required to unlock researching the moused over box.

In other words, all of the purple and red boxes need to be researched before you're able to research Astronomy. 

Next on the agenda is drawing lines from each box to their direct unlocks.  I'm thinking that I'm going to define a small (invisible) grid (with each cell being 10x10) and adapting the pathfinding system to make this happen.  The width/height of each technology box is going to be a multiple of 10 and the boxes in the grid which overlap with the tech boxes will be defined as obstacles.  Then it'll just be pathfinding between relevant tech boxes.  I suspect that with each line I add I'm going to need to update the grid to mark those boxes as obstacles to prevent lines overlapping. 

I'm not really looking forward to this, and I'm not 100% sure that it'll actually work and look nice, but we'll see.  I'm going to try to make that happen either Friday or Saturday.

Then I'll need to add icons / progress bars and try to make it look pretty.

[Parsley]

This looks cool! Did you end up multithreading it since the last update? I multithreaded my game but then people started reporting random crashes every few hours and I got paranoid and single threaded it. It's really hard to do and increases the code complexity by so much.

[Sub]

Thanks

The game is now multithreaded, though I was way too optimistic in that post.  I can relate to the crashes and bugs, it was a nightmare to get it working properly.  I had to rewrite a bunch of code and it wasted a lot of time. 

It fixed the performance issue I was having, but honestly, if I get a chance I want to go back and improve this aspect of the code because it could be a lot more efficient.  I decided the easiest thing to do would be to have separate sections of the code be offloaded to their own thread.  So for example, the units are all being processed on their own thread, the cities on their own thread, etc. 

I don't know if I'll ever get around to this, but what I'd like to do instead is have a generic job queue system in place where the main thread is posting jobs which need to be done, and there's a constant number of threads taking the next job up in the queue and performing the work.  That would utilize all the cpu cores more consistently / evenly. 

At the very least I want to have a system like that for the next project I do.  Game dev is hard and I'm kind of learning as I go here.

[dabbertorres]

I don't know if I'll ever get around to this, but what I'd like to do instead is have a generic job queue system in place where the main thread is posting jobs which need to be done, and there's a constant number of threads taking the next job up in the queue and performing the work.  That would utilize all the cpu cores more consistently / evenly.

Easiest way would be to use a thread pool library.

[Sub]

I don't know if I'll ever get around to this, but what I'd like to do instead is have a generic job queue system in place where the main thread is posting jobs which need to be done, and there's a constant number of threads taking the next job up in the queue and performing the work.  That would utilize all the cpu cores more consistently / evenly.

Easiest way would be to use a thread pool library.

Yeah.  It was bothering me so I went ahead and integrated a thread pool library instead of having dedicated explicitly defined threads for specific tasks. 

Went with CTPL (https://github.com/vit-vit/ctpl) as it seemed reasonable and didn't have any show stopping open issues.  There was another library that I liked the API of, but it had a deadlock in the most recent version that the author didn't seem too keen on fixing anytime soon.  There was also a boost one that looked like it could be good, but I don't want to use boost.

I'm curious if most people roll their own or something.  I expected there to be libraries with thousands of stars on Github, but the most popular one I found was a C library with 450 stars. 

[dabbertorres]

Yeah that was something I noticed. I ended up rolling my own, and I've been happy with it. Stress testing it was a fun exercise.

At a quick glance, ctpl and my impl seem to be fairly similar funnily enough, except ctpl is header-only (And used by a lot more people it looks like).

Boost was the other thing I noticed, a decent amount of libraries I found just let Boost go and do all the fun stuff!

[Sub]

Ah cool.  Looks like a nice clean library.  Very easy to read / understand the code 

[Sub]

Getting closer to where I want it to be.