Top 10 community requested features

Not favoritedFavorited Favorited 0 favourites
  • 7 posts
From the Asset Store
80 pieces of loopable game music, 10 game overs and 10 level complete pieces.
  • Can see the full list ranked here:

    github.com/Scirra/Construct-feature-requests/issues

    (You can affect the ranking by clicking 👍 if you want to see certain features!)

    Currently these are the most popular features the community wants to see:

    1. Clipping Mask
    2. Custom Actions: Return Type (variable) — "custom expressions"
    3. Dark theme: change highlight color
    4. Store installed addons in user account
    5. Allow addons to render into webgl2 context (_not_ to C3 canvas)
    6. (SDK V2) Get paired instance instance image
    7. Allow import custom 3D Models (GLB/GLTF)
    8. Specify origin point position when creating new frames
    9. texelSize shader uniform
    10. Editor setting: snap to pixel

    Most of these great requests are about to expire.

  • I did not realise that there was a suggestion hub!

    Does the Dev team actively look to approve and implement them? Or is there a community request threshold that usually needs to be hit? I have quite a few suggestions, not sure they meet the requirements.

    Hoping to see us eventually be able to code and create our own behaviours/effects shaders in the editor and export them out of the project for reuse later, instead of using external SDK Addons and importing them in. Just closer integration.

    Checking it out now.

  • Nice! Yeah they occasionally chip away it. You can see the list of things they've shipped here: github.com/Scirra/Construct-feature-requests/issues

  • They should focus on optimization, because that's the biggest drawback of Construct 3. Similar graphics and functions running in Unity will be much more efficient than Construct. I specifically bought a simple Android for game testing and noticed that many of my projects simply lag on the Oppo A3.

    Also, a decent text editor, which is available in all engines. Why can't we add a border or shadow to the text? I'm not even asking about a gradient. Perhaps I don't understand how text is structured correctly, but I struggled with adding shadows.

    The problem isn't with the code—the code is optimized. The problem is with the engine itself.

    Construct 3 uses too much memory, especially when working with sprites, animations, and textures. Even with careful resource management, size limits, and asset optimization, memory usage remains unreasonably high.

    The problem with spritesheets and rendering is particularly noticeable:

    Large spritesheets quickly inflate memory consumption

    The GPU becomes more heavily loaded than it should be

    Weaker devices begin to throttle

    Similar scenes run noticeably more reliably in Unity—simply because it has better memory management and a better graphics pipeline.

    My other complaint is the debugger. It's completely neglected. Bugs and other errors are practically impossible to track. There are no graphs, no memory tracking. It's absolutely necessary to add the ability to track memory usage for specific events. For example, so that you can see that Event 30 is consuming the most. Even breaking it down by group doesn't help you understand the exact action. I spent a whole day trying to figure out what was causing my lag until I noticed a very hidden every tick rotation; a debugger would have improved this.

    List of active textures

    Weight of each sprite

    What's currently in memory

    Which assets are being reloaded

    Texture / Memory Profiler

    Construct 3 is an excellent engine in terms of ease of use and development speed, but its main drawback is poor optimization of memory and graphics. Nobody raises the issue of optimization because many people's projects are small or pixelated. But a truly large game with thousands of code lines and tens of thousands of lines will simply wreck any mobile device. Except for the iPhone. By the way, text display on the iPhone is still crooked, and I have to use Y-4.

    3D is absolutely not what Construct should be doing. You won't be able to create a game on the level of Unreal Engine or simple Unity indie games. It would be better to focus on 2D mechanics, animations, timelines, and usability, rather than useless 3D features. Construct could become a leader in 2D, although in my opinion, it's the ease of use that makes it so. Thank you.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • They should focus on optimization, because that's the biggest drawback of Construct 3. Similar graphics and functions running in Unity will be much more efficient than Construct.

    We've done a great deal of work on optimizing Construct already, including writing an entire new renderer based on the latest WebGPU graphics technology and taking advantage of the improvements it made possible. 2D content often uses a lot of transparency which generally means back-to-front rendering is necessary, and then the performance you get with that usually depends on the capabilities of the graphics hardware rather than anything the engine does. If you have specific benchmarks I could try out I'd be happy to investigate - there may be more we can do, or there may be some performance pitfall we missed.

  • We've done a great deal of work on optimizing Construct already, including writing an entire new renderer based on the latest WebGPU graphics technology and taking advantage of the improvements it made possible. 2D content often uses a lot of transparency which generally means back-to-front rendering is necessary, and then the performance you get with that usually depends on the capabilities of the graphics hardware rather than anything the engine does. If you have specific benchmarks I could try out I'd be happy to investigate - there may be more we can do, or there may be some performance pitfall we missed.

    Hi Ashley, thanks for the detailed reply. I understand the progress made with WebGPU, and I agree that desktop browser performance is impressive.

    However, from my perspective as a developer shipping mobile games, the core friction points lie in architectural differences and — crucially — the lack of visibility into them.

    Here is a breakdown of the challenges we face on mobile:

    1. WebView Overhead Construct apps run inside a WebView (Cordova/Capacitor). While functional, this essentially runs a full browser instance inside the app. This abstraction layer adds unavoidable overhead in terms of base memory footprint and CPU usage compared to thin native runtimes.

    2. Native vs. Interpreted Execution (The GC Issue) Unity uses IL2CPP to compile to native machine code. Construct relies on JavaScript. Even with V8's amazing JIT, we suffer from lack of manual memory control. Garbage Collection (GC) spikes are the main cause of micro-stutters on mid-range Android devices, creating a "janky" feel even at high average FPS.

    3. Thermal Throttling Because the CPU has to handle the WebView overhead + game logic (mostly on a single thread), thermal load increases rapidly. This leads to aggressive thermal throttling on mobile, causing performance to degrade significantly after 10-15 minutes of gameplay.

    4. Tooling and Profiling (Critical) In my opinion, this is the biggest missing piece. We lack professional profiling tools to diagnose why performance drops. What we desperately need:

    Deep CPU Profiling: Breakdowns of which specific Event Sheets or Functions are consuming frame time.

    Asset Auditing: Visibility into texture memory usage and heavy assets.

    Performance Warnings: Alerts for expensive operations (e.g., "High overdraw detected" or "Heavy logic in Every Tick").

    5. Texture Management Support for KTX2 / Basis Universal would be a game-changer. Unity, Godot, and Unreal use these standards to drastically reduce GPU memory usage. Since WebGPU supports them, native integration in Construct would significantly help mobile devices with limited VRAM.

    6. Text Rendering The current text system is a performance bottleneck. Text objects are heavy, and styling is limited.

    Long text becomes blurry.

    Baseline/offset issues persist on iOS.

    Suggestion: Implementing SDF (Signed Distance Field) font rendering would solve both the quality and performance issues, allowing for crisp text with cheap outlines/shadows.

    7. Blur and UI Effects Blur is standard in modern UI, but it is currently too expensive in Construct (requiring separate layers or heavy shaders). Optimized, built-in primitive effects for UI that don't tank the framerate would be very welcome.

    8. Mobile Simulation Tools It is difficult to predict mobile behavior on a desktop. It would be helpful to have debug modes that simulate:

    Artificial memory limits (e.g., cap at 100MB).

    Low-end CPU throttling simulation.

    Strict FPS caps.

    (Example: My old Meizu PRO 7 crashes if the game exceeds 100 MB of memory, regardless of the event logic. Debugging this without tools is a nightmare.)

    9. I've noticed that even with the Preload Sounds checkbox enabled, the game might not launch at all on my older devices. So I'm forced to disable it to save memory. I don't know why... But with the checkbox disabled, the sounds are terrible. This means I can't create high-quality sounds for a large project.

    Summary I’m not suggesting Construct should abandon the web stack. But precisely because we are running on the web stack, we need better tooling, profiling, and resource control to manage these overheads effectively.

    I love Construct and use it daily. I’m sharing this because I want to see it become even more viable for high-quality mobile releases.

    Thanks for listening!

  • rusya119a - I'm not sure I follow... it sounds like you started off talking about GPU performance, and then you went in to a whole bunch of things but didn't talk about GPU performance again. So I'm confused as to whether you really think GPU performance is an issue now.

    You raised a whole load of things that involve a lot of complex tradeoffs. I could probably write a whole series of blog posts covering a full response. I'm afraid however I just don't have the time to do that. I've just added a few responses off the top of my head in the time I have available.

    I would however point out that you're comparing Unity - a billion-dollar public multinational corporation with thousands of staff - to Construct - a small UK company with a handful of staff. The fact we even merit comparison is, I think, quite a credit to us.

    1. WebView Overhead Construct apps run inside a WebView (Cordova/Capacitor). While functional, this essentially runs a full browser instance inside the app.

    These days I don't think this is actually significant. I also don't believe it affects GPU performance at all - WebGL and WebGPU come down to the same GPU commands a native app would use.

    2. Native vs. Interpreted Execution (The GC Issue)

    Well-written JavaScript code (which we have) can come pretty close to C in performance. It's also been a long time since I've seen good evidence the GC is responsible for any performance degradation. Modern JavaScript GCs are generational, incremental, and concurrent, meaning they have less work to process, collection can happen on different CPU cores, and the work done on the main thread can be done in tiny increments well within a frame time, all making the performance impact negligible in most cases. People often misattribute things like this - what if you're skipping frames because of v-sync scheduling misses? It's necessary to rule out other causes like that before you point the finger at GC. So please share your evidence - if GC really is an issue in some case, it is possible we could optimize things to reduce GC pressure - but as I said it's been a long time since I've had to do that.

    3. Thermal Throttling

    Thermal throttling happens in the hardware and affects all software.

    4. Tooling and Profiling (Critical)

    If you want more advanced tools in this area, use the browser developer tools. They have things like performance profiles, flame graphs, memory analysis and more.

    5. Texture Management Support for KTX2 / Basis Universal

    Compressed texture support involves tricky tradeoffs. All compressed texture formats are lossy, and so degrade the quality of your artwork. This is generally a poor fit for 2D content where people want pristine artwork. It's easier to get away with lossy images with 3D content, as it often appears distorted (e.g. far away, at oblique angles, or wrapped around a mesh). Perhaps we could do this now Construct has 3D model support, but then you run in to the next tradeoff: compressed texture formats have much poorer compression than WebP/AVIF. So if you put everything in that format, the project download size would get significantly larger - not great for a web-first engine. You could download WebP/AVIF and then encode to compressed texture formats on startup, but that could significantly increase in-game load times. I don't think there's an easy route to have both a small download size and fast loading times with compressed textures.

    Suggestion: Implementing SDF (Signed Distance Field) font rendering

    SDF font rendering is monochrome. The Text object supports quite a lot of color formatting options, as well as color emoji. So this also involves tricky tradeoffs and is definitely not as obvious a thing to do as it might sound.

    7. Blur

    We could definitely do improvements in this area. The main complication is the effects compositor is one of the most complex parts of Construct.

    8. Mobile Simulation Tools

    Browser developer tools can emulate mobile behavior and even allow throttling performance. However I don't believe there will ever be as good a substitute as running on a real device. I don't think anyone else in the industry heavily relies on powerful PCs trying to pretend to be a weaker device, instead of just having some actual devices to hand to run on. Construct's Remote Preview makes it pretty quick and easy to try things out on mobile devices, and it's one of the reasons we have it.

    9. I've noticed that even with the Preload Sounds checkbox enabled, the game might not launch at all on my older devices.

    If you ask Construct to load the entire project's audio in to memory on startup, then yeah, it's going to potentially use a lot of memory. So if you want to reduce memory use, you should definitely turn that off.

Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)