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 ... 6 7 [8] 9 10
General discussions / Re: We're close!
« on: November 11, 2014, 03:58:36 am »
Pretty exciting.

I just took the three minutes to download, compile and test it out.  It seems to be working just fine in my project / on my machine, but I'll post back here if I notice anything.

SFML projects / Re: Dwell - A Retro Sandbox Survival MMO
« on: October 25, 2014, 11:33:45 pm »
Voted.  I wish you luck, I don't think you'll have too hard of a time getting greenlit.

SFML projects / Re: It Always Ends In Nuclear War
« on: September 28, 2014, 03:40:04 am »
Creeping slowly toward playability...

General discussions / Re: Randomizer.hpp
« on: August 26, 2014, 05:17:58 am »
Taken from stack overflow
#include <random>
#include <chrono>

unsigned seed = std::chrono::system_clock::now().time_since_epoch().count();
std::mt19937 rng(seed);
std::uniform_int_distribution<int> gen(min, max); // uniform, unbiased

int r = gen(rng);

SFML projects / Re: Feedback wanted - Simple Gravity Game.
« on: August 12, 2014, 01:09:44 am »
At the very least you should make the hitbox for the ship bigger, as well as make it a bit more obvious that the goal is to click and drag from that ship. 

Either way, this is pretty cool.

SFML projects / Re: F.I.R.E.D. v0.99.pre-alpha
« on: August 12, 2014, 01:05:11 am »
That looks awesome.  Nicely done man.

Fair enough.  Thanks for the response.

Higher level features (like sprite batching) that implicitly or explicitly improve performance were never part of the SFML API, since the API is about providing the necessary access points to lower level functionality. Such high level features can already be built on top of SFML, and people who complain about the lack of such features and thus the implied inefficiency of SFML are simply too lazy to roll their own code and probably just spoilt by other libraries that do go ahead and provide such features. SFML performance scales with the aptitude of the programmer, and that isn't a bad thing.

Maybe it's just me, but I think you guys would want SFML to perform as fast as possible, regardless of how skilled the programmer using the library is.

In regard to a feature such as sprite batching, is the concern not wanting to clutter the API, or is it more that it's not considered low level enough to implement? 

SFML projects / Re: Run time error sfml-network-d-2.dll is missing
« on: July 29, 2014, 05:39:44 am »
It sounds like you're dynamically linking, which means that you need to put the SFML .dll files in the directory you're running the application. 

Taken from Stack Overflow:
When you statically link a file into an executable, the contents of that file are included at link time. In other words, the contents of the file are physically inserted into the executable that you will run.

When you link dynamically, a pointer to the file being linked in (the file name of the file, for example) is included in the executable and the contents of said file are not included at link time. It's only when you later run the executable that these dynamically linked files are bought in and they're only bought into the in-memory copy of the executable, not the one on disk.


Also, does SFML work with VS 2013? 

SFML projects / Re: It Always Ends In Nuclear War
« on: July 27, 2014, 06:00:27 am »
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.  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

I'm still not entirely happy with how the tile types look and are distributed, but it's getting closer.

SFML projects / Re: It Always Ends In Nuclear War
« on: July 23, 2014, 12:15:46 am »

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.

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. 

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



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.

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.


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.

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