Any ideas on how to generate fast and decent 2d tile terrain for a side scroller in real time? The game would generate new columns or rows depending on the direction the player is scrolling in. The generation would have to be deterministic. The same seed value would generate the same terrain.

The style of game would be a platformer like Sonic The Hedgehog. Maximum size would be around 1024 x 1024 tiles, but smaller could also work.

A column or row doesn't have to be calculated every frame, just when a new one is needed. If the player moves 1 pixels a frame, then a new column is only needed every 8 frames.

I'm looking for algorithms that would satisfy the memory and CPU constraints of the hardware.

Something tells me this isn't a "side scroller" at all. Is it a Legend of Zelda perspective or a Mario Bros. perspective? If it's really a side scroller, with platforming and gravity I assume, randomly generating "terrain" wouldn't be easy, especially if you really want them to be able to go in all 4 directions.
–
Eric BNov 24 '12 at 15:53

1. What is the size of the screen in tiles? 2. Is this a platformer with gravity (like Sonic) or a top-down view (like Phantasy Star)? Cause creating tiles for each of these is different. 3. If you need it to be deterministic, why not randomize in advance and then save the tiles to the ROM data?
–
zehelvionNov 24 '12 at 16:06

@arthur: For #3, the idea is to save rom space by calculating in real time. I'm limited by 4 megabytes of rom space.
–
DJCouchyCouchNov 24 '12 at 17:26

Alright, I understand now. My question is, how would you save 1024x1024 tiles? That would be a megabit even if the tiles are of two types only and the Mega Drive only has 64KB of memory AFAIK.
–
zehelvionNov 24 '12 at 17:50

1 Answer
1

I would limit this to a SMB(1) style game where the Y-axis is bound throughout the game.
Instead of randomizing everything, I would stick to building mini-stages in advance and then determining which of them will be next using a hash-like function that takes the seed and the current 'x' value to pick the next area. I suspect that because of the computational abilities of the Mega Drive (~7 MHZ), it would be unwise to further burden it with sophisticated level generation when it should be sufficiently occupied with collision detection, enemy behavior and other game mechanics.

If this experiment works out, you could layer mini-stages on top one another, breaking the y-axis bound and getting something similar to what your described.

what you describe is exactly how sonic megadrive works : the levels are made out of giant 128x128 tiles (which consists of sixty four 16x16 blocks, each of them finally mapping to 8x8 hardware tiles). see here: segaretro.org/Block_mappings. Most 128x128 tiles have been made to "connect" to each other, a 128x128 tile can, for example, contains a whole sonic loop (eg: i42.tinypic.com/xpvgic.png). The only difference between sonic game and solution you described, is that the position of these tiles are stored inside rom (as a array of indexes), not choosen randomly.
–
tigrouNov 24 '12 at 23:54

Hi there. I'm aware of that technique. I might use it to reduce the rom usage of "regular" areas. My question would apply to the areas in between, kinda like transitional areas.
–
DJCouchyCouchNov 25 '12 at 0:31