next »

[Sub]

I consider myself a slow worker, but I am still making some progress on this thing.  I spent all of last Saturday and Sunday debugging various errors with the game that had popped up, which is harder to talk about than shiny new features.  I mostly worked on fixing issues / crashes due to incorrect syncing of data between the province view screen (pictured below) and the actual game data. 



I don't expect this screen to look anything like this when the game is done, but it has to look like something for now and I'm not sure where it'll end up.  In any case, I've worked out all the issues and the game is once again solid as a rock in terms of bugs / crashes.  I have no one but myself to blame for the issues, though.  I'm making my own GUI system for this game and it's a learn as you go process. 

I also spent a little bit of time last weekend stress testing units / pathfinding and I'm pretty happy with the results. 



That's a few hundred units auto exploring the map.  This is subject to change, but I currently envision the game ticking along at a solid rate similar to the Europa Universalis series, so it's pretty important that the time between turns is almost non-existent. 

Last night I built another GUI widget for the game -- We now have progress bars!  Try to contain your excitement. 



It might be a bit hard to see with the embedded screenshot.  At the moment I'm using it to countdown time until the next game tick occurs (aka the next 'turn'), as well as to show the progress of things being produced by a province. 

The remainder of this weekend I'm going to attempt to actually hook up the province growth algorithm that I have planned.  I want the number of births per 1000 people to roughly approximate the rate that populations have grown through history.  I'm going to have a rudimentary model of disease and a food/starvation system to keep populations from growing indefinitely.  In Civilization, population grows on a stairs sort of system, where it's flat for a long period of time and then it bumps up instantly when you fill up your food bars.  I want the population in this to grow in a more linear fashion, until you start developing technologies to eliminate starvation / disease. 

[Connor]

is this going to be a paid thing? will it be on steam? those two questions were the first things that came to mind.

Other than those two questions, this looks pretty impressive. the scope of the maps in civ games to me were far too small in my opinion, so to have a massive map like that is wicked. no more running into my friends in the first five minutes, haha.

i suppose thats also another question, will there be multiplayer? lan multiplayer looks like it would probably be wicked in this.

[Sub]

is this going to be a paid thing? will it be on steam? those two questions were the first things that came to mind.

Other than those two questions, this looks pretty impressive. the scope of the maps in civ games to me were far too small in my opinion, so to have a massive map like that is wicked. no more running into my friends in the first five minutes, haha.

i suppose thats also another question, will there be multiplayer? lan multiplayer looks like it would probably be wicked in this.

Hey, thanks for the interest

I'm planning on selling the game when it's complete.  I'd like to get it on Steam, but I'd have to get through their greenlight process first. 

As for whether it'll have multiplayer, it's going to be single player only.  I was never the type to play civ-style games in multiplayer, and I'm trying to prevent feature creep. 

[TheChaoticGood]

How long until we can see things blow up I'm a simple man.

[Sub]

Given my artistic abilities, any explosions we do get probably won't be too pretty

I'll figure something out though.

[Sub]

Still alive and working on this!

I've been working on the GUI system lately.  I just finished working on a simple automatic layout system so that I don't have to worry about manually positioning GUI items on the screen.  This was surprisingly hard to do, but I did come up with something that I'm happy with.  It's not the greatest thing in the world as I only have so much free time to work on the game, but it should definitely help me out in the future.

At the most basic level, I'm thinking of each GUI component as a rectangle that takes up space on the screen.  The layout system just manipulates rectangles for me by positioning and sizing them based on properties that I define for the rectangles.  So if for whatever reason I want a GUI component to span half of its container in width, and all of its container in height (a container the size of the screen is always the top most container), be anchored to the left edge of its container with an offset of however many pixels, be centered vertically, as well as have constraints on the size (min/max width and height), I can do that really easily.  The cool thing is that each GUI component can have other GUI components as children, allowing me to embed and use these position properties inside other GUI components. 

I'm going to be working on the GUI system until it's finished.  I very much want to be done with this task and start work on the actual game again, but I think patience always pays off in the end.  It should be worth it to have a good base so that I can quickly create / iterate on the GUI screens.  In terms of components, at the moment I have a

• Panel / Container
• Button
• Checkbox
• Radio Buttons
• Navbar menu
• Dialogue Box
• Messagebox (ie: the message list at the bottom left here)

I think that's a pretty good list of things, but I still need to build out a tab container, dropdown list, input box for text, a list view, numeric spinner, and a color picker.  I also want some way of making certain components scrollable.  I have some vague ideas on how to go about making the components scrollable, but I'm not really sure how I'm going to do it yet.

I'm also trying to pick out color schemes for the GUI.  I am not an artist, so I'm going to be going with plain colors / shapes instead of using premade images as a lot of games do.  I'm thinking something simple like white text on a semi transparent background as shown here looks pretty good.

[Sub]

I've been pretty frustrated lately with the amount of work still left to do.  I've been working on this thing since (around) November 27, 2012, and I'm still nowhere near finished.  The game isn't even playable in the sense of being in an alpha state.  I'm working on it at least 10 hours a week, which is better than nothing, but there's just insane amount of work to do, and it seems like most tasks are more time consuming than at first glance.  I'll start a task, and I'll think it'll take me an hour to do, and then 4 hours will have gone by and I'll be halfway there.  

I like to think that I have super human patience, but it's going to be great when I get this game behind me.  I have a full time job where I code, and then to try and come home and code some more after that is really tough.  

But I'm making progress.  In my last post I talked about how I was working on the GUI system, and that's come and gone.  It needs to be polished in terms of how it looks, but it's got all the widgets that I'll need, and everything works (!) and is relatively easy for me to use which is important.  

The current goal is to have a rough playable version up and running by January 1st.  I'm defining that as all of the core gameplay systems in place.  They'll be rough, but they'll be in there.  

[Pixel Noise]

The mental exhaustion of working all day, only to come home and try to create is REAL! Keep it up though

[Sub]

Thanks!  Honestly, I'm thinking about it and I don't think I even mind the mental exhaustion so much.  I think the thing that kills me is not knowing if this game that I'm making is even going to turn out good.  If I'm going to have something that I like at the end of this then yeah, in my mind of course it's worth it.  It would just be depressing on the other hand, though.  I suppose in the end, all we can do is give it our best try.

[Pixel Noise]

I'm no dev - but if you feel like the project is becoming too large or overwhelming - is there a way you could produce a sort of demo version, or smaller scale version of the project? That way you can see if, in limited capacity, it ends up being what you wanted?

Also, I know you mentioned trying to avoid some of the ultra detailed micromanaging of the Civ series - is there a way you can stream-line things even further? I don't know if that would completely wreck your vision of the game - but it may take some pressure and time off of your development cycle.

[VampireSquid]

I think it will turn out good if you put enough polish in.   I agree with Pixel Noise that you should consider working towards some type of demo.  Even if you don't release it to general public you could provide the demo to some of the review sites and that way get some feedback on the game.   Motivation is such a huge factor, that extra bump from some good reviews could power you through for another year or two.

[Sub]

I appreciate it guys.  I agree that motivation is huge, and working towards a playable demo should definitely be the goal.

In any case, I have a contribution to today's screenshot saturday

[Sub]

I'm still working on this and have been making good progress recently.  There's still a lot of work left to do, but I feel like I can see a light at the end of the tunnel now.

I've changed the name of the game from "It Always Ends In Nuclear War" to "It Usually Ends In Nuclear War".  The name was meant to be a commentary on human civilization, but I decided to change it as I was afraid that the old name could have given the wrong impression about the gameplay. 

I've also changed the graphics a bit.  Previously I had a pronounced psuedo-3d height visual effect going on.  I liked the way it looked and I put a fair amount of work into it, but it was purely aesthetic and it prevented me from using tile colors to display information about a given tile. 

For instance, in most if not all other similar 4X games there are a set number of distinct tile types.  In Civilization II for example,  a tile could either be  grassland, swamp, forest, plains, desert, or tundra.  Each tile type had a specific food, production, and science output.  I want the output of a tile to be somewhat dynamic, and I want the player to more or less be able to tell the output of a tile by its color alone. 

So I still have a base set of tile types which have a specific food and production output, but the tiles are blended in with their neighbors, and the outputs are averaged together (as is their color).  On top of this, I'm also further applying a bonus to production or food to select tiles, and I'm using the the shade of a tile color to communicate this to the player.   Darker tiles are better for production, lighter tiles are better for food. 

I can't say how anyone else will receive it, but I really quite like how it turned out.  At least in my head, lighter green tiles look more like grassland tiles and accordingly have great food output, and darker green tiles look to me more like forests and have great production output. 

The reason I'm happy about this is that most maps will have huge swaths of land which are a single tile type.   In the old system these tiles would all have the same output and I honestly don't know how I would go about balancing that.  This new system allows me to have those large swaths of land which are the same tile type, but vary their output depending on the shade, which for example would make some tiles in a huge swath of desert still desirable.

I've done a lot of other stuff since then, but those two are I think the biggest and most obvious changes.

Older look


Screenshot fro a few months ago.  The map is completely flat here


Screenshot from yesterday morning.  I readded height to the map here, but the tile shadows from height are no longer present.  Kind of a compromise between the two

[Sub]

Today I'm going to try to implement an algorithm which picks city locations for the AI.  

If you've ever played civilization, you should have a good idea on what this means, as it's more or less the same problem from that game.  Maps in my game are much larger than in Civilization, and my game ticks along at like 1 turn every 600 milliseconds, so performance is a pretty huge concern.  

I'm still debating the exact city ring size, and I'm going off memory here but I think cities can currently grow to a maximum of 5x5 tiles.  You can see the maximum growth of a city by the black outline around the center city this screen



If anyone has any suggestions on a good way of going about doing this, all I'm ears.  I've come up with something that I think will work (high level code outline below), but I wouldn't be surprised if there's a much better way of going about it.

Code:

// Only one  object of this class will be instantiated, and each AI will talk to this object in order to get a city location
class AI_City_Location_Mapper
{
private:
    // first dimension is number of continents on the map (where a continent is a group of connected land tiles)
    // second dimension is a vector of tile indexes where cities should be placed
    std::vector<std::vector<int>> CityLocationsByContinent

    // where the magic happens
    void calculateCityLocations(int ContinentIndex);

public:
    // city locations are calculated for each continent on map generation and cached in the above array
    void onMapGeneration()
    {
        CityLocationsByContinent.resize(NUMBER_OF_CONTINENETS);
        for (int i = 0; i < NUMBER_OF_CONTINENETS; i++)
        {
            calculateCityLocations(i);
        }
    }

    // if the human player settles a city, the city locations for that continent might need to be reworked to make more sense.
    void onCityCreation(int ContinentIndex)
    {
        calculateCityLocations(ContinentIndex);
    }

    // basically, the above two functions are the only time when city locations are going to be updated.  

    // when the AI wants a location for a new city, it calls this function, and passes the unit index for the settler in question.  
    // the game iterates through each possible city location for the continent the city is on, and does a simple calculation
    // based on distance and city desirability to determine which city location to settle
    // -1 if no city available 
    int requestCityLocation(int UnitIndex);
};

For calculateCityLocations(), I'm thinking that I'm going to divide the map up into a larger grid, with each cell in this larger grid representing let's say a 5x5 group of cells.  Perhaps that size will be determined by the city ring size.  I then think I'm going to assign a city location in the center tile of the actual grid for each cell in this large grid.  

So essentially calculateCityLocations would be iterating over each city in this list and moving the city location over 1 tile for each loop iteration, based on the best location of its neighbors.    If the initial city location happens to be on a water tile, I'll have to do a check to make sure that doesn't happen or fix it when it does.  I already have a function which ranks how good any given city location is, but I'm going to need to expand that function to take into account tiles which are already owned by another city (obviously those tiles would be degraded in importance).

I'm aiming to do all of this today, but we'll see how it goes.  Like I said in the beginning, if anyone has a better idea on how to go about doing this, I'm all ears.  This was the best I could come up with for now.

[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.

[VampireSquid]

Still following this, looks interesting.  I still haven't figured out what the base mechanics to the game are but I suppose that will come out as you make progress.

Working on a hex based game myself but still far from announcement.  Just a hobby project for me.  Too many responsibilities to do more.

On your city generation question, had to do something similar.  I just ranked and order descending each hex.  I then start from the highest scoring hexes, make sure that they are not within such-and-such distance of another city and if not, that's a city. I terminate after a fixed number of cities, with that number being determined based on map size with a little randomness thrown in.  It is simple but it works great.  Not sure if that helps, it looks like your code is already working.

[Sub]

Ah interesting.  That strikes me as a better approach to determining where to place cities.  It seems like it'd be quick to implement too.  I think I'm going to try it out in the hopes that it gets better results.

But yeah, I know ive been vague about the gameplay.  Truthfully I'm just a slow worker, and I dont want to post about what I have until I'm sure I like it and its not going to change.

Wish you luck on your project.  Let me know when you announce it

[Rarykos]

I love the name change! It sounds way better and it's funnier.

I've read your devlog and it's amazing that you've been going at it for so many years, huge patience for sure, that's admirable!

And I feel your worries, making a 4X is almost like making an RTS which is almost like making an MMORPG at this point. Huge amounts of work. Great to see you chipping away at it though!

It would be awesome to play a demo or see some of your ideas in play, it's such a big design space I don't know what to expect! Can you tell us what's the game about, what are your goals with it? I understand that it's like civ2 with less micromanagement, but you're not really recreating civ2, right?

[Sub]

I love the name change! It sounds way better and it's funnier.

I've read your devlog and it's amazing that you've been going at it for so many years, huge patience for sure, that's admirable!

And I feel your worries, making a 4X is almost like making an RTS which is almost like making an MMORPG at this point. Huge amounts of work. Great to see you chipping away at it though!

It would be awesome to play a demo or see some of your ideas in play, it's such a big design space I don't know what to expect! Can you tell us what's the game about, what are your goals with it? I understand that it's like civ2 with less micromanagement, but you're not really recreating civ2, right?

Thanks for the kind words .  I wrote an extremely long post in response, but don't feel any obligation to read it through.  I'm sitting in a hotel room right now with nothing but my phone and some time to kill, this post was the result.

The tl;dr is that I am taking the civ formula and making large changes in an attempt to make it less tedious to play (and hopefully make the end game more interesting). I'm not convinced that these changes will actually be for the better, and I've been pretty hesitent to write a post like this without having a more complete game with videos to back it up.  

Originally I started this project as a way to get better at programming, and the idea was that it would be civ 2 but with some usability improvements.  For instance, I wanted to fix things like the broken goto command, which was where the pathfinding was poor and would often not take the shortest path to get somewhere, or in some cases get itself caught in an infinite loop where units kept repeating the same path and never ended up reaching their destination.  I still occasionally play that game, but things like that make it much more tedious than it has to be.

I think some of the earlier screenshots reflect the fact that I was trying to remake civ 2.  I might still attempt to do that one day, because I guess i dont learn (and I really want a more streamlined version of that game). What I have now has strayed from that idea though.  I don't know if I do myself any favors by inviting that comparison.

The basic premise is similar for sure. You start off on a randomly generated map at the dawn of civilization.  The map has tiles, and tiles each have a certain amount of food and production.

You start out with one city, and your city works its surrounding tiles (the amount of tiles it can work depends on the size of the city), basically consuming the food and production on the tiles its working.  

You meet neighboring nations and make freinds / wage wars, all while trying to survive as a civ and advance through the ages.

Cities use food to grow larger, allowing them to work more tiles.  With production, each city has a production queue, and there are units, city improvements, and wonders that you can build there.

Cities also generate science (used to research technologies) and gold (units cost gold in maintenence, province improvements cost gold in maintenence, city production can be rushed with gold).

The Government system isnt implemented yet, but it too in part is more or less how it works in Civilization II.  You have a government type which provides a base set of values for unit maintenance, city science output and city gold output.  I'm also going to borrow the government sliders, as I think it provided a much needed mechanism to have your civilization quickly change tactics.  I'm sad they got rid of this in later versions.

Every system above (other than govt) is more or less implemented and working. Some systems like technology work but are filled with temp data only meant to show that the code works.  

What i think are the main differences:

1)  How turns are processed.  Civ is obviously turn based.  This works really well for the early and mid game, but when you reach the end game it becomes tedious to move all your units around (at least in my view).  

It also becomes a waiting game.  I haven't played civ 6, but I feel like turn wait times have gotten longer and longer in each new version.  I seriously hate waiting for the AI to process its moves.

In civ 5, turns aren't even instant at the very start of the game, and I have a pretty good computer.  What is the AI doing at turn 5 to make me wait?  It boggles my mind.  

My attempt at solving these two issues has been to make the game semi-real time.  The game still has discrete turns where the game world is advanced, but that now happens at a set interval of (currently) 1 turn every 600 milliseconds.  As a result there are a lot more turns in this than there are in civ, but youre expected to do a lot less in a turn in this game.

I try to make it reasonable in that the game automatically pauses for you when you enter into city mode. You can also set the pace to be slower if you want, and can pause at any time by clicking a button up top.

This forces me to write an AI where the turns are ready in under 600 milliseconds.  I'm convinced its possible to write a good AI with that constraint.

2)  The distribution and blending of tile types.  The goal here is to make city placement choice less a matter of looking at the math (which is something I do in civ but have never loved) and more a matter of gut feeling.  

I tried to write about this in one of the above posts.  There are a base set of tile types (grass, desert, forest, ocean, plains) which each have a distinct food and production outout.  At map generation these tile types are placed on the board, and then an additional pass is done which averages the food / production outputs with that of their neighbors.  The same is done for the tile color.  In addition to that, one further pass is done across all the land tiles where they're either assigned a bonus to food output (tile becomes a lighter shade), production output (tile becomes a darker shade), or no bonus.  

The tile colors reflect the food and production of a tile surprisingly well, which is something i didn't think I'd be able to pull off.

The downside here is that its potentially very confusing and hard to explain to people.  I've never actually talked to anyone about this to verify that I'm not insane, but I like it enough that I don't think it'd change my mind.

It might also be a nightmare for people who are color blind, which is unfortunate.
 
3)  Leader system.  This is still being fleshed out but I'd like it to work very similar to how generals work in Rome Total war 1.  

Basically, you can consruct a building which gives the units you construct at that city a general.  The general is currently a simple multiplier to your armies power.  Generals would have a rating from 1 - 10, which is where the multiplier would come from.  Youd be able to upgrade your building to increase the chance of spawning better gemerals.  Your generals ability would increase via fighting battles.  I want the management if this to be pretty hands off, similar to how it was in rome 1.

Generals would have a lifespan, lasting a certain number of turns before they die of old age.  

I like this because it makes war a potentially time sensitive matter, where you might have a great general and want to make use of him until he dies of old age. Technologies would exist which increase leader lifespan.

The reason i came up with this system, though, is because i want to model civilization leaders in the same way.  Your goverment has a head of state, and you should be able to constrict am army with your civilizations leader in command.  I'm thinking the rating for this unit should tend to start higher than normal generals.  

Similar to rome 1, if your next leader is poor, you face risk of rebellion.  I want rebellions, and I want them to be driven by succession crises.  Im thinking different government types would have different methods of handling your leader.  Perhaps you wouldnt have a leader available to command an army under a democracy, for instance.

Im hoping the result of this is for large empires to fracture on the event of their leader dying in a battle, or perhaps a capital being sacked.

This is probably too ambitious.  But it's what i want to happen.

4)  Nuclear Wars.  This is the first difference I decided on, and partly where the name comes from.

Years ago I modded civ 2 so that you can not construct a defense against nukes.  It makes the game much better in my view, and i am going to go full throttle on that here.  Nukes are the great equilizer for the end game.

If anyone actually read all of this, I commend you. 

[VampireSquid]

Wow, you are very ambitious sir!

I like the nuke end-game.  It's an interesting dynamic.

The one thing I am wondering now is if you are building a civ game, why do you need to pre-generate it packed with cities.  Perhaps that will come out as you release more details.