I was thinking about procedural generation, and read an interesting post over on tigsource, and decided to make a basic tree generator, since I have basically been tackling any programming problems that are interesting to me. Here’s the result of very little work, but it’s still kind of nifty.
As usual, mt, is the Mersenne Twister. This can be swapped out for Math.random() or java.util.Random.
Click here for more! (more…)
I updated a few things, like terrain noise with smoothing, and also full land maps and more island like maps as well. Here are a few screens.
Click here for updated source code
Click here for more (more…)
Well, I was really bored, so I wrote a quick and dirty terrain generator. It uses some simple recursive methods to generate terrain.
The “mt” refers to the Mersenne Twister psuedo-random number generator. This could be replaced with whatever random number system you want, to get random maps. I prefer it since it has the highest longevity of any psuedo-random number with its performance rating.
Click below to see more generations (more…)
To continue my tradition of making many small, slightly unplayable games, to learn more about programming, I bring you: A tower defence!
Who knows, I might actually do something with it. However, this is only 2 hours work, so it’s pretty crappy!
So, I was fooling around with maze generating, and I happened upon a very strange way to make mazes, albeit, not the most pretty ones! 
You can see the source code here
Basically, it works through a branching recursive function that chooses a Y direction at random, but always prioritizes left over right. This leads to fully usable mazes from all my tests with flood filling thus far. I will probably run a tester over a few thousand gens soon to verify, but it appears clean! If anyone wants to take a stab at it, and tell me all the things I did horribly wrong, I’m open for advice 
Here’s a picture of one creation of it. As you notice there are many short dead ends which make it not the most aesthetic, but it is actually fully connected!
Basically, a turn based game that is extremely gore-ridden and involves increasingly harder, and nastier, opponents! Sounds like a fun idea to mess with, and here’s the prototype menu for it atm. 
So, I finally got a few things working, like basic collision detection and map loading from a text file. I’ll probably work on adding some sort of challenge to the game, and a win condition for each level. Also, I may look at extracting the txt files from a zip file to save space, as the 48 kb of 3 levels compressed ended up being 950 bytes. That’s a pretty big space saver!
Anyways, I’m going to release a demo to fool around with for anyone interested, so here it is.
It’s not the greatest, but I did include my ad-hoc level editor with it, so you can use that to make a level, and play it in the game. Controls are as follows:
In game: Arrow keys to move, and space to jump. Shift to run.
In editor: Arrow Keys to navigate, right click to select tile, left click to place tile, f2 to save. (it will make a file called level_2.txt in the root, just rename it to level_1.txt and replace the current level_1.txt in the data folder to play your level.) Also, you can send me any creative levels since I may use them if I don’t feel like developing a ton of content right away.
All right, I’ve decided to start making a few tips for new programmers as I, myself, learn to program, in the hopes it may help anyone new to programming, and game making specifically.
So, today’s random tip is Floor, and not the kind you stand on, mind you! No, this floor is a special function that allows you to round any number down to the last whole integer. Seems pretty simple you say, huh? Well, it is! It also has a very useful purpose, and that is grid based positioning.
For instance, say you have an object that is moving around the screen, but you want it to collide with a grid. This is very simple with your friend, the floor method. If you have an object that is at (19,32) and your game is a 4×4 grid of 32×32 tiles, you may want to know where it is in the grid. Assuming most objects aren’t a single point, the easiest way to do this is to get the floor position of each corner of a sprite, for a rectangular or square object. If you were to round here, a point that is 9/10ths of the way into a tile becomes in that tile, when it really hasn’t collided yet. That’s why floor is useful!
A simple collision test for an object whose speed never exceeds the size of a tile, so for instance, an object moving 4 pixels per frame with 32×32 pixel size tiles, is simple with floor. Just by doing a nested if loop you can achieve a decent collision tests. Also, you will want to check the four corners for collision, taking into account their next position based on current speeds, and if collides, stop it before it intersects the grid.
This is just a VERY remedial collision method, but it does work for simple collisions. If I’ve made any mistakes, please comment below so I can correct them!
This first screenshot is of a super-super-prototype game I made when me and a friend decided to try and make a gameboy style (4 colors and 160×144 resolution) game in under one day. We ended up spending about 2 hours, perhaps, on the entire thing before getting bored. And that’s the result of those 2 hours. Anyways, I did compose a jaunty little bg song for the game here
