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 ... 7 8 [9] 10 11
121
SFML projects / Re: It Always Ends In Nuclear War
« on: July 23, 2014, 12:15:46 am »
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.

122
SFML projects / Re: It Always Ends In Nuclear War
« on: July 20, 2014, 07:03:35 pm »
I've been busy with moving, getting a job, and life in general.  In news completely unrelated to anything, I saw this post 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.  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). 





I'm open to any suggestions on how to make it look better. 

123
SFML projects / Re: It Always Ends In Nuclear War
« on: May 09, 2014, 12:45:29 am »
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:



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?)

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:



Decided to get rid of the ocean floor. I never really did quite like the way it looked:



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!)


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




Closer, but what the hell is going on with the water and the topright side of the map?



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.



There we go. 



Now I just need to make the shoreline not so rigid..

Whoops:


Better...



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:


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:


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.

124
General / Re: Game Speed Consistency
« on: April 15, 2014, 06:05:40 am »
Also, it's a good idea to cap the FPS at something reasonable.  You don't want your game running at 1000 FPS, or something ridiculous.

window.setFramerateLimit(60);

125
SFML projects / Re: Ninja teaser
« on: January 06, 2014, 02:58:24 am »
Yeah.  I was replying to Siile / trying to say I thought it was funny, I should have been more clear.

126
SFML projects / Re: Ninja teaser
« on: January 05, 2014, 08:01:29 pm »
Exit to dos?   :P

127
SFML projects / Re: Faster
« on: December 09, 2013, 11:59:25 pm »
The program can't start because MSVCR120.dll is missing from my computer. 

I downloaded the .dll and it now works no problem, but I thought you should know.


128
SFML projects / Re: It Always Ends In Nuclear War
« on: December 07, 2013, 11:11:06 pm »
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.

129
SFML projects / It Usually Ends In Nuclear War
« 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.
Screenshot from October 15, 2017


Something more recent

130
SFML projects / Re: Winter-Pong
« on: October 30, 2013, 07:54:36 pm »
Do you have any screenshots, or at least a description of what the game is?  I assume it's Pong :P

131
Graphics / Re: Anti-aliasing causing small graphical glitch?
« on: October 27, 2013, 02:34:13 am »
Using the same code from the example above

SFML 2.0 gives me a AA of 1.
SFML Nightly from 9.27.13 gives me a AA of 16.

The graphical bugs happen in both cases so that's not it.  I'm updating my drivers right now, hopefully that fixes it.

edit:  Driver update didn't fix it.  The glitch is kind of interesting though, it almost looks like a version of Conway's Game of Life with different rules.

132
Graphics / Re: Anti-aliasing causing small graphical glitch?
« on: October 27, 2013, 02:03:15 am »
I accidentally erased the line where I added an sf::Event when I was pasting it, it's now edited back in.

Anyway, I tried your test and it's giving me an AA level of 1.  I'm not quite sure why that is, but yeah.

I decided to create a project on my laptop to see if it occurs there, and it actually works fine on my laptop, so it looks like it might just be a problem with my desktop.

My desktop is an AMD FX-6300 3.50 GHz, 4 gigs of ram, with a geforce GTX 470.  Not sure if any of that is relevant.

edit:  Considering this problem didn't occur in the past on my desktop (I have some old screenshots of SFML projects that I checked), I wonder if it's because of a video card driver update?

133
Graphics / Anti-aliasing causing small graphical glitch?
« on: October 27, 2013, 01:38:33 am »
I'm either confused on how to properly enable anti-aliasing, or it's causing a small graphical bug in my program in the form of small squares that appear randomly around the screen.  This is a zoomed in screenshot that I took to show what I mean.

http://i.imgur.com/cXX5Inw.png

And here's a small test program I made to make sure the problem wasn't elsewhere in my code
Code: [Select]
#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow MainWindow;
   
    sf::ContextSettings ContextSetter;
    ContextSetter.antialiasingLevel = 16;

    const int DEFAULT_SCREEN_WIDTH = 800;
    const int DEFAULT_SCREEN_HEIGHT = 600;
    MainWindow.create( sf::VideoMode
( std::min(sf::VideoMode::getDesktopMode().width, (unsigned)DEFAULT_SCREEN_WIDTH)
, std::min(sf::VideoMode::getDesktopMode().height, (unsigned)DEFAULT_SCREEN_HEIGHT)
, 32), "Antialiasing Test", sf::Style::Default, ContextSetter);

    sf::Event Event;
    bool Quit = false;
    while (Quit != true)
    {
        while (MainWindow.pollEvent(Event))
        {     
            if (Event.type == sf::Event::Closed)
            {
                Quit = true;
            }         
        }

        MainWindow.clear(sf::Color(60, 90, 150));

        MainWindow.display();
    }
}

Anyone have an idea on what I'm doing wrong or what's causing this?  I'm using a nightly build that I last updated on 9.27.13.  I took a look at some of my old screenshots and this artifact doesn't appear to be on them, so I'm thinking it might be a recent change which causes this.

edit:  I just did a test with SFML 2.0 and it still happens, so that's not it.
edit2: This is what it looks like when not zoomed in: http://i.imgur.com/SY39cGI.png

134
SFML projects / Sins of a Hex Empire
« on: October 19, 2013, 01:59:30 am »
Sins of a Hex Empire
Disclaimer:  Due to VS2012 apparently not liking Windows XP under its default settings, this won't work on Windows XP.  It's also a poor clone of Hex Empire(http://www.freewebarcade.com/game/hex-empire/).

Download link -- http://goo.gl/wLStq7


  • Turn based strategy game
  • Your goal is to defeat three opposing AI and conquer the entire map
  • The black dots scattered across the map are cities. If you own a city, it generates one army every turn.
  • Capitals (the stars) generate two armies per turn. If you capture a capital, that enemy will be eliminated
  • Your units have two values -- armies and experience. Armies are the thin black crosses, experience is the black outline around those crosses.
  • A unit gains experience whenever it expands your nations borders
  • You only get 5 moves per turn
  • Pressing enter moves to the next turn
  • Pressing spacebar at any time spawns a new map.

I think that's about it. It was originally written with SDL, but I ported it over to SFML. That old version never had AI and never worked quite right.  I ended up drastically changing the code structure, updated a lot of old functions since a lot of my old code was terrible, fixed a bug with the pathfinding which took forever to figure out, and added in an AI. The AI is terrible, but it only has a few hours of work on it, and I don't care enough to improve it. It's managed to beat me a few times so I figure that it's good enough for a base line level. It's still mostly retarded though. If you want a harder challenge you can artificially handicap yourself by picking a terrible starting position.

I didn't really test it too much, so there are probably some bugs.

135
Weird, I got no screen tearing.

I actually got extremely bad screen tearing.  It looked like there was a drastic FPS drop, but the fps was apparently a constant 60, so I'm not sure what that's about.

Pages: 1 ... 7 8 [9] 10 11