Which is the best way to make a large map inside Construct 3 for a side scrolling game?

• Which is the best way to move if a developer who uses Construct decides to make a large map which, in general, would be composed of always-changing graphic elements and scenarios?

• The fact the map is supposed to be with a high degree of difference between the elements that compose it, does it imply not having to use the tile-map or in any case will it have to be used even for that kind of map?

• Will it be inevitable in that way I'm going to create a game that will be necessarily too heavy or are there expert measures and moves in cases of this type, that allow to cushion the "huge size" during developing?

It depends on what you mean by "always-changing graphic elements and scenarios".

Generally this is why we have different layouts.

In game design you have x amount of memory that you don't go beyond.

That with everything that's going on cpu wise are the limitations.

It depends on what you mean by "always-changing graphic elements and scenarios".

Generally this is why we have different layouts.

In game design you have x amount of memory that you don't go beyond.

That with everything that's going on cpu wise are the limitations.

By that expression I mean the background of the game has elements that are always different and never repeated. For example, a side-scrolling game set in a city whose buildings are always different so that you cannot recycle previous assets. So the problem that arises is related to the fact that, if the background were procedural and could replay itself to infinity then ok, fine, you can get by its repositioning through the X and Y coordinates.

But with a non-procedural background that is always different? What size should the entire layout be, as large as the level itself? And doesn't that mean making the game necessarily too heavy?

Layout size doesn't matter. The amount of memory used does.

You can't just shovel a bunch of assets in, and hope for the best. You can swap textures, but you have to be careful of when and how its done.

So basically, what you described on one editor layout? Probably not.

Programatically during runtime? Sure. In fact this is one descriptor away from an endless layout.

You will need to know which objects with instances share the same texture, and which don't.

Then you will have to figure out how to balance the swapping of textures, and the timing.

No game will have a background with elements that are never repeated.

All games repeat certain textures with variations in size, and orientation.

Ok, I've made a quick sketch of my doubt. Pardon my being that nooby in terms of art quality.

construct.net/en/make-games/releases/beta/r117-2

Basically you'll be manually loading an unloading your sprites during runtime to keep memory usage reasonable.

I would not recommended doing this unless you're really confident you know what you're doing.

If you're thinking of drawing one big image the length of the layout, or making a composite by adding new objects that just add to the amount of ram used, and that ram exceeds what the user's hardware can afford, then yes that won't work. That's not how games, and even computers work.

construct.net/en/make-games/releases/beta/r117-2

Basically you'll be manually loading an unloading your sprites during runtime to keep memory usage reasonable.

I would not recommended doing this unless you're really confident you know what you're doing.

If you're thinking of drawing one big image the length of the layout, or making a composite by adding new objects that just add to the amount of ram used, and that ram exceeds what the user's hardware can afford, then yes that won't work. That's not how games, and even computers work.

So, in conclusion, what's the alternative for creating such a map? Does it exist or the alternative is making necessarily a procedural and tiled map with a narrow range of variations?

Asked and answered. It will take the use of swapping textures, and a lot of experimentation to do so.

There are no specific templates, or demo's because it's not a recommended thing to do.

Note that "2d" platform games with huge, nonrepeating assets and levels such as ori and the blind forest and child of light are actually created in a 3d engine, which has different rules. The memory budget for textures is still a thing to consider, but the geometry is drawn during runtime. This allows for basically unlimited shapes to paint textures onto.

For 2d engines, the common approaches for huge levels are either tilemaps or reusing scaled/stretched/tinted assets. See construct.net/en/blogs/construct-official-blog-1/remember-not-waste-memory-796 for an example.

As I mentioned before though, Construct 3 allows for the ability to load and unload sprites/textures from memory on demand. This will allow you to basically stream in assets as needed, as long as you clean up any unneeded ones at any given point. This can be difficult to design around, considering the graphics memory capacity of user devices can vary greatly, not to mention a lot of work.

Note that "2d" platform games with huge, nonrepeating assets and levels such as ori and the blind forest and child of light are actually created in a 3d engine, which has different rules. The memory budget for textures is still a thing to consider, but the geometry is drawn during runtime. This allows for basically unlimited shapes to paint textures onto.

For 2d engines, the common approaches for huge levels are either tilemaps or reusing scaled/stretched/tinted assets. See construct.net/en/blogs/construct-official-blog-1/remember-not-waste-memory-796 for an example.

As I mentioned before though, Construct 3 allows for the ability to load and unload sprites/textures from memory on demand. This will allow you to basically stream in assets as needed, as long as you clean up any unneeded ones at any given point. This can be difficult to design around, considering the graphics memory capacity of user devices can vary greatly, not to mention a lot of work.

Perfect answer. 100% on point. Thank you for the explanation. Thanks also to newt and all the others but your answer is exactly what I was looking for.