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.

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.


3D Maze

New dimension adds a whole new dimension to maze exploration.

Download: – 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.

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.

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.


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.