Minecraft/terraria style block system?

[Tsun]

Simple version: Is this possible?

Long version:
I've been playing a lot of Terraria lately, and while talking to my friend, it sparked an inspiration towards a game using a similar interactive block system for the map.

While I could probably do the system itself, the problem comes with the immense amount of tiles in the game. I would need a sprite tile and an obstacle tile for every single block, which would amount to hundreds of thousands if not millions in larger maps. The game can't really handle this, can it?

My initial thought was to paste a blank tile to background in layer 1 as an obstacle, do the same with a sprite tile to layer 2 as not-an-obstacle, and then delete the involved active objects. But apparently I was wrong when I thought that "paste into background" leaves no objects to the game.

So is there perhaps some way to get this done without lag? And how exactly does MMF handle this large maps anyway? Is there some way to separate the map in chunks and connect them seamlessly together, while only the nearby chunks being active?

[Shawn]

You might be able to do some trickery with jumping frames at points and somehow making it appear seamless, but that sounds awfully difficult and I have no idea how it might work. lol

[DaveC]

well you wouldn't need a 'sprite tile' and a obstacle tile.. you'd only need one active object and have the player interact with them. It could be easily possible if you just made smaller sized maps that connect.

[Konidias]

You'd want to generate the surrounding area of tiles on the fly. If you create a way to load the tiles via a file or level data, you could generate tiles within the screen (with a bit of overlap to prevent seeing the tiles generate at the edge of frame when moving)

This would limit the number of actives to just what you currently see on the screen. Doing this means you'd need to be reading and writing to the level whenever anything changes, so that the updates to the tiles stay the same when they move off screen and get destroyed.

Generating on the fly is how a lot of games do it. Even Minecraft only generates x amount of blocks surrounding your character. No need to load 10 million blocks when you're only seeing a few thousand at a time.

[Tsun]

You might be able to do some trickery with jumping frames at points and somehow making it appear seamless, but that sounds awfully difficult and I have no idea how it might work. lol

That's what I initially thought about, but I don't know how to do that either. :P

well you wouldn't need a 'sprite tile' and a obstacle tile.. you'd only need one active object and have the player interact with them. It could be easily possible if you just made smaller sized maps that connect.

My idea was to use a grid of numbered entities, and whenever something would interact with a block, the game would load the number in that spot of the grid and act according to it. To my knowledge active objects are much more laggy than background objects so... :P

You'd want to generate the surrounding area of tiles on the fly. If you create a way to load the tiles via a file or level data, you could generate tiles within the screen (with a bit of overlap to prevent seeing the tiles generate at the edge of frame when moving)

This would limit the number of actives to just what you currently see on the screen. Doing this means you'd need to be reading and writing to the level whenever anything changes, so that the updates to the tiles stay the same when they move off screen and get destroyed.

Generating on the fly is how a lot of games do it. Even Minecraft only generates x amount of blocks surrounding your character. No need to load 10 million blocks when you're only seeing a few thousand at a time.

Ohh that's a great idea. This was something I was going for with the separate chunks, but I didn't think of generating the world in realtime. The only problem would be how to load parts of the map so quickly all the time, but maybe I need to separate the map in chunks afterall and save them separately. Smaller file is faster to read. Thanks for that tip.