Massive Layouts

This may have been addressed before on the forums.

I'm working on a game that's going to have ridiculously large maps, so I need to rely on Construct being able to work with large layouts.

I was deciding on whether or not I should separate the game into many different large layouts for the stages, or if I should make one super-map in a single, stupidly large layout, with size values like 9999999, which it apparently allows and seems to work with.

I haven't tested doing this very much and I have no idea what kind of things it might incur, such as growing unstable or leading to crashes, or very long load times, what have you.

I want to know if this is doable and neither Construct nor the game will end up with serious issues like these if I work with one enormous layout for the whole game. It appears to efficiently cull only whats needed, but APPEARS to isn't enough for me to know. I don't want to get far into development only to wind up with sudden crashes that start happening.

Does anyone know enough on these matters to say what could happen? If this is doable?

You should definitely not use layouts that size. As I understand it, floating point precision starts getting less accurate at 100,000 pixels.

Also, CC may be fast, but there is still a bit of overhead from having an object in the layout. My computer can manage 100,000 sprites in a layout at 60fps, but that's with no code or behaviors at all.

It would also use a lot of memory, and likely would take longer to load as well. These reasons are why games segment areas. Games that don't segment areas fake it by streaming in data to make it seem like it's one huge area - it is, it's just only processing one part of it at a time.

I agree with Arima.

The best way would be to either divide it up and have sections that required screen transitions, or fake it by using unbounded scrolling (unlimited scrolling layout) and load the data/scenery based on player position, using an array or similar method.

~Sol

I started out with Construct with the classic "I want to make an RPG!" attitude. I used layout sizes around 15,000 by 15,000 pixels in size, and quickly saw the limitations.

Because of the huge emphasis I was placing on high resolution hand drawn textures and environments, I quickly surpassed Contruct's limits when it came to loading textures. It just isn't stable enough, and the editor crashed while SAVING as often as it crashed while attempting to play the game.

So in short: From my experience, only work with massive layout sizes if you are using small and few textures within that layout. Construct seems to want to draw EVERYTHING in a layout at load-up, so creating a whole world in one layout is bound to be problematic.

So in short: From my experience, only work with massive layout sizes if you are using small and few textures within that layout. Construct seems to want to draw EVERYTHING in a layout at load-up, so creating a whole world in one layout is bound to be problematic.

Construct Classic probably loads all graphics into RAM if an object exists in the layout to avoid predicting when to load and free the RAM. Only a custom engine can probably get away with that because they are designed for a specific game.

The trick is to load certain parts of the game near the player at runtime, and free up memory of things far away like SoldjahBoy said. Only position/angle/status data needs to be stored of an object if it loads a texture/model from a file, otherwise you should be able to store the custom or modified texture to a file and load it again later.

I might use separate layouts if it weren't for the runtime error that occurs everytime I either:

Go to a different layout.

Restart the same layout.

Load a game save.

I have been working on a different game and made a very large map, a size in the tens of thousands, and neither Construct nor the app so much as coughed about it. I heard layers were rendered as textures so it didn't make sense to me that it could handle images that large unless it were culling things off screen. Mind you this layout had several layers with various graphics and objects spanning the size of the map, the level layouts, decorations, background layers, game objects, etc.

Loading only parts of the map when the player is near is a good idea too, but how do I do that? Do you mean loading external images in place of sprites? I tried that too and it was picky about what images were loaded. Some images worked and others gave me the same runtime error that changing layouts gave me.

The error was something like "Microsoft C++ pure virtual function call" something or other. The game technically didn't crash, but if OK was clicked it would abort, and sometimes things like missing sound would happen.

I might use separate layouts if it weren't for the runtime error that occurs everytime I either:

Go to a different layout.

Restart the same layout.

Load a game save.

Are you using transitions? If I recall correctly, those can cause crashes. The 'or' condition can cause crashes as well.

If you want to find out what's causing them, save a copy of your .cap then start deleting chunks of code to find out what causes it.

I have been working on a different game and made a very large map, a size in the tens of thousands, and neither Construct nor the app so much as coughed about it. I heard layers were rendered as textures so it didn't make sense to me that it could handle images that large unless it were culling things off screen. Mind you this layout had several layers with various graphics and objects spanning the size of the map, the level layouts, decorations, background layers, game objects, etc.

Tens of thousands is no problem. Layers are only rendered as textures if you set them that way in the layer properties. Even then, it's only the part of the layer that's visible on screen. Stuff that's off screen isn't rendered, the graphics card takes care of that automatically, but the logic of the objects is still there and being processed.

Loading only parts of the map when the player is near is a good idea too, but how do I do that? Do you mean loading external images in place of sprites? I tried that too and it was picky about what images were loaded. Some images worked and others gave me the same runtime error that changing layouts gave me.

Don't load external images unless you're willing to put up with a delay while the hard drive reads the file, stores at memory and then flings it to the graphics card. That can take long enough to be noticeable. Best to load from files during transitions between areas.

You would want them to be preexisting objects that you create and destroy based upon the proximity of the player. You could divide all of the objects into a sections on a grid, save all of the instances in each grid cell to an array, and when you get close to the boundary of one section, you could create all the instances in the new section, and when far enough away from the old one, delete them. This isn't really a simple thing though.

This is all excellent advice. I'm not using transitions but there is one or two OR conditions somewhere in the code. I'll start messing around to see what the cause is.

And no I haven't the faintest idea how to do this grid thing you're talking about. Could I not just manually define things like once the player is within this area (that is a stage) load everything here, when not, remove everything here. I wish I could do the grid thing though that sounds a lot more convenient.

I found a really nice example .cap from the russian site, can't find it right now. I uploaded it to my dropbox. I'll link the original thread when I'll find it.

http://dl.dropbox.com/u/26932498/worldstreaming_example.rar

Isn't that an example of streaming? If someone could make a tutorial how this was done. You could make really great maps with it, using that technique?

I'll take a look at this, thank you.

Anyway after trying Arima's suggestion (which I should have done in the first place really) I discovered it was strangely all because of the zip file object. I had one in the layout and once I removed it, the error never showed up again, so changing layouts is now not a problem. I hadn't used the zip object yet but I intended to, so I hope I still can. If not I'll just do something different for the assets.

Also, for reference, the exact error message I was getting was this:

img837.imageshack.us/img837/3254/r6025.png