Construct Games have very high RAM usage on Steam Deck

As of now it is clear to us that the best way to go about making games with Construct is to keep them small (due to browser memory limits which we are dealing with sadly. Engine crashes very often (out of memory error) because of how large the project is

As far as I'm aware browsers, and Construct, don't have any particular memory limits that would affect even a large game. For example you can use as much texture memory on the GPU as you can - there's no limit there. No matter what software or technology you use, it's up to you to design your game efficiently and not use too much memory.

Temp file creation is also an unexpected issue with games made with Construct. Players have reported over 10gigs of temp files get created over a 20 hour total play session.

Construct doesn't itself try to create any temporary files, and that sounds like some kind of fault. I think it's possible it's also a bug in your project, e.g. if it has a storage leak - hard to say without a bug report.

There is also the issue of the games running on NWjs so devices with dual graphics card often offload NWjs games to the onboard card

Yeah, that's been a long-standing problem, but it's difficult to do anything about - the graphics card vendors have system-level software that overrides what the app asks for. You could try contacting them to change the default for your game. I think people found some workarounds, but they don't seem to be well documented. AFAIK this affects all indie games in general - if you publish a game that isn't big enough for the graphics card vendors to know about, then their system software often defaults it to the low-power GPU, regardless of what the app asks for (if your project property 'GPU preference' is 'High performance', which is the default, then Construct is asking for the better GPU on dual GPU systems, but the system may ignore that request).

As far as I'm aware browsers, and Construct, don't have any particular memory limits that would affect even a large game. For example you can use as much texture memory on the GPU as you can - there's no limit there. No matter what software or technology you use, it's up to you to design your game efficiently and not use too much memory.

I think the main issue here is that C3 seems to have a hard time handling memory with large amounts of image data. Even if that amount is way below the memory limits, when C3 is generating spritesheets, it seems like memory usage skyrockets the more images there are, and very often it leads to memory overloads.

I've seen the issue happen on both Biogun and Astral Ascent, and usually the exact memory management efficiency vary depending on the browser being used. At the time I remember Edge was more efficient with memory, but now that it's Chromium based it might not make a difference anymore.

It's way easier to get the crash when using larger spritesheet sizes and with multiple layout tabs open or multiple browser tabs/programs open on the computer.

Currently, to minimise the crashes happening, you need to use only one or two layouts, and load the minimum amount of icons and sprites because any new icon spritesheet or sprite spritesheet being generated can cause the crash.

I don't know if that can be fixed, but I think C3's spritesheet generation algorithm could maybe be made more memory efficient when too many images need to be handled, even if that means going slower.

Also, an alternative could be to save the editor spritesheets in the project files within a special editor folder like uistate files so the sheets don't have to be generated again every time the project is opened. That folder could be gitignored to prevent merge issues.

when C3 is generating spritesheets, it seems like memory usage skyrockets the more images there are, and very often it leads to memory overloads.

I had assumed the previous discussion related to the runtime. If you are talking about the editor, that is quite a different matter - it may cause you some problems during development but it should not affect the experience of gamers playing published games at all.

FWIW the editor has a fixed limit on how many spritesheets it will render at once, specifically to cap the memory usage. For example if you have 1000 spritesheets, it will only render/compress something like 10-20 (I forget the exact limit) simultaneously at any one time, so the peak memory usage should only ever be the amount of memory used by the handful of spritesheets that are currently being processed.

FWIW the editor has a fixed limit on how many spritesheets it will render at once, specifically to cap the memory usage. For example if you have 1000 spritesheets, it will only render/compress something like 10-20

Do you think it's possible to have an experimental setting (even something hidden like a URL query param) to change that limit? I'd be down to give it a try and report if changing the limit helps or not.

The easiest way to deal with this, as with anything else, is to file an issue following all the guidelines. You can use a project filled with dummy content rather than providing any sensitive project files. With that approach issues can be fixed maybe 10 times faster.