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.
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!!!").
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.
- Load sprite on start of layout*
- Edit missing texture
- Unload texture by selection (+option to keep sprite on layout or destroy it)
- >On texture loaded into memory
- Get texture memory loading progress (from 0 to 100)
* 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".
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!