503: the dawn of an old age.

AKA “the project formerly affectionately referred to as project sword and also formerly occasionally humorously referred to as project you’re a nation”.  (503 is shorter)

->Download now: 503 -236kb<-

A third render of the same map from a similar angle as the first two posts highlighting the differences. Click to view full size.

Instructions:
The project at this point is still about exploring the map, more to come, hopefully soon.  Movement is WASD and directional keys. Q and Z controls elevation.  N for new map. F2 to gain control of your mouse. Esc to quit the program (only works if it’s the active window, you may need to click then hit esc.)

Geek stuff:
So this update has a lot of new work in it.  The horizon looks much more realistic as I’ve vastly improved my generation algorithms.  I separate the rock and dirt into separate arrays, while exaggerating the rock.  Then treat the two differently in erosion.  A much bigger step I’ve made though is the river and lake generation.  This was a lot more difficult than I expected, I basically rain on every vertex then allow the water to go down to the lowest adjacent vertex absorbing a small amount of terrain per step then when it is trapped it begins raising the height with water and placing terrain instead of taking it. Eventually it finds it’s way out and continues until it reaches the ocean.  Mass wasting was much simpler, though I’m not completely satisfied with the results.  It moves earth much like the water moves.  It breaks off a chunk of terrain if the slope is too steep, and moves it to the lowest adjacent vertex.  Then runs again on that vertex and so on.

One of the noise parameters I added controls distribution. This is what one of the maps look like when I override the default value for the heightmap generation. A very exaggerated version of the pyramidding mountains is clearly visible.

The problem is that there are 8 adjacent vertices so if I had a large area that was really steep I always end up with large flat areas with well defined corners, and coastal shorelines that are straight.  Maybe a little more robust slope detection check would do the trick.  I abstracted my heightmap generation and then use it to make 2d noise maps. I also made it a little more powerful so I can create more specific noise maps. I generate several noise maps with each new map. Though, you can’t see the effect of any of them except one. The green terrain looks more interesting now; the darker patches represent forest. I still need to tweak these values.  But, I’ll probably get higher lod terrain streaming and tree generation before I tinker too much with it.  I could probably get a decent looking skybox with a little bit of work using the same noise generator.  Maybe I should have got that out before posting;  But, I’m trying to find a balance between high frequency posts and actually having something to show in the posts. Ideally I would like to post once per week but that may be unrealistic. We’ll see how it goes.
As a side note, the name, 503, refers to a period of time on the Gregorian calendar, or AD 503.  While the game won’t be historical it will be designed to be in a very distinct setting (late antiquity/early middle ages/dark ages/whatever you want to call it, in western Europe).  503 is probably a little too exact but it’s just a name.  I’ll figure out a subtitle for it later as it’s too ambiguous right now.

You can start to see what the horizon might look like from the land.

Updated:
-Erosion added: both mass wasting and fluvial simulation
-Noise maps generated for various resource placement
– Multithreaded some of the generation to make it a bit faster on multicore processors
-updated texture generation
-fixed a small (but annoying) memory leak in the generation (about 2kb per map generated)
-a bunch of smaller stuff I can’t think of right now

Advertisements

Project Sword: now in Technicolor!

Project Sword more normal than ever… or now with normals… or something…

Download: Project Sword r2- kb

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. F2 to gain control of your mouse. Esc to quit program (only works if it’s the active window, you may need to click then hit esc.)

Geek stuff:
Knocked out quite a bit with this update, beyond the obvious, a few noteworthy things are: Water height calculation, I average the map’s y values and then increase the average by 25% then use that as the water height. Makes the maps a little more consistent, though I still run into quite a few poor quality maps (in my opinion).  I don’t want to really reduce variability too much, I’d hate to be able to produce millions of unique, marginally different maps. The y values have been reduced significantly. I think they are about right for my project now. Once I get some erosion going, from the local area view, it will still be interesting. I think I’m intimidated a bit by river creation, I’ll just have to tackle it and beat it into submission. I’ve got some ideas about cube map generation for a skybox. But I have some important behind the scenes threading duties to do before I can do much more.  Vertex normals are calculated by normalizing and averaging the cross products of the vectors to all 8 adjacent vertices at each vertex.  It’s actually surprisingly fast considering I’m doing 4 square roots per vertex… Just now thinking, I may be able to get that down to one square root per vertex. I’ll have to look into that.  One of my favorite new features is the rather simple generated texture.  I get each vertex’s y value and then depending on what it is shift the color, the lighter color water is the same, I just render the vertex at water height. I also compile the normals and geometry and texture all into a display list for faster fps, which adds a bit more time to the generation process.  It takes about 4-5 seconds to generate a new map now, with compiling the map, calculating normals, and generating the texture.

Updated:
-Tweaked some of the values and made water height dynamic.
-Added triangle strips
-Added Dynamic Texture Generation
-Added Vertex Normal Calculation
-Added Display list

 

Project Sword: A beginning “dotted” with hope

 Originally titled “Project You’re a Nation”.

Download: Landscape prototype -231 kb

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.

Todo: (next)
-Refine algorithms
-Probably add some triangle strips and textures and basic lighting to help visualize.
-???
-PROFIT!

3D Maze

New dimension adds a whole new dimension to maze exploration.

Download: Maze3D.zip – 582kb

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

Maze screenshot

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!

Todo: (don’t hold your breath)
-Chunk maze (see above)
-Add stencil shadows
-Add normal maps
-Add rotational momentum

Lottery Simulator

Remember, you can’t lose if you don’t play!

Download: Lottery Sim – 170kb

Ever wanted to lose a bunch of money playing the lottery without losing a bunch of money playing the lottery?  NOW YOU CAN!  This application simulates one of the big US lottery games.  The instructions aren’t really explained in game as it’s designed to be just like the real game.  I will go over them here, however.  Let me know what you think in the comments below!  btw I have tried to avoid any trademarks or other intellectual property intrusion for obvious reasons.

Instructions:
You will choose the number of lines or tickets first, this is like the number of computer picks the machine picks in a lottery kiosk.   Second you will choose whether or not you want the multiplier, this will double the cost of your tickets but at least double your winnings up to the top two tiers:  the second tier is always 5x and the jackpot is unaffected. 2-5 is randomly chosen as a multiplier for every other tier, per draw.  Draws are a little redundant with no waiting 3 days between them, but there is a subtle difference and further it’s included in the real game so I through it in the mix.  This will multiply the cost of your ticket by the number of draws, but will cause your tickets to draw in that many draws.  For example 2 tickets and 3 draws will be 6 dollars with six chances to win: a winning combination will be chosen, you will try two times, then another, two more tries and finally a third, and two final tries.  You start the game with $100,000 good luck and enjoy losing!  [side note: the chances are as close as I could make them but for technical reasons (see below) you may win a little more frequently than you should]

Geek stuff:
The game is pretty true to life, for example: it would be easier to just use the chances of winning, but instead I actually calculate the winning ticket and each of your tickets and see if they won just like reality.  You can’t draw two identical numbers on any one line.  There are a couple technical problems.  Number one is that you technically should maintain your same lines from one draw to the next only the winning number should change.  This wouldn’t be too difficult to fix but overall what I’ve got works, everything is recalculated every time, spins a little extra cpu time but doesn’t use as much RAM, not that that isn’t all negligible.  The second is I just use the stock Random function, which has poor distribution and high repeat-ability, it was really bad at first, I combated it by simply inverting the output for the winning combination: 1 is 59, 3 is 57 etc. this cut down on the unexpectedly high winning but it seems to still be higher than it should be.  I could probably swap this out with a better one fairly easily but it works I guess.

Todo: (maybe)
-simulate lottery jackpot increase and possibility of someone else winning each draw (including when you do).
-add a table of suggestions for ways of spending money based on how much you have left to emphasize that you could have bought a house but now you can only buy a cheeseburger.
-Just had a thought, to embellish the draws function, create a pause for each draw requiring you to press any key and allow you to review your winnings for the “night”.
-Another good idea, difficulties: Easy starts with $100,000 like the current, Medium starts with $1,000, Hard starts with $100, Reality starts with $20. With the lower difficulties available I should probably put the entire game in a while loop allowing you to try again over and over if you lose.  I really like this last idea I kinda want to implement it now but I already have it all uploaded and I have other things I need to work on for now, maybe I’ll do it later.

Amazing

Download: Ascii maze generator – 164kb

Screenshot of program output. Click for full size.

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.