I'm working on the Sega Genesis that has a 8mhz Motorola 68000 CPU.

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.

  • \$\begingroup\$ 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. \$\endgroup\$
    – Eric B
    Nov 24, 2012 at 15:53
  • \$\begingroup\$ 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? \$\endgroup\$
    – AturSams
    Nov 24, 2012 at 16:06
  • \$\begingroup\$ Sorry I wasn't clear. I'll update my description. \$\endgroup\$ Nov 24, 2012 at 17:22
  • \$\begingroup\$ @arthur: For #3, the idea is to save rom space by calculating in real time. I'm limited by 4 megabytes of rom space. \$\endgroup\$ Nov 24, 2012 at 17:26
  • \$\begingroup\$ 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. \$\endgroup\$
    – AturSams
    Nov 24, 2012 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.

  • \$\begingroup\$ 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. \$\endgroup\$
    – tigrou
    Nov 24, 2012 at 23:54
  • \$\begingroup\$ 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. \$\endgroup\$ Nov 25, 2012 at 0:31
  • \$\begingroup\$ As for the game itself, you can find a video of its current state here: youtube.com/watch?v=1jyG4kZ8GoE& \$\endgroup\$ Nov 25, 2012 at 0:32
  • \$\begingroup\$ that looks pretty good. reminds me the flying sheep in worms. \$\endgroup\$
    – tigrou
    Nov 25, 2012 at 11:04
  • 3
    \$\begingroup\$ youtube won't let me see the clip... says it's private \$\endgroup\$ Mar 24, 2013 at 21:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .