Here's a rough idea using image processing transformations to isolate the features of interest:
Apply a flood fill from an ocean cell to make a mask of all ocean cells. Depending on how your rivers are set up, you might need an extra elevation or clearance criterion to keep the ocean mask from flowing inland. ;)
Apply a local smoothing to the edge of this ...
Amit Patel, a user of this site, has created a wonderful resource of information about random world generation that will certainly be of use to you.
Further there are some great questions/answers about procedural generation on this site.
Road / river generation on 2d grid map
Procedural world generation oriented on gameplay features
How can I generate ...
Most games place the map origin in a corner. The main reason for this is that tilemaps are often internally stored in two-dimensional arrays, and most programming languages don't allow negative array indexes. There are a lot of discussions about which corner should be the origin, but I don't consider any of the arguments particularly strong. In the end it's ...
Back when I experimented with this type of thing (late 1990s), I read some papers and books to learn about water flow, but I didn't keep a record of which ones I looked at. I ended up doing my own thing because I wanted to handle erosion. I wanted rivers to produce canyons and floodplains. I wanted dam reservoirs to fill up with sediment. I wanted rivers to ...
I have been able to come up with a few reasons myself, but I'd really like to hear more.
Horizontal layout matches the layout of the keyboard. You could use WEADZX for movement, similar to WASD on square grids. On the other hand, I have also found suggestions that QWEASD is a natural fit for vertical hexes.
Horizontal hexes seem to be better suited for 3D/...
The way Dragons Abound identifies bays is to walk along the coastline and find two spots on the coastline where the straight-line distance between the spots is less than the distance along the coastline between the spots. This is the sinuosity of the coastline between the two spots. By selecting a sinuosity limit and limits for the straight-line distance ...
I would go with vertical layout if you are using any sort of bird's eye perspective, as in the image above.
Why? Because all walls will be visible. If you use horizontal layout, and you have walls that run along the vertical lines, you will not be able to make out details on them very well (such as doors or gates). Furthermore, if you are using the ...
Sounds like you're leaning toward horizontal as having more advantage. For what it's worth, bees agree with you when they build their honeycombs:
The axes of honeycomb cells are always quasi-horizontal, and the
nonangled rows of honeycomb cells are always horizontally (not
vertically) aligned. Thus, each cell has two vertical walls, with
I think the Voronoi idea is a good one. Each star becomes a seed point for Voronoi, and then the Voronoi regions show the areas owned by each faction. However, there are some changes that will make it work better:
As you mentioned, there are empty areas that shouldn't be assigned to a faction. Voronoi will create large polygons that extend out to areas ...
Layers are needed not only the most basic use of a tile map, but also allow more artistic expression and play features. Layers define the draw order of the sprites used in your world. They're simply a way to say, "Draw sprite X after sprite Y, so that sprite X will appear on top of sprite Y". They're typically generalized into layers so you don't need to ...
Let's start with the array. Don't think about it as tridimensional. Indeed, if you want to have stackable units there, it makes sense at first sight:
first dimension is collumns of rows of tiles
second dimension is rows of tiles
third dimensions is tiles, i.e. arrays of units.
But this third dimension won't be consistent, as you will store there not only ...
You want multiple paths from A to B.
You want to work in grid space, presumably this is tile space for your side-scroller.
You don't want paths to cross, or it will spoil game progression.
You want the paths to look reasonably organic.
Voronoi Diagrams are space-filling, planar graphs:
One nice thing about them is how you ...
Your hex orientation will influence both your general aesthetics and your asset production.
If you choose vertical tiles, you can make your hexes twice as wide as they are tall and have pixel-perfect accuracy. Here are some 64x32 hexes.
Note that the diagonal edges are at 45 degree angles, making them easier to render in pixels.
The narrow height of the ...
If you are building a strategy game, the game requirements and design itself should dictate which orientation you choose. Note that defensive lines are more easily held with the grain than against it, so your choice of grid orientation relative to map orientation will affect game play. To emphasize defence, such as in WWI, align the hex grid with the natural ...
Step1: Randomize points-each time taking a step forward on the x-axis
Step2: Imagine segments(lines) between these points, add new points in the middle of each one
This is how it looks now without the segments:
Step3: Draw bezier from red point to red point, using the original point as control.
Randomize new control point
From a technical and programming perspective, there should be no fundamental difference in data structure between the two orientations - any reasonable scheme should be easily modifiable to work well with either setup.
Design-wise, in the end it will come down to preference — as you've noted, there are multiple games using either scheme, which is ...
Have you tried Lloyd's Algorithm? The procedure is pretty simple, and will generate fairly regular looking regions (depending on how many iterations you run).
Tile the map with blank hexes to start.
Choose N hexes at random. These will represent the "center of mass" for each country.
Tag each hex with the center hex it is closest to (Voronoi Diagram). ...
You could use OpenStreetMap data.
It is liberally licensed. In particular, their wiki says:
3c. If I make something with OSM data, do I now have to apply your
license to my whole work?
No. For example, if you have written a game or published an artistic
map which includes OSM data, only the data is covered by the license.
This is called a ...
As Martin Sojka notes, rotations are simpler if you convert to a different coordinate system, perform the rotation, then convert back.
I use a different coordinate system than Martin does, labeled x,y,z. There's no wobble in this system, and it's useful for lots of hex algorithms. In this system you can rotate the hex around 0,0,0 by “rotating” the ...
Okay, for anyone interested in this topic I will now detail the solution I have chosen. Thanks to every one who replied and gave me ideas.
First, for the 'best' tesselation, I will choose the truncated icosahedron as a starting point. Subdividing it leads to a very nice tesselation of hexagons with 12 pentagons providing the curvature.
Also, continuing the ...
In doing a similar project, I found the SketchUp modeling program to be excellent for copying existing architecture. That's what Google originally meant it for after all.
Here's an account of how I did this:
SketchUp's Photo Match feature (tutorial video) is an absolute killer.
It lets you to do this:
Load in a photograph of the real building ...
In theory the location of the origin doesn't matter. All math operations you do when the map is rendered or when objects move on the map work fine regardless of where the origin actually.
However in practice there is one reason why you might want to make the center of the map be the origin - and that is limited precision of floating point values.
Because spherical maps, compared to rectangular ones, create a lot of additional complexities regarding the technical implementation and the UI design while usually offering very little gameplay advantage.
First, there is the technical problem. With a rectangular map, you just use a 2-dimensional array to represent map positions. But unfortunately there is ...
To add to Savlons answer:
There are two ways of doing this
Vector2D objects(Assuming your positions are vectors):
diffVec.normlize(); //Assuming it's applied on the vector itself
// and does not return a new one.
//This vector is now a unit vector which represents the heading/Direction
//without the "speed" (Well ...
Finding an algorithm is usually best done with a data structure that makes the algorithm easy.
In this case, your territory.
The territory should be an unordered (O(1) hash) set of borders and elements.
Whenever you add an element to the territory, you iterate over adjacent tiles and see if they should be a border tile; in this case, they are a border ...
360,000 * 360,000 == 129,600,000,000 pixels in total.
Let's be generous, and assume that you're only using a 16-color palette, so each pixel can specify its color using only four bits.
129,600,000,000 pixels * 4 bits per pixel == 518,400,000,000 bits. Divide by 8 bits per byte gives us 64,800,000,000 bytes. Divide by 1024 bytes per kilobyte (or kibibyte, ...
Regarding the coordinate system:
In order to address individual tiles, you will need some kind of origin (a 0:0 point). In order to allow the playing field to expand in every direction, you will also need negative values. This will give you a world which stretches from -2.147.483.647 to 2.147.483.647 in both directions, which is "large enough" to seem ...
I think it helps to compare it side-by-side with regular Perlin noise. As explained in the Gustavson paper, Perlin noise works by assigning pseudo-random values (gradient vectors) to each corner of a square grid and then doing some interpolation for points in the interior of a grid cell. So the first step in evaluating Perlin noise is to figure out which ...