Right now I'm trying to figure out what I'm going to do for some of the required Steam marketing images.  There's a gallery below of possible header images to use for steam (it's that small image which appears to the right of the videos / screenshots). I guess my question is do any of these work or could they work with some tweaking, or should I do something else for this? I should add that if i decide to use one of those images i'd actually go through the effort of centering or aligning the text better

https://imgur.com/a/n6orpYa

Added an initial batch of sounds and upgraded some of the graphics.  Also working on a very simple meta-game surrounding the fights, which is a view of the galaxy offering you planets to fight over. 

I made a main menu, though once again the compression on the video doesn't do it any favors





You have to be in 1080p and fullscreen to notice it but there's a particle system simulation going on in the background that you can subtly interact with.

I replaced the rectangles representing the player with an active ragdoll.  This is a super early first pass, and honesly just about everything in this video needs multiple additional passes.  For the ragdolls specifically, right now they're ingame and reacting to the flight physics of the player.  They also orient themselves to the terrain if they detect they're going to collide soon. 

I need to animate them for charging energy attacks, melee (winning and losing), landing on the ground, and some flailing for when they're being knocked back.  I've been reading and playing around with forward and inverse kinematics, I'm thinking I should be able to come up with something decent.  It helps that the characters are super small and move very quickly, so you're less likely to notice imperfections. 

It looks like I accidentally made a lighting system

I'm playing around with what to do for the background. This geometry wars style grid is one of the experiments. I don't know if I'm going to keep it in as it makes it pretty hard to read the screen

Thanks!  Yeah, you're right about it being almost like a liquid.  It's a technique used in a lot of 2D games for water, I just tweaked it a bit to try and make it behave as a solid.  Still needs some work as it's probably still too liquidy, but I kind of like it.  

Having it instantly deform rather than gradually is an interesting idea, I think I'll try that out for higher impact speeds.  

Another video

Finally got around to implementing deformable terrain for this.  I'm honestly amazed that it works as well as it does. 





The video would be longer but I ran out of disk space while recording.  Also, the long black screen in the beginning is OBS, for some reason it takes a while to start capturing frames when I switch to fullscreen.

Anyway, for a repeat explanation on what it is, it's loosely based on the combat in DBZ. You control a very tiny and fast square. It can fly / teleport and shoot energy attacks.

I'm the yellow dude in this video. The circle around me is how much energy I have. Flying, teleporting, and energy attacks drain energy. Energy automatically regenerates after not using any for a short period of time. Energy regenerates 2 times faster if you're (more or less) stationary.

If you fly into the opponent square, a melee collision happens, and the loser gets damaged and knocked back. The winner is determined by whoever was moving faster in the opponents direction. It's all about momentum.

If anyone has any ideas on a name for this thing, I'm all ears.

Getting closer to where I want it to be.

Here's a video in which I control a very tiny and nimble square. It can fly / teleport and (not implemented but eventually) shoot energy beams / energy balls / lazers.

I'm the yellow dude. The circle around me is how much energy I have. Flying and teleporting drains energy. Energy automatically regenerates after not using any for a short period of time. Energy regenerates 3 times faster if you're completely stationary.

If you fly into the opponent square, a melee collision happens, and the loser gets damaged and knocked back. The winner is determined by whoever was moving faster in the opponents direction. It's all about momentum.





On the list of things I've done since recording this video
-  Added a somewhat reasonable camera instead of the stationary one shown in the video
-  Improved AI's use of teleports so as to not unproductively zig-zag around

 On the list of things I think would be cool to do
- Improved collision detection / melee resolution. It's a bit janky in the video, but I know what I should do to improve this.
- Add malleable / destructable terrain (basically integrate the code from the second part of the video in the first post)
- Add energy attacks
- Make it look pretty

On the more unreasonable end of things I'd like to do
- World generation. Instead of the level taking place on a flat surface like in the video, it'd be cool if it took place on a rather large circular world populated with enemies. Gravity would point towards the center of this circle.
- Add rpg elements, where your character can level up to learn new attacks / gain more energy / speed.
- Add rogue-lite elements, so that when your character dies, you start over with a new character on a newly generated world.

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 pixels) 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.

Super late reply, but I didn't see the new posts until just now!

Okay,read it!

I'd love to see how you'll handle unit movement, it was my biggest problem in middle/late game in civ and total war games. There's just too many units for me to care about. First war is fun, little wars are fun, but producing units in all cities and moving them all is hell... Maybe a "population limit" taken from RTS games would work Shocked

Thanks for taking the time to read it over, means a lot to me.  I actually added a population limit in the other day.  It's funny, I never really realized the similarities between 4x and RTS games before trying to make a 4x game, but there are definitely a lot of similarities.

I heard that 4X games are one of the most difficult to code. Is it true? Game looks good so far, keep it up!

Thanks for the kind words.  I guess it depends on what 4x game you're making, and what type of game you're comparing it to. I don't necessarily think 4x games are more difficult to code.  There are some nice aspects about it, like I don't have to worry about syncing complex physics over the 'net for instance.  Prior to starting this, I thought the hardest part about it would be creating a good AI, but so far that's been going surprisingly well.

But yeah, every day this gets a little closer to completion.  The aesthetics have been pretty stable for a while now, but I recently decided to do another pass over it, and I think I'm finally happy with it.  I messed around with the colors a bit, and solved some usability issues like it occasionally being hard to tell the difference between land and coastal tiles.

Well, everyone only starts with one city.  The city spots are generated up front so that at runtime it's quick to figure out where the next city should be.

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. 

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

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.

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.