Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.


Merged idea

This idea has been merged into another idea. To comment or vote on this idea, please visit C3-I-111 Load/Unload Sprites from RAM.

Construct 3 - The Case For Advanced Memory Management Merged


Construct 2 & Construct 3 are both great pieces of software but they still lack features in my opinion, specifically features which give game developers more access over Memory Management.

Nowadays games use more and more high quality textures in order to support constantly improving screen-sizes and their higher resolutions but hardware mostly can't catch up with these improvements and requires advanced types of optimization.

In my opinion the following suggestions would not only make Construct 3 more flexible and improve usability but they could also make Construct 3 more attractive towards more advanced game developers, with more advanced projects in mind.



Table of contents:

  • The Issue With Layout To Layout Loading
  • Sprite Plugin 2.0 (Basics)
  • Sprite Plugin 2.0 (P + ACE's)
  • Example Of Use


The Issue With Layout To Layout Loading:

The most common memory related "crashes" are without a doubt occurring during the layout-loading process. The current layout-to-layout loader loads every texture into memory on the start of the layout (before the actual condition trigger).

This basically means that low-end devices (especially mobiles) will run out of memory and crash while loading into memory demanding layouts. So far neither Construct 2 nor Construct 3 offer features in order to workaround these kinds of issues.

While competing game engines offer features to customize and take control over the loading process of textures, Construct 2/3 don't and all that game developers can do is forcefully reduce the quality of their game assets, which usually leads to negative feedback regarding the game's quality (e.g. "OMG, THIS GAME'S GRAPHICS LOOK SO BAD, IT'S 2017!!!").


Sprite Plugin 2.0 (Basics):

In order to bring Construct 2/3 on-par with competing game engines, advanced memory management features have to be implemented. These memory management features include runtime changes to the layout loading system and Sprite plugin.

We need to be able to select the sprites that we would like to load into memory on start of the layout. This could be done using a property inside the Sprite plugin. The new layout-loader would basically check this specific property in order to determine what textures need to be loaded in at the start of the layout and which don't.

Textures which have this property checked and do not get loaded in, would also require an additional "error texture" to be specified. This texture can be set by the developer and the developer would be able to decide to perhaps use the popular Half Life Missing Texture or even leave it "blank" so that the instances are still on the layout but invisible and ready to be loaded into memory for later use.


Sprite Plugin 2.0 (P + ACE's):

Sprite Plugin Property Action Condition Expression

- Load sprite on start of layout*

- Edit missing texture

- Unload texture by selection (+option to keep sprite on layout or destroy it)

- Unload texture by name (+option to keep sprite on layout or destroy it)

- Load texture for picked sprites (+option to override/replace selected frames of animations) (+option to load in intervals to reduce loading lag)

- Spawn sprite by name/selection/etc (+option to load it into memory or create blank** instance)***

- >On texture loaded into memory

- >On texture loading error (e.g. device doesn't have enough memory, stops the process to avoid crash)

- Is loading textures into memory (any)

- Is loading textures into memory (by name or selection)

- Get texture memory loading progress (from 0 to 100)

- Get texture memory loading progress error message


* During the layout loading process.
** Instance with an "error texture" applied to it.
*** This change also requires to be applied to the system action "Create object".


Example Of Use:

Generally open-world games with higher resolutions (e.g. 4k) would benefit from these features. Developers could simply pick and load in the sprites of one part of the game world, while leaving the rest of the world unloaded.
Please keep in mind that "unloaded" does not necessarily mean destroyed!

A good and more specific example could also be the Metroid franchise, especially the older 2D games. In those games "rooms" were loaded into memory on the fly, giving the player the impression that everything is loaded into memory from the start.



I understand that from a game-engine developer's perspective this might not seem to be that relevant but for a lot of people including myself, it is quite relevant and in my opinion required.

I also understand that these types of features will probably require runtime changes and I'm personally OK with seeing this being implemented into Construct 3 only.

Thanks for reading through my idea and I'd very much appreciate a positive response!



  • TheRealDannyyy
  • Oct 19 2017
  • Shipped
  • Admin
    Ashley Gullen commented
    September 11, 2018 16:39

    I'm merging this idea with C3-I-111 because it essentially proposes the same high-level feature (memory management for textures). A few notes on the details of this idea:

    - none of this is specific to Sprite: memory management extends to tiled background, 9-patch, particles, other third-party addons, etc. so the feature should not focus solely on sprites

    - layout-by-layout *does* give you control over which objects are initially loaded: it's those that are initially placed in the layout. You can delete all instances of an object from a layout and its memory won't be loaded for that layout. This also makes the property for "load on start" redundant, because the presence of an instance implies it is enabled.

    - the Construct engine won't support showing an "error texture" - they will simply skip drawing until they are loaded. This avoids unintended content appearing in the game and significantly simplifies the feature development (since we architecturally do not have a way to have a separate image in addition to the main ones the plugin uses). The entire "not yet loaded" state can be avoided anyway by making sure not to create instances until their textures are loaded.

    I think the best approach is just to add some system features to load/unload objects, which is pretty much what the other feature suggests, and it was also posted before this one and gained more votes, hence merging this idea in to that one.