SFML community forums
General => SFML projects => Topic started by: Sub on December 07, 2013, 02:17:11 am
-
It Usually Ends In Nuclear War
- 4x civilization building game in development for Windows and Linux
- Heavily influenced by Civilization II, Alpha Centauri, Call To Power, and Rome Total War. To a lesser extent Endless Space and the Europa Universalis series
- Currently prealpha
- Design goals.
- Keep microamanagement to a minimum yet allow for larger empires than recent civ games.
- Not turn based, but rather semi-real time. When the game is unpaused, turns will occur at a set-interval of roughly one turn every 500 milliseconds
- Revolutions / collapsable civilizations
- Interesting end game
- Huge gallery (1000+) of screenshots I've been maintaining throughout the project. (http://www.it-usually-ends-in-nuclear-war.com/screenshots/)
Screenshot from October 15, 2017
(https://i.imgur.com/WjI0DVK.png)
Something more recent
(http://it-usually-ends-in-nuclear-war.com/screenshots/2018-01-20.png)
-
Some of the images are taken from other games / concepts which I wanted to try to emulate
So it's difficult to tell what you did... But ignoring that, some of the images look graphically quite good. Civilization is a huge project, have you already thought about using the map generation for something smaller? Especially since you seem to have already put a lot of effort in it.
-
edit: I originally had some screenshots from other games in the gallery which I was using as inspiration for how I wanted the game to look. This post was originally declaring the images which weren't from my game, but I've since removed all such images from the gallery.
-
Thanks for declaring the images!
I've also made the experience that after some time, you would rather re-implement functionality in old projects than reuse it in newer ones -- especially if it's one of the first projects, where code and everything was horrible. With some experience, ond would probably do a lot in a different way. The important knowledge are the ideas behind it (and possible algorithms), not necessarily a concrete implementation. That's also why I tried to document these parts well, so that I wouldn't have to re-learn everything in case I would use something again.
Anyway, it's still interesting to look at older code after some time ;)
-
Bit of a late response, but yeah, I constantly find myself going back to older projects to reuse code.
I spent the past few days working on taking my existing code and gutting a lot of functionality that I don't need anymore.
One of the main things I want to do is show the player the more macro side of history, so I made the decision to increase map size by quite a bit. The previous maps were 70x75 -- The new maps are 280 x 300. That's a change from 5,250 tiles to 84,000 tiles. I think if we compare this to the real world it comes out to around 50 miles per tile, but my math might be off on that?
The old game:
(http://i.imgur.com/9EGY2tE.png)
First I increased the number of tiles to 84,000 and decreased the physical size of the tiles (I think they were previously 64x32, now I think they're 16x8?)
(http://i.imgur.com/EhAbFDO.png)
My game has a boolean value where I can turn tile textures on / off. I decided to turn textures off, as the new tiles are much too small for it to make sense.
I had a pseudo 3d effect (was trying to go for something akin to alpha centauri) in the old game which doesn't work so well with this new set up. The screenshot above is actually the first attempt I made to scale it down, because it looked even more ridiculous than that. The second try was much more reasonable:
(http://i.imgur.com/WxOhEEO.png)
Decided to get rid of the ocean floor. I never really did quite like the way it looked:
(http://i.imgur.com/9xrrn3Z.png)
I think around this point I decided to get rid of the tile height completely. It can be turned back on by uncommenting one line, but I think it's for the best with it off.'
The zoomed out view shows that the map generation algorithm needs some tweaking. It's designed to work on much smaller map sizes (5250 tiles vs 84000!)
(http://i.imgur.com/WhpCHzk.png)
I didn't want to create a new algorithm for generating maps. I decided that the easiest solution would be to generate a map for the old map size of 5250, and then just scale it up to a larger map size. The map is scaled up by a factor of 4 compared to the old one, so I'm basically just treating every one tile in the old map generation algorithm as a group of 4x4 tiles in the new map.
Whew it compiled! But it didn't quite work...
(http://i.imgur.com/Yc7zFot.png)
(http://i.imgur.com/0QDPBnm.png)
Closer, but what the hell is going on with the water and the topright side of the map?
(http://i.imgur.com/FTAQoBQ.png)
Fixed the water, but something still isn't quite right. I am happy at this point, though, because the general theory I had seems like it'll work.
(http://i.imgur.com/TfhaVfX.png)
There we go.
(http://i.imgur.com/dGwFlfc.png)
Now I just need to make the shoreline not so rigid..
Whoops:
(http://i.imgur.com/kL9zCUb.png)
Better...
(http://i.imgur.com/CMBRa6J.png)
So that's going to be the default camera view. Conveying information with such a high view is going to be a bit of a problem. I need to figure out how to display the locations of cities, as well as nation borders. I think maybe having a red outline around tiles with cities might be the way to go. I tested it out by randomly outlining tiles here, but I'm going to sleep on it:
(http://i.imgur.com/SR1E2jV.png)
I'm thinking if you mouse over a tile with a red outline, maybe a tool-tip like popup will appear with the city name and some more information.
Also tested to see how bad the height looks if it's turned on again:
(http://i.imgur.com/nqohjlo.png)
Pretty sure I'm going to leave it off as it clutters the game.
Tomorrow I'm going to work on the generation of tile types since that's still using the algorithm designed for small maps. For the record, though, the tan tiles are desert, white tiles are ice, and the green tiles are grassland.
I'm also going to work on adding in rivers to the game. I'm hoping to start and finish both of those things tomorrow.
If anyone made it this far, let me know what you think. Also let me know if I used too many pictures, I'm afraid that it's going to be a pain to load for people with slower internet.
-
Very cool that you continue this project, even if it will go into another direction. :)
I'll certainly be check back here to see how it turns out, not quite sure if I understand the interactive simulation you're aiming for, but it sounds interesting.
I'm thinking of posting regular updates here, although I'm worried that it might be considered spamming the forum, so we'll see how that goes.
That's fine, as long as you don't post like 5 updates one after the other in a day. :)
Also let me know if I used too many pictures, I'm afraid that it's going to be a pain to load for people with slower internet.
I like the pictures, but then again I've fast internet.
Personally, I'd still be interested in some of the code, I really like games with such terrains.
-
Looking good. :)
-
I've been busy with moving, getting a job, and life in general. In news completely unrelated to anything, I saw this post (http://codegolf.stackexchange.com/questions/33172/american-gothic-in-the-palette-of-mona-lisa-rearrange-the-pixels) making its way around the internet and decided to give it a try. I made an attempt at it, and, well, I love what you can do with computers. (http://i.imgur.com/ju75Dkn.jpg?) I used SFML to grab pixels and display the results.
As for the topic at hand, I haven't done too much with this since the last update. I did get a chance to play around with tile type generation this weekend, though.
I'm not sure if what I've come up with is embarrassingly bad, but I'm going to show it regardless. The current thinking is that there's going to be 4 discrete tile types -- Desert (represented by tan tiles), Ice (represented by white tiles), Grassland (represented by light green tiles), and forest (represented by dark green tiles). Tile types are going to effect food output, the culture that develops in cities, and resource distribution (ie: oil being more likely in desert / ice areas).
(http://i.imgur.com/OTYXfmd.png)
(http://i.imgur.com/dEe5kAy.png)
I'm open to any suggestions on how to make it look better.
-
Not sure it would be really handy to play with (maybe with view rotation ?) but I like your pseudo-3D effect, kinda cool :D
Good job so far
-
It looks very good. :)
What kind of algorithm do you use to generate the map ?
"Bravo!" for what you can do with computers .
PS : Felicitations for your apparition on RPS !
-
Thanks!
I'm doing this from memory, but from what I remember, this is the algorithm:
- Start with a small board (70 x 75 tiles)
- Make every tile water
- Pick a tile at random and make it land.
- Add that tile to a list we'll call tiles to check.
while the number of land tiles is less than some arbitrary number (I think I made mine 35% of the map). . .
For every tile in the list we made we look at each of their neighboring (i think only water) tiles to determine whether to change them to land or keep it as water. The closer this tile is to the first tile that we chose, the greater chance it has of becoming land. If we decide to make a tile into land, we add it onto the list of tiles to check. Tiles that stay as water don't get added to this list. Once all neighbors for a particular tile are checked, that center tile gets removed from the list. When the list is empty, you can repeat the process with a new starting tile. Repeat this entire process until we hit a desired number of land tiles.
I then translate this small board onto the larger board, which I described in one of the above posts.
It seems to produce reasonable results, and you have a bit of control over things like the size of a landmass (adjust the weight on distance), the % of the map that is water (adjust the # of desired land tiles), you can dictate certain areas of the map that are more likely to contain water/land (for example, if you want a map with a gigantic ocean in the middle, you can favor starting tiles that are far away from this area), you can control how many continents appear on the map, as well as the size variance between continents (that is, how large the largest continent is in relation to the smallest) by changing the distance weight for each continent you place.
For the height, I did something that was roughly this -- All tile corners are at height 0, and there's a list of corners that are locked and will no longer be heightened, and a list of unlocked corners. All corners start out unlocked. First lock all water corners. Iterate over all remaining unlocked corners and randomly either heighten a corner if allowed (i.e. this will not make it too high over any of its neighbors) / do nothing if not allowed, or lock the corner. Keep iterating over the unlocked list until it's empty.
-
Thanks for writing this. :)
Why using a smaller board, then converting ?
Your height generation tend to produce uniform height variations ( the whole map looks like mountains ), is intended behavior ?
For suggestions, maybe make the coastal water tiles (?) brighter/lighter .
Is it possible to hide the tiles borders ? I would like to see some screenshoot without.
keep up the good work! :D
-
Once again, thanks for the interest! I appreciate it a lot.
I made the map generation algorithm a while ago. It was designed for a board that has around 5,000 tiles. I recently decided that I wanted larger maps, so I went and increased the map size to around 80,000 tiles. The map generation algorithm no longer produced good results after that change, though. All the maps looked like this (http://i.imgur.com/WhpCHzk.png). The easiest solution was to just generate the map for the smaller board, and then scale it up to the larger board. This has the added benefit of being quicker than trying to generate a map for the size that I'm using.
The height generation needs some work. I don't mind the behavior too much, but it could use some work.
As for making the coastal tiles brighter/lighter, I definitely agree with you there. It looks something like this right now
(http://i.imgur.com/QrqfMDG.png)
I'm still not entirely happy with how the tile types look and are distributed, but it's getting closer.
-
Creeping slowly toward playability...
(http://i.imgur.com/WTJ9ep3.png?)
-
Cool :)
-
I like how this is looking. :)
-
I'm getting a "Civilization" feel from this - which is a good thing ;)
Looks like it's progressing nicely..
-
Terrain is wonderful!
-
Nice!! ;D I'm looking forward to future updates
-
I’m still working on this. I admittedly don’t have much progress to show at the moment, but I am putting in a great deal of time and effort. The hard part is coming up with a design that I like
(http://i.imgur.com/3DCsrsR.png)
Graphically I like the direction I’m headed, but there’s definitely something not quite right about it. I’m about as far from an artist as one can possibly get, so I think what I’ve done so far is pretty good, but like I said, it’s still not there yet. As you can see, the current thinking is that the entire game is going to have a textureless look, possibly even going as far as to have no sprites or external images used at all. This serves a dual purpose - It takes some pressure off of me having to somehow get high quality art assets, and I also think it gives off a unique stylistic vibe.
Hopefully I’ll have some actual progress to report soon.
-
It's nice to hear that this project is still going! :)
Btw. you need to use the public Dropbox links, because currently we can't see the first three images (same for your blog post).
And if you want a certain width to be applied to the images you can do so with [img width=700]url[/img].
It's kind of normal to get frustrated when developing and working alone on a project can be very tedious. What helps me personally a lot, is having a group of equal or similar minded people to chat with, which is probably the main reason I keep hanging around in the #sfml IRC channel (http://www.sfml-dev.org/community.php). There are often quite interesting discussions about code design etc., but at times there are also general discussions about anything really, which then can take away your time, if you choose to chime in. Feel free to join us if you ever want to talk about your project. :)
-
Ah damn, I thought I was grabbing the public URL. Thanks for the heads up, and thanks for the invite :)
-
I implemented a pathfinding algorithm known as a* forever ago, and it miraculously still works with It Always Ends In Nuclear War after all the changes I’ve made to the code (check out the above screen; purple tiles would be the path), but I’m going to have to improve the system further if I don’t want it to grind the game to a hault.
Is your program single threaded? What about having two threads, one for graphics and one for game logic, that way the UI can remain responsive even if you need to run CPU intensive tasks such as A* on a very large graph.
I really like the visual style btw.
-
Thanks :D
It's single threaded. I'd like to eventually have it be multithreaded, but I think it's worth it to optimize the pathfinding regardless, as I think the game is going to have to calculate large paths quite a bit. Not going to lie though, a lot of the reason I want to do it is also because I like working on that type of thing.
edit: It's also the type of thing that's almost entirely self contained, so I can play around with it and have it be useful regardless of what changes I make to the rest of the game.
-
Hi !
I'm looking at your project since a long time, and I'm again asking myself, what are your technique to generate the map ??
Your world looks very realistic and if you want to make a game like Civilization, you can be sure I'll try it :)
-
Thanks, I really do appreciate it :).
There are a lot of ways to go about the map generation. I'd like to eventually have multiple map generation algorithms, but for now I'm doing something reasonably simple. I'm doing this from memory, but from what I remember, this is the main algorithm:
- Start with a small board (70 x 75 tiles)
- Make every tile water
- Pick a tile at random and make it land.
- Add that tile to a list we'll call tiles to check.
while the number of land tiles is less than some arbitrary number (I think I made mine 35% of the map). . .
- For every tile in the list we made we look at each of their neighboring (i think only water) tiles to determine whether to change them to land or keep it as water.
- The closer this tile is to the first tile that we chose, the greater chance it has of becoming land.
- If we decide to make the tile into land, we add it onto the list of tiles to check.
- Tiles that stay as water don't get added to this list.
Once all neighbors for a particular tile are checked, that center tile gets removed from the list. When the list is empty, you can repeat the process with a new starting tile. Repeat this entire process until we hit a desired number of land tiles.
I then translate this small board onto the larger board, which I described in one of the above posts.
It seems to produce reasonable results, and you have a bit of control over things like the size of a landmass (adjust the weight on distance), the % of the map that is water (adjust the # of desired land tiles), you can dictate certain areas of the map that are more likely to contain water/land (for example, if you want a map with a gigantic ocean in the middle, you can favor starting tiles that are far away from this area), you can control how many continents appear on the map, as well as the size variance between continents (that is, how large the largest continent is in relation to the smallest) by changing the distance weight for each continent you place.
That being said, I'm sure there are better ways to go about it. A lot of people use perlin noise (http://en.wikipedia.org/wiki/Perlin_noise) to generate random maps. I found another project on the web a few weeks ago which generated similar maps in Javascript. You can check out the results, code, and a writeup of that here (http://experilous.com/1/blog/post/procedural-planet-generation) if you're interested. I actually highly recommend it, it was really interesting.
For the height, I did something that was roughly this -- All tile corners are at height 0, and there's a list of corners that are locked and will no longer be heightened, and a list of unlocked corners. All corners start out unlocked. First lock all water corners. Iterate over all remaining unlocked corners and randomly either heighten a corner if allowed (i.e. this will not make it too high over any of its neighbors) / do nothing if not allowed, or lock the corner. Keep iterating over the unlocked list until it's empty.
-
Happy new year! Let's get to it.
The Civilization series used to have a flaw in that the minimap would reveal exactly where you were on the map. It wasn't a huge deal, but it could be abused in some situations. For example, if you spawned near the top of the map, you'd be able to see that and plan accordingly. Scouts would be sent south, settlers would be sent south, and no time would be wasted exploring the north of the map. I'm not sure what version of Civilization fixed this, but it was fixed by having the minimap zoom in to fit the area explored.
I'd like to have that same need for exploration in IAEINW. You should have to explore or look at the terrain type to figure out where you are on the map. Up until today, however, you were able to abuse the sides of the map to figure out where you were in the world. Check out this old screenshot to see what I mean.
(http://i.imgur.com/2sx1c0E.png)
A few months back I sort of fixed it by only drawing a side of the map if a player discovered a tile on that edge of the map, but this wasn't perfect. The entire side was still drawn, so you could gauge exactly how large the map was and where you were in it once you discovered one edge. I've been wanting to fix this for a while now, and today I finally got around to it. I'm now only drawing the edges of the map between the furthest explored reaches of the edge. Check it out to see what I mean
(http://i.imgur.com/UWrounb.png)
(http://i.imgur.com/WvZf51x.png)
(http://i.imgur.com/7nOJakR.png)
(http://i.imgur.com/wY024vL.png)
(http://i.imgur.com/55OQyfz.png)
There are more important things I could be working on, but it's the little things that make me happy. And as an aside, I think I've now got all the pathfinding stuff worked out.
-
I worked a bit today on the code for getting armies (units) working, and then got bored of that and decided to get the game up and running on Linux. SFML is awesome -- It basically worked out of the box.
(http://i.imgur.com/wyxvOKg.png)
The low FPS is from the screenshot program freezing everything.
-
Cool! :)
Yes, if one uses platform independent code and libraries which support multiple platforms, there's usually not much if anything one has to adjust.
-
Yeah, I was just surprised at how easy it was. I suppose I was afraid that I might have some code which wouldn't work.
I was looking for a Linux IDE which was similar to Visual Studio, and the top reply for this (http://stackoverflow.com/questions/24109/c-ide-for-linux) SO thread recommends not using an IDE, but that seems crazy to me. I just decided to use MonoDevelop since I've used it before and it works fine.
-
Hehe, well alot of Linux users want to optimize their environment to maximum and this can easily be done if your whole system is your IDE and using editors like Vim.
But there are also "normal" IDEs on Linux, e.g. KDevelop, QtCreator, Code::Blocks, etc. ;)
-
Is that what your setup is like?
I'm sure it's a great workflow once you get everything set up and you're used to it. Too much of a hassle for me to take that on right now though.
-
Another IDE people don't mention as often is CodeLite. It is also cross platform and, imo, better than CodeBlocks. It is less intuitive in that you don't get a lot of check box configurations. You need to know the compiler console commands and such and do things a bit more manually, but the IDE itself for me is less intrusive than CB.
A couple of other options would be Geany(kind of an IDE/text editor hybrid) or Kate(text ed)/Sublime(text ed).
As for your current project, I have been watching this on the forums for a while now. I've been working on pgc content on a smaller basis for dungeon/town building. Slow going, but making progress. I'd be interested to know a bit more of how your world gen work is progressing as I'll be moving on to that at some point.
**EDIT.... Forgot about one I found recently. Notepadqq is the linux port of Notepad++ on windows. Pretty nice text ed with multiple plugin options.
-
NetBeans has been extremely good for me after I was already used to completion and UI in VS 2008 and 2010. No other IDE I tried came close to it in terms of features and power.
-
If you really need a full blown IDE then KDevelop is a solid choice. But personally I just use the "editor component" Kate alongside a terminal window:
*Write some code* -> *alt-tab* -> clear && make && ./start
Nice and simple work flow. The only annoyance I've had with Kate is when changing git branches, every changed document will show a dialogue asking to reload the file or save as new.
-
Personally I just use Emacs.
It's an excellent editor that works the same across platforms, so I get the same editing experience regardless of the OS I'm working on.
git.el provides very nice git integration inside Emacs (yes, Magit can do more, but I don't quite grok it yet).
My build system of choice is SCons (also cross-platform/compiler agnostic) and with a simple tweak to Emacs's 'compile-command', whenever I press F9 it runs scons and then launches my app. If there are any build/link errors they show up in the *compile* buffer and hitting <enter> on a line takes me straight to that source file/line/column.
For source navigation etags does the job nicely (and is updated in the background whenever I do a build).
GUD takes care of integrating gdb into Emacs for a nice debugging experience.
Community interaction through IRC happens in a Emacs buffer as well of cource courtecy of 'erc'.
And when I need a shell to test out something special, then 'M-x shell' happily opens one for me in a Emacs buffer.
Documentation for standard library, OS and other libraries can of course also be read inside Emacs.
There's a nice cross-platform IDE for you right there :-) and it has the added benefit of not hiding the individial working parts too much from you.
Maybe I'm just old-fashioned, but this setup works well for me and I have a hard time seeing what extra benefit "modern" GUI centered IDEs bring.
-
Thanks for the suggestions guys :)
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.
(http://i.imgur.com/QKgNyxy.png)
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.
(http://i.imgur.com/y4aOqsM.png)
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.
(http://i.imgur.com/MV05jVD.png)
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.
-
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 (http://i.ytimg.com/vi/vuEM9E6dU30/maxresdefault.jpg))
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.
(http://i.imgur.com/2vWOn4M.png)
-
Looks great! I know it's just an alpha but I really can't wait to play this :)
-
Thanks for the interest! I'm trying pretty hard to get it done, all in good time I suppose.
-
DUDE!, looks cool man. I have a question for you, how are you loading your maps? I'm curious because I'm working on an RTS that needs a good efficient way to load some maps, and google doesn't help, but you seam to have it down.
-
DUDE!, looks cool man. I have a question for you, how are you loading your maps? I'm curious because I'm working on an RTS that needs a good efficient way to load some maps, and google doesn't help, but you seam to have it down.
Thanks!
For loading maps, it depends on what you mean. I'm generating a different map every time the program starts. I have a class called Tile, which stores (among other things) a number representing what tile type it is (0 for grass, 1 for water, etc). I'm creating an array of thousands of tiles, and each tile in this array gets assigned a type at the start of the program based on a a pseudo-random number generator and some logic.
Because of the way computers work, if I want to generate the same map again, I just need the number (usually called the seed) that the random number generator started with and used to generate the map the first time, and then it'll spit out the same map back. This is because computers can't do true random number generation, it's just making calculations based on the first number that we gave it. So for me, saving my entire map (at least the terrain portion of it) is as simple as saving a single number.
Most RTS games have maps that someone created before hand, though. I know a few people use Tiled (http://www.mapeditor.org/) to create maps, and I've definitely seen a few examples around the forum of people using it with SFML. I can find you some links if you're interested.
(http://www.mapeditor.org/img/screenshot-terrain.png)
I've never used Tiled before, but pictured there is a screenshot of what you can do with it. You can see that each map is just a grid of tiles. I imagine that after you're done creating a map in Tiled it will save its map information to something like a text file. So for a super simplified example, if you made a map like that, Tiled might spit out a text file which looks like a bunch of numbers. Each tile might have a certain amount of these numbers associated with it, such as what sprite to use, whether or not the tile is walkable, or whatever arbitrary information you want a number to convey. When it comes time for your game to read this data, you would open this text file and create your map based on what's inside.
-
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 (http://www.it-usually-ends-in-nuclear-war.com/screenshots/2017-03-04%205.png) 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
(http://i.imgur.com/kikzJFT.png)
Screenshot fro a few months ago. The map is completely flat here
(http://www.it-usually-ends-in-nuclear-war.com/screenshots/2017-03-26%201.png)
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
(http://i.imgur.com/ltoqVrc.png)
-
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
(http://www.it-usually-ends-in-nuclear-war.com/screenshots/2017-06-19%203.png) (http://www.it-usually-ends-in-nuclear-war.com/screenshots/2017-06-19%203.png)
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.
// 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.
-
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)
-
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.
(http://www.it-usually-ends-in-nuclear-war.com/screenshots/2016-12-08%203.png) (http://www.it-usually-ends-in-nuclear-war.com/screenshots/2016-12-08%203.png)
(http://www.it-usually-ends-in-nuclear-war.com/screenshots/2016-12-08%202.png) (http://www.it-usually-ends-in-nuclear-war.com/screenshots/2016-12-08%202.png)
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.
-
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.
(http://danielpetersen.io/images/Screenshot%20from%202017-07-14%2017-18-41.png) (http://danielpetersen.io/images/Screenshot%20from%202017-07-14%2017-18-41.png)
(http://danielpetersen.io/images/Screenshot%20from%202017-07-14%2017-40-16.png) (http://danielpetersen.io/images/Screenshot%20from%202017-07-14%2017-40-16.png)
(http://danielpetersen.io/images/Screenshot%20from%202017-06-21%2015-08-43.png) (http://danielpetersen.io/images/Screenshot%20from%202017-06-21%2015-08-43.png)
(http://danielpetersen.io/images/Screenshot%20from%202017-07-07%2017-30-46.png) (http://danielpetersen.io/images/Screenshot%20from%202017-07-07%2017-30-46.png)
-
Nice work! Keep it up. :)
-
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
(https://i.imgur.com/d7KFegk.png)
The WIP Tech Tree
(https://i.imgur.com/0DYUhKN.png)
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.
-
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.
-
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.
-
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.
-
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.
-
Yeah that was something I noticed. I ended up rolling my own (https://github.com/dabbertorres/threadpool), 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!
-
Ah cool. Looks like a nice clean library. Very easy to read / understand the code :)
-
Getting closer to where I want it to be.
(http://it-usually-ends-in-nuclear-war.com/screenshots/2018-01-20.png)