Main menu

Tag Archives: generate

So, as you can see, I’ve begun work on a new project. Affectionately referred to as “Project Sword”, pending a real name. Currently, it’s just a graphical display of a procedurally generated height map.

That's a million dots of pure awesome.

I have included a download (see above); I will be making more posts and maybe youtube videos in the future. I’m not sure how long I will include an executable of my current progress as I would like for the completed project to be commercial. Perhaps I will just provide limited features in a demo version.

Instructions:Currently the project is pretty simple. All there is to do at the moment is to explore the generated map. Movement is WASD and directional keys. Q and Z controls elevation. N for new map.

Geek stuff:As linked above, I use a “diamond square” algorithm in which the generated area height is averaged then randomly modified within a range, then again, and so on. It’s currently fractal, or self similar on smaller scales. However, this will change in the future. I have a lot of processes I want to run to refine my current output into something more usable. After all these procedures are ran I will then find a map I like (or keep it open, I’m not sure) then use this map to seed a similar, though implicit, algorithm. Which will finally be rendered into the game world. While I like the idea of a infinite game world like Minecraft’s and it certainly wouldn’t be difficult to pull off, I have specific reasons why I want to use a finite map. An infinite map uses a purely implicit algorithm. This means that only a nearby area can be used to figure out what your current area will be like. You could generate a continent at a time or something like that but it would get really weird. With an explicit algorithm you can determine, for example, your current area should be a desert because the rain is carried in from the west and there are large mountains 500 miles in that direction blocking any storm clouds from getting to you. Typically in an infinite world you would only generate everything a chunk at a time, with some very simple larger areas being generated. In Minecraft, these are called biomes. But as far as I can tell there is really no strict rules on any sort of placement. I’m not really sure how big the game world will be yet, I think it’s going to hinge on river creation. As I believe this to be the smallest aspect that will need to be explicitly generated. A map of ideal size, would require the distance between each point to be approximately 300 yards/meters (the current height is exaggerated). The problem with this is that if I wanted to designate a a river to be at a certain point, I would need a pretty clever algorithm to determine where, in that distance, it is actually located. Now the obvious solution would be to increase the density of the points by increasing the number of points. However, I’m being mindful of memory and generation time. Currently there are 1025×1025 points (yes, I know, weird size, due to the generation algorithm it’s easiest with 2^n+1) this means slightly more than 1 meg per byte pixel. Currently the height map is stored in an unsigned short, 2 bytes. This means 2 megs to have this in RAM. That might not seem like much but every time I halve the distance between the points I double the RAM necessary and it will likely require at least another 2 bytes for the rest of the information needed, dryness, material, vegetation, temperature modifier, river etc. The whole game should probably take around 1GB of RAM and I wouldn’t really want this aspect to hold more than about 5% of the total RAM (about 50 megs). The second part is with every algorithm I run the data through, the time increases, and exponentially so with increased points. If this increases up to more than a few minutes it would make it unreasonable to allow the user to generate a new map, and would also require the user to download the 50megs along with the rest of the data. I may increase the density some more still but it’s not necessary to make the decision yet, so we’ll see.

This program uses my Ascii maze generator for data to make a maze, then allows you to explore it in a 3D OpenGL context.

Screenshot of the entrance to a generated maze. Click for full size.

When you first run the program it will launch a console window and ask for a width, height, and a random seed number. 10 – 50 is a good range for the width and height, but you can make it larger or smaller than this if you want. On a 3ghz core a 50×50 maze takes just a few seconds to generate but a 100×100 maze takes around a minute and is very large, runs choppy, and causes problems with collisions on slower gpus.

Instructions:Controls: W A S D movement with strafing, arrow keys for movement with turning. Mouse for looking around. Space bar jumps. More keys listed in game, press F1 for help. Hold F2 to gain control of your mouse (unbind from game window). Esc closes the window. Feel free to maximize the window, probably won’t slow it down (depends on your system).
A Few Tips: A green gem is generated at the entrance and a blue gem is generated at the exit. By jumping you can get a glimpse of what is on the other side of the wall in front of you, as well as the location of the gems.
Known Issues: If the cursor is visible or not responding, click the window and press F2. Two things may cause unresponsiveness on the keyboard, if you have caps lock enabled none of the alpha keys will respond, also if the window is not selected only the mouse will respond, try clicking the window, or ALT-TAB to select the proper window. On larger mazes if you are dropping to low frame rates you may occasionally walk into, or through walls. Right now the only solution to this is to generate a smaller maze or get a motherboard with a higher bus speed to your graphics card the bottleneck may vary from system to system.

Click for full size.

Geek stuff:I learned most of the OpenGL at Swiftless I found his site to be the most straightforward and easiest to conceptualize. The generation program is pretty accepting of information, try putting in 0 x 0 maze. Or 800 x 1. If you are curious how the maze is generated, there is more information on the post I made when making the generation algorithms. You can have some fun playing around with different .bmp’s in the texture folder. Just make sure they are 24bit and must have the exact same name. You can use paint to easily convert an image to the proper format. The current textures I got here.

There is an issue with large mazes currently, my laptop runs a 100×100 maze at 15fps compared to a 0x0 at 1000fps you shouldn’t really have any problems at around 100 fps. I think the actual issue is with sending so many vertices. It would probably be fixed with a vertex buffer, but this would only fix the problem for computers with full graphics cards, I programmed all this on a laptop so even with a vertex buffer all the info would still reside on the same stick of RAM. And a desktop computer would likely have a much higher bus speed to the graphics card anyway(I guess). So the other idea I had would be to divide up the maze into small chunks, maybe 5×5 or 10×10 then display only what is needed per frame, considering frustum and location. I think this would probably be a couple days worth of work and I really need to get in the habit of focusing on priorities. Everything I add will only open up more avenues to add more, and this project really doesn’t have a future, so I think it’s in a fun, playable state and will probably forever remain thus. I thought about adding logic to detect when the player reaches the finish, but I decided I like it better when you decide how you want to play, and not distract the player with my rules. I also like not having a minimap or any gui user interface or a splash screen it’s just the game engine. Onward to bigger and better projects!

Cool, but what’s it do?:
This maze generator will make (for all practical purposes) an infinite number of mazes you simply choose a width and height (restricted only by the console), and choose a random seed. A random seed will allow you to create the same maze multiple times, just make sure you enter the same width and height as well. For example, every time you enter 38 wide 10 high 19 random seed, it will always give you the same maze. But changing any one of these variables will practically always give you a completely different maze. Have fun and let me know what you think!

Geek Stuff:
The maze construction works by first setting up a template I put together after studying this then randomly placing blocks onto the maze one by one and ensuring all the maze is accessible, if a piece is placed that would divide any of the maze into a separate section, that piece is removed and a new place is found. There is a threshold for number of fails and it increases the larger the map gets. So larger maps do take significantly longer to make than smaller maps. Additionally, this is not multi-threaded, your single core cpu’s are not at a disadvantage! That being said, it really doesn’t take very long to crunch a new map. I would like to eventually export the data to an opengl environment but until then, bask in ASCII’s glory!

(10/08/11) I have updated the program and moved to a different IDE (and compiler) for better compatibility. The application is now much larger but no worries about an installer or having all the required dlls (yay). The old build is still available, but you will need Visual Studio C++ installed to run it. The program is now more efficient at creating larger mazes. There are actually two fairly similar maze generation algorithms, one is more efficient early on and the other is more efficient as the maze begins to fill up with blocks. So it starts off with the one, scattering blocks randomly, many times on the same tile as last time and then once I start reaching diminishing returns with the first algorithm a smarter algorithm finishes up, never trying the same block twice. The difference is really negligible except on huge maps you have to scroll to see (eg. 38×140) but I’m a dork.