Suggestion: 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

https://construct3.ideas.aha.io/ideas/C3-I-1463

Dictionaries or the Json object if you're feeling masochistic.

Unless you need an object to host a behavior like Timer, Tween, Sin, or LOS.

Sounds more or less like a classic Null-Object. I´d take that.

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.

The performance impact of using a sprite should be almost zero. The quad issue performance test measures performance for rendering sprites; if you make the sprite invisible, it doesn't even do that work. Even if it does, it's 1/300000 of the work, which is negligible. So I don't see any performance argument for this at all. Maybe there are other reasons for it, but performance is not one of them.

Performance is important to me because I want it to run on old mobile devices so every little bit counts.

I'm trying to convince you with big words and advocate for both user friendliness and growth of the community.

I hope that once my game releases people take construct 3 seriously for big projects and you get more money

I'm sorry if it makes you cringe, but I do my best.

I think that my results and the performance of my game with a thousand AI doing 3D collision detection and moving and doing physics and sorting counts for something and gives some weight to my opinion, even if it doesn't always make sense to you, that you will consider it.

also Ashley, how difficult would it be, engine wise, to dynamically add and remove objects from families/containers at runtime and at an instance-level, rather than object type.

I'm asking because picking is pretty much the main thing in the engine, and accessing properties from a container object is great, it lets me use self and reference a containered object and it will automatically get picked instead of having to do a "foreach" or function call with UID to pick to do the action.

what I'm ACTUALLY trying to do and why i made this suggestion, is to dynamically create objects and give them properties at runtime so that the game loops through every object with an animation property and steps animation, same thing for collision and physics and gravity, etc, without creating a giant object that has every single property and looping through that massive object and picking by boolean "animation", "collision", "physics", "Gravity" and so on, because creating that massive object is a logical and debugging nightmare.

what I've started doing is creating a "gravity" empty object for example, giving it the UID of the game object that needs gravity applied to it, and do pick by UID gravity.gameobjectUID, and then run the action on game object, to not have to bloat the code with conditions and seperate things.

Another way would be to make like, 20 copies of the gravity object and put them in a family and then container with their specific immutable game object and do familygravity

I don't have the skills to really give any input on this, I'm essentially an UI developer, but what eleanor said about dynamically creating shell objects with the exact amount of information you need them to have sounds amazing, mainly through the argument of demanding less instance checking, like the wall slide she mentioned.

I'm still reading through the posts again and trying to understand everything, but just wanted to show some support.

I'm not really clear on what you're trying to do - instance variables are the usual way to add extra data per-instance. If you need more sophisticated data per-instance, you can put a dictionary or array in a container with a sprite, and then you get a whole dictionary or a whole array per-instance. I'm afraid it's still not clear to me what a new empty object type would add to this?

Give me some time I'll work on a prototype to show what I mean exactly.

sorry i keep writing these super long posts

Seems like this is going into the scene graph territory.

Better containers that efficiently express the parent child hierarchy in pairing, and un-pairing.

I'll be honest before this post i had no idea what scene graph meant and I still don'T really understand. Would this fit my needs or make things worse, I don't know.

This whole engine is about picking, so I need a more flexible way to pick without impacting performance in a negative way.

How? I don't know. All of this is just suggestion, but the suggestion itself isn't the goal. The goal is picking.