Tuesday, April 9, 2013

Map Generation

Working on a RTS-like/City Sim-like game and working on getting a large map for it. My plan is that the game be tile based and completely procedurally generated. Working with some Simplex Noise, I've generated what I hope will be a the starting point of my levels, but I need to work on the scale. The generated images here have no scale, but they appear as though they would be in the scale of several (possibly hundred) square miles or km, which is impractical.  The goal is to have a tile equal about half a meter or 1.6 feet, about the width of a person.  That makes path finding and collision avoidance/detection easier.  My plan is also to make one pixel in the map correspond to one tile, this poses the problem that the below images would be 200 meters for most, the tiled ones were generated as 400x400 px, and the largest image would still only be half a km, at 1000x1000 px.  At the moment my noise is normalized to always contain [0,1] so it always looks similar, scale changes do make it look better, but even I try to get it to generated square at a much more detailed scale it still has large patches of 'desert' near water because of the way the noise is mapped to land, still thinking of a way to deal with this. I am thinking generating the noise for a larger area and using that to normalize a smaller actually used area.

This one is to show the way the tiles will hopefully look.



UPDATE: I've been tinkering and I got the following image for different levels of zoom, the left-most image is the landscape I'm thinking will be a mile or km width/height.  each set of images is scaled by two.

Tuesday, April 2, 2013

Fluid-Based game progress

Well, I've been working on the idea of a Minecraft-like game (infinite procedurally generated world, with resource gathering and building) but instead of semi-fixed Voxel-based, I want to use fixed-size particles in full Smoothed Particle Hydrodynamics simulation, including heat transmission.  The idea is to create a world where you can shatter a chunk of the rock off with a tool to pick up, or create a heat source large enough to melt the rock, and gather the liquid.

This is obviously a very difficult proposition for many reasons, but mostly speed, as well as the problem of getting a good simulation of melting/freezing, the papers I've found that mention it don't go into detail enough to implement. I've toyed with three versions of a simulator so far, but none of them are fast enough to do a full world with. And only one would support what I want to do right now, the slowest.

These are two screenshots of the original full simulation:

These shows two fluids, the pinker is denser and also more viscus and elastic. This simulation works nicely but is quite slow <250 particles runs at 4FPS as shown. It uses springs for the boundary conditions.

The next two are another version of the same simulation.  It does not use full SPH and simply uses springs to prevent penetration:

This one has the same parameters except the boundary conditions are different, they are still springs, but there seems to be a bug in my implementation where there is a new boundary that keeps forcing the particles down. This however is much faster with nearly 500 particles running at 5FPS, about double the original, but it would require more work and code to get melting/freezing/solids and thus would slow down the code probably to the same as the original.

All those above used LWJGL for rendering.

This last one is done with JME3 to render and it's built in JBullet library to do the physics, this has many drawbacks, density won't cause a fluid to float on another, and melting/freezing and solids built of particles become problematic.
Because it uses JME3 the particles->FPS isn't quite as obvious because it is showing 'objects' which is not the same thing.

This is one of the slowest projects I'm working on, because I keep putting it on the back-burner for other things that are more likely to be possible.  I'm thinking I should do it in C++ for speed, but I really prefer java.  I'll probably keep working with the original, or second one, just to get a tech demo, albeit slow, that works.