• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0

Random Map generator needs improvement

7 posts in this topic

I have a random map generator, that essentially uses the X/Y location of the tile as the seed to identify its tile type.  (infinite terrain without needing to save it)


However, its too random.  the terrain is peppered with any terrain type.  I would like it to be more splotchy.


What I was planning, was to divide it into regions (like x >> 4, y >> 4) of 16x16 to increase the likely hood of a particular type, but then I end up with squares.  any thoughts? 


Here is the code I use:  


    public static int PickANumber0ThoughN(int seed, int x, int y, int range)
        uint hash = (uint)seed;
        hash ^= (uint)x;
        hash *= 0x51d7348d;
        hash ^= 0x85dbdda2;
        hash = (hash << 16) ^ (hash >> 16);
        hash *= 0x7588f287;
        hash ^= (uint)y;
        hash *= 0x487a5559;
        hash ^= 0x64887219;
        hash = (hash << 16) ^ (hash >> 16);
        hash *= 0x63288691;
        return (int)(hash % range);
int tileTypeId = PickANumber0ThoughN(playerid, tileX, tileY, TileTypes.Length) - returns a seemingly random tile, that is the same every time the method is called.  I'm considering ways. to improve that to make larger blocks of random code, without adding much cost here.  Any ideas? I'm not opposed to using polar coordinates, 
Edited by Dan Violet Sagmiller

Share this post

Link to post
Share on other sites

an interesting challenge.


terrain that makes sense, randomly generated, on the fly, no saving to disk or ram.


can you lose the "no saving to ram" requirement, and generate sections at a time in ram at least? if so you can apply more sophisticated distributions to your tile patterns, but the algos may not be fast enough to do it from scratch every frame for every tile.


essentially, you'd have part of your world map stored in memory, probably the usual 9 regions paging method. but in your case, you don't page, you generate. but since the algos define multiple tiles at once, you have to store the results in ram, and can't just generate one tile at a time if it happens to need drawing. well, you could, but it probably would be too slow.


the algos themselves are your typical splotch based stuff. as long as you keep it deterministic, you should be able to generate anything anybody else does. 


Share this post

Link to post
Share on other sites

You can copy the initial permutation idea from the Perlin noise: basically, you have a permanent 256-sized array which points to a numbers from 0 to 255, call it "permutations". Then your "random" hash number at a specific integer point would be:


int X = (int)Math.floor(x) & 255;
int Y = (int)Math.floor(y) & 255;
int Z = (int)Math.floor(z) & 255;

int hash = permutations[X];
hash = permutations[hash + Y];
hash = permutations[hash + Z];



Also the trick is to expand the 256-sized array and clone the copy of the same numbers to the second half, so you don't need to check for array overflow when adding the coordinates.


You get more variations by interpolating between these values and blending more noises at different scales.


Perlin noise is here: http://mrl.nyu.edu/~perlin/noise/. 3D Perlin noise additionally interpolates between 12 points, plus 4 point simplex shape.

Although you would want to use improved Perlin noise, which uses 4 point simplex for 3D and 3 point triangle for 2D, which is aptly called Simplex Noise.

Edited by Nercury

Share this post

Link to post
Share on other sites


Here is the reason I'm trying to avoid saving chunks of data.  When the server needs to know something, like if a building can go in a particular spot, it needs to check all the tiles that it will be on to make sure they are buildable.  As in not water for instance.  If I did chunks, then for each check, it has to build that entire chunk, Suppose a building is 2x2 tiles, and that is right on a division between four chunks.  Then it has to build up all 4 chunks of data just to check 4 tile ids.  


So it is for the server's sake that I am trying to avoid this. 


also, @JTippetts

Some of what that produced was awesome.  exactly the types of layouts I would like to see.  But it also looks like its building in large chunks, not so much pixel by pixel.  (as in a function/pattern will adjust many pixels at a time, so if you didn't preprocess that, how much work would it take to implement something like that per pixel for checking.  



*Possible Idea...

(PreviousRandom = where the current code leaves off and was about to return)

X>>3&7&previousRandom = obtaining bits 0 1 2 3 4 5 (giving blocks of 8*8 the same base randomizers), as 0 through 7.  It increases the odds for the value to be 0, then 1,2 or 4, then 3,5,6 then 7 from highest to lowest order.

I can repeat the same pattern on the Y side. 

Each value can link to something that will alter the odds of particular tile types, for instance, I could make

: 0 grass, just all grass.  No more mods.

: 1,2,4 Grass mostly, but with water as an alternative.

: 3 = grass at edges, another tile type massed through the center

: 5 = additional rock focus.

: 6 = additional forrest focus.

: 7 = Forest.


That would be the X effect, and Y could have its own modifying alterations.  Perhaps the top corner pieces, can even look up its 2 neighbors to modify its likely hood of a particular type.


I think this gives me some more tweaking room without particularly expanding on the processing level too much.

Edited by Dan Violet Sagmiller

Share this post

Link to post
Share on other sites
I've done this sort of thing before, and I always used Perlin noise as JTippetts suggested.

Note that some things are pretty difficult to do with purely math methods, such as erosion. There are some tricks you can do with a Perlin function, such as using the derivative of the function at the given point, to sort of fake erosion but it's just never going to look as good as an explicit pass across a buffer of data using Navier-Stokes or some other approximation. Of course, if you're doing a tile game, then good looking erosion probably isn't a necessity. biggrin.png

If you have to do any after-the-fact modification to the terrain, or if you want to add things like roads, then again you will probably need to be able to work with chunks of data. Pure mathematical procedural roads are a BEAST to implement, and only rarely to they look good, but you can make them look okay if done as a post-processing pass after chunk generation.

Share this post

Link to post
Share on other sites
Yeah, erosion and roads can be tricky. I do use erosion on the maps in Goblinson Crusoe to help with river and lake placement, but it's a lot easier in my case since I'm not streaming a continuous world. There are a couple of noise variants described here that use the derivative of preceding noise layers to affect latter noise layers (some of the "tricks" that FLeBlanc may have been talking about). The Swiss variant described at that link, especially, gives the appearance of an eroded terrain. It still doesn't really help with rivers, though. I still haven't found what I would consider a good technique for procedural rivers on procedural terrain that doesn't involve simulating a process over an entire chunk.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0