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.

16 Vote

Add a new empty object type

Everyone puts sprites right outside of the viewport that holds instance variables to reference later with events or that holds important variables you don'T want to pollute the global variable scope with.

I suggest adding an empty object type that contains all of the usual instance variables and families and containers of other type of objects, but none of the internal engine stuff that has to be updated like a sprite's X and Y and Quad or the array object'S methods,

I suggest to have a lightweight object type to use for instance variables that is cheaper to instantiate and destroy, and has no risk of showing up on the screen or causing bugs

  • Guest
  • Jul 26 2020
  • No status
  • Attach files
  • Eleanor Jacques-Morel commented
    30 Jul, 2020 12:43am

    From a simple performance point of view, if you modify the quad issue performance test to spawn empty arrays instead of invisible sprites, you can spawn around 300k sprites, but millions of arrays(until out of memory) with basically no CPU bottleneck because they do not tick system properties like their quad, their X or their Y, etc...

    But using arrays like this is not very intuitive for users and array are not perfect either because they have useless actions and conditions so I'm going to assume that empty game objects would use less memory and be easier for the engine to create and destroy with less garbage collection.

    I want to add that for my use case, my game objects are empty arrays that only spawn a sprite once they enter the screen, making picking and sorting much faster and removing overhead, and they're updated and controlled with instance variables. By making my game this way, I've about doubled the amount of objects I can put in the game which is very significant.

    Another use I have for these is for rare conditions, for example, playing a sound while a character is sliding down a wall. Instead of adding a condition for every single game object to check if they're sliding down a wall or not and keep playing the audio for it or stop it, once a player touches a wall, an empty object is created with the player UID saved as an instance variable, and I have a condition that makes these objects check if their corresponding player is still sliding down a wall or not, and this kind of code greatly reduces the CPU usage because these kind of conditions don't need to be checked on every single object on every tick anymore, instead of creating a condition for every object, it loops though this seperate object type and runs the condition on the related player object, and that new object type isn't created for game objects that can't slide on walls, so that property doesn't need to be checked on every tick either.

    I think this use case for construct 3 is very important because it lets users make their own unique game and physics and player movement instead of relying on the behaviors, and reduces bugs and feature requests for those behaviors because while behaviors are good for all around game mechanics, they're usually not suitable for specific mechanics users have in mind to make their games unique and there'S very little they can do to change the mechanics since they rely on built-in physics they have no control over and since they haven't practiced creating their own, they end up using band-aid fixes to keep their game together and become pretty unsatisfied with their game's stability and performance and start thinking and saying that the engine is limited for small games and hobbyists and switch over to a different engine.

    I'm currently writing a series of tutorials that teaches all of this.

  • Admin
    Ashley Gullen commented
    29 Jul, 2020 10:19am

    A single off-screen sprite should have virtually zero performance impact. So there doesn't seem to be any problem with this. Do you have any actual measurements indicating there is any benefit to be had from a new empty object type?

  • Guest commented
    28 Jul, 2020 12:07am

    I don't even use Globals anymore, this would be awesome.

  • +8