How to deal with procedural terrain, pre-load or real-time calculation?

Question

I have developed an algorithm that generates 2D terrain coordinates for my iOS 2D game. This may be a possible visual output:

The coordinates are stored in a 2D array.

mVertices[i][0] = ccp(sx, sy);
mVertices[i][1] = ccp(sx, 0);

E.g. sx is increased in steps of 30px while i is the number of steps. For each step a sy is generated. To get the line straight down I need a second point which is the second line of code.

Imagine in the game there will be a character on that terrain. The terrain scrolls to the left while you have to move your character. Now I want to figure out what would be the best way for me to draw the terrain.

One way is to pre-load the terrain. So I would generate the points for say 5000px along the x-axis when the user starts the game while a loading spash is displayed.

Another way is to generate the terrain in real-time. I think this is the best solution here. What do you think?

When I take the real-time way, how I do the array stuff? I mean the part that goes out of screen has to be removed from the array and there is a new step that is added.

Maybe a classic array is not good as data structure for that prupose. I introduced it in my project because I can pass it to the ccDrawPoly function that takes a CGPoint array.

Please share your ideas.

Answer 1

I think the best Idea is to go with the real time generation since there are always some nerds who break every limit you put for yuor game.

for example if you go with 5000 nodes there will be some people to player far past it just like what happen to pacman, none of the developers never tought of someone go beyond level 255, but there were geeks to break that limit! so you need realtime generation.

Now how to generate levels in realtime: you are saying you are developing your game for IOS and as your sample shows you are going to create a landscape game so you have 480px screen to draw you game, considering your terrain is create by 30px pieces you need 480/30+2 piece ready at each frame. since there are always atleast 480/30 pieces inside screen and just by a little movement a part of another piece will come in your viewport. lets say we store one extra piece as reserved. some games doesn't have a feature that player can go back in levels (just like super mario bros) in these cases you can remove every tile that goes out of screen to free unused memmory, but if your game let's player to move freely inside levels you need to keep whatever was generated. just ignore them in drawing phase.

to store the levels you may use both arrays and linked lists. since you usualy don't need a direct access to any of the pieces, linked lists doesn't slow your code down. in my case I usually try using queues to store my level information. if you know how many pieces are in your levels you can easily use an array and keep your all your data inside it, you may either shift data as new pieces are generated or you can keep head and tail of queu and use that array like a queue (circular buffer as maik suggested).

then you need to draw them, ccDrawPoly is a good choice by I prefer to use ccSprite or ccTMXTileMap since you can't apply texture to what you are drawing. don't worry about your object may be out of screen since cocos2d handles these situations and draws only visible parts. I think for objects that are completely out of scene it even ignores drawing but it's better to remove objects that move outside. it help you organise your game better.

Answer 2

A proper data-structure for this situation is a Ring-Buffer, aka Circular Buffer