Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Sub

Pages: 1 2 3 [4] 5 6 ... 11
SFML projects / Re: It Usually Ends In Nuclear War
« on: October 21, 2017, 12:28:25 am »
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.

SFML projects / Re: It Usually Ends In Nuclear War
« on: October 20, 2017, 06:28:14 am »
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.

SFML projects / Re: Mad Maze Attack
« on: October 20, 2017, 12:21:54 am »
Visuals took a minute for me to process but it does have a certain charm to it.  I'm not an artist, but for what it's worth, I think the characters / animations are well done.  I think you guys would benefit from having a better ground texture though.  I feel like the green / yellow patches in particular don't match the quality of everything else.

I'd also echo what Mario said.  I think you guys would benefit if you came up with a single sentence that describes the game and how it plays. 

SFML projects / Re: This Grand Life
« on: October 20, 2017, 12:11:58 am »
Don't really have much to say other than that this looks great.  It reminds me a bit of the game Drug Wars which I had a ton of fun with when I was younger.  Keep it up :)

edit:  Any chance this will also come out for Linux when it's done?

SFML projects / Re: Screenshot Thread
« on: October 15, 2017, 06:32:52 am »
Civ-like game I've been making.  Every day a little closer to completion.  I think I'm finally happy enough with the aesthetics.

General discussions / Re: SFML 3 - What is your vision?
« on: August 13, 2017, 11:59:46 pm »
This is a nice thread.

The only thing I want is better multi-monitor support, as I've run into a few issues with this on both Linux and Windows.   Sounds like this is already on the agenda though. 

SFML projects / Re: It Usually Ends In Nuclear War
« on: July 15, 2017, 12:02:21 am »
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.

General discussions / Re: The Steam Direct fee is $100
« on: June 25, 2017, 04:59:49 pm »
Damn.  Figures.  There was a lot of greenlight submissions for asset flips.  I guess it makes sense that all of that stuff is now just going to go directly to Steam. 

Looking good  :)

General discussions / Re: The Steam Direct fee is $100
« on: June 24, 2017, 09:12:30 pm »
How have people been abusing it? 

SFML projects / Re: It Usually Ends In Nuclear War
« on: June 20, 2017, 03:32:23 am »
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)


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. 

SFML projects / Re: It Usually Ends In Nuclear War
« on: June 19, 2017, 04:36:09 pm »
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: [Select]
// 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
    // 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);

    // city locations are calculated for each continent on map generation and cached in the above array
    void onMapGeneration()
        for (int i = 0; i < NUMBER_OF_CONTINENETS; 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)

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

General / Re: SFML Icon - Pin To Taskbar Problem - Bug???
« on: June 17, 2017, 08:35:02 pm »
Not sure if there's a more generic way to do this, but for Windows, you need to create a resource file specifying your icon and add it to visual studio.  Then when you compile next, it'll be added to the exe.  The replies here should help you out


SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: June 11, 2017, 06:00:27 am »
I love the custom text you've made.  It really fits the game nicely.  Well done!

SFML projects / Re: It Usually Ends In Nuclear War
« on: June 11, 2017, 05:47:48 am »
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

Pages: 1 2 3 [4] 5 6 ... 11