# How should I generate and store the boundries of a cave?

I am making a small cave copter game (seriously, where did this type of game come from anyway) and I am trying to figure out how to make and store the procedural generated walls. I am thinking about creating the walls by randomly picking two points away from the center of the screen. They will be no closer than the height of helicopter and no further than the edge of the screen, weighted to prefer to go in the same direction as the point prior so I end up with stalactites and stalagmites and not just noise, at set intervals of distance. To store, perhaps parallel arrays/lists, one for distance from center to top screen and one for distance from center to bottom.

Am I way off base with my thinking? I just want the cave to be varied and challenging, I just have never worked with generating data like this.

Edit: Woah, I just realized that my idea would lead to a player being able to stay in the middle of the screen and win. That isn't right at all. So the very basis of how I was going to generate is wrong.

Edit 2: I also realized I left out a very crucial point. Part of the mechanics of the game will let the player go backwards therefor the data structure should be continuous.

• To your edit - no, because you generate the walls SCREEN_WIDTH - helicopter.rightBoundary pixels ahead, and you add some random values making it possible to pop up in front of it. – Markus von Broady Oct 12 '12 at 13:39
• @MarkusvonBroady, that is my fault for explaining it poorly. I meant basically what you put in your first point. Not the height of the helicopter at any time but the height of the helicopter itself which would have created a straight corridor in the center of the screen where the top and bottom of the cave would not get any closer. – Bob Roberts Oct 12 '12 at 13:49

After edits that makes things easier. Check out this topic: How do I generate a smooth random horizontal 2D tunnel?

1. Initialize paths for SCREEN_WIDTH + BUFFER_WIDTH pixels.
2. Every time you go further, add more curves, but don't remove old (as you can go back)
3. I suggested curves, because pixels take more memory, though they might still be OK.
• You are a winner! Seriously, not only did you give me exactly what I needed but the question you link to has other useful links. It is links all the way down. – Bob Roberts Oct 12 '12 at 14:35
• Heh, hard to lose when you're competing against yourself. Good strategy Markus. – MichaelHouse Oct 12 '12 at 18:07

Sure, two arrays are OK, but there are two problems:

1.Position of your helicopter change, so you should translate the positions to something absolute, like screen position, as you want your walls to stay in place.

point1Y = - 100; //100 pixels above helicopter
point2Y = 140; //140 pixels below helicopter

topPoints[i] = helicopter.y + point1Y; // we stored screen absolute position
bottomPoints[i] = helicopter.y + point2Y;


2.Another problem is how to efficiently store the points. In case of an array, you would have to remove first point of each array every time the helicopter moves 1 pixel right, and also add one point per array on right side. Moving all items left in an array may be slow. Instead you can use a moving offset in the arrays:

//initialize arrays:
for ( var i=0; i < SCREEN_WIDTH; i++ ) {
topPoints[i] = randomTopPointY (i); //translation is already inside
bottomPoints[i] = randomBottomPointY (i);
}

offset = 0; //leftmost points are in topPoints[offset] and bottomPoints[offset]

function scroll ( dx:int ) {
offset += dx;
if ( offset > topPoints.length ) offset -= topPoints.length; //wrap around

for ( var i=offset - dx; i < offset; i++ ) {
var index = i;
if ( index < 0 ) index = topPoints.length + index; //wrap around
topPoints[index] = randomTopPointY (index);
bottomPoints[index] = randomBottomPointY (index);
}


However I recommend you make it work first, and then optimize.