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

Author Topic: It Usually Ends In Nuclear War  (Read 42196 times)

0 Members and 2 Guests are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
AW: It Always Ends In Nuclear War
« Reply #30 on: January 11, 2015, 10:26:24 pm »
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. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #31 on: January 11, 2015, 10:43:43 pm »
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.

Spirro

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #32 on: January 11, 2015, 11:07:32 pm »
     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.
« Last Edit: January 12, 2015, 12:25:47 am by Spirro »

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: It Always Ends In Nuclear War
« Reply #33 on: January 11, 2015, 11:37:25 pm »
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.
Back to C++ gamedev with SFML in May 2023

Mörkö

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #34 on: January 12, 2015, 12:26:16 am »
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.

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: It Always Ends In Nuclear War
« Reply #35 on: January 12, 2015, 07:53:52 pm »
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.
« Last Edit: January 12, 2015, 08:14:28 pm by Jesper Juhl »

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #36 on: March 21, 2015, 07:10:33 pm »
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. 



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

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



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

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



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

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

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #37 on: June 06, 2015, 03:17:08 am »
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


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.


Ztormi

  • Jr. Member
  • **
  • Posts: 71
  • Web developer by day. Game developer by night.
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #38 on: June 07, 2015, 01:28:51 pm »
Looks great! I know it's just an alpha but I really can't wait to play this :)
« Last Edit: June 07, 2015, 01:37:50 pm by Ztormi »

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #39 on: June 07, 2015, 10:19:10 pm »
Thanks for the interest!  I'm trying pretty hard to get it done, all in good time I suppose.

GAMINGBACON97

  • Newbie
  • *
  • Posts: 42
    • View Profile
    • Email
Re: It Always Ends In Nuclear War
« Reply #40 on: November 09, 2015, 05:02:04 am »
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.

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Always Ends In Nuclear War
« Reply #41 on: November 10, 2015, 04:46:48 am »
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 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.



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. 

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Usually Ends In Nuclear War
« Reply #42 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


Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: It Usually Ends In Nuclear War
« Reply #43 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
{
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.
« Last Edit: June 19, 2017, 04:47:36 pm by Sub »

MrOnlineCoder

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: It Usually Ends In Nuclear War
« Reply #44 on: June 19, 2017, 11:16:29 pm »
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)
« Last Edit: June 19, 2017, 11:18:28 pm by MrOnlineCoder »

 

anything