The way object types and instances interact currently feels inconvenient

Hey fellow developers. I didn't want to jump right to the feature suggestion platform, but hear other opinions on this first.

In C3 the object types in your project window aren't primitives/prototypes (which I'm used to from all other engines I've used). Instead, if you select an object type and there's no instance on the scene, you can't change any properties.

Usually when you create an object during runtime you'd except it to inherit the properties of the prototype but since there's nothing comparable in C3, here's what it does:

1. look for the first layout (lowest index) in your game with an instance of the object
2. look for the first instance of the object on this layout (lowest layer index and lowest z index)
3. make this instance the prototype

In my opinion this is counterintuitive. You need to know and keep in mind that you need a loading/setup layout on which you place all objects that need some sort of prototype (I guess a lot of you already have this). It needs to be at the very top of your project, if there's an instance of an object on an earlier layout (lower index), that instance will be made the prototype instead.

It's also inconvenient in that whenever you want to change a property of a prototype you have to switch to this layout, change the values there and switch back to the one you're currently working on.

I've created a small project for demonstration purposes. Try changing the order of Layout 1-3 and see the differing results for the instance that gets created during runtime. Then put the "Layers" Layout first, change the order of both "instances" layers, and see the differing results. Am I alone in thinking that this is counterintuitive?

dropbox.com/s/1c3zm04u9gjsk38/types%26instances.zip

Why is any of this necessary. Simply have your objects in whatever layout they are supposed to be as they are supposed to be.

You need to know and keep in mind that you need a loading/setup layout on which you place all objects that need some sort of prototype<

Not sure why one would need this. You only need an instance of the object in a layout if you are going to create it using system>create object event. And then you can just change whatever you need to change using actions, although you can simply have a single instance in that same layout as it is supposed to start out.

Whenever possible probably better to avoid creating anything. Just place everything in your layout so it starts out like that. Objects can be hidden off screen instead of destroyed and recycled instead of create>destroy>create......

BadMario What you're describing doesn't work, that's exactly the problem that you see in the demo project.

There's an instance on every layout but the dynamically created one doesn't behave like that pre-existing instance. Instead the created one differs in behavior depending on the order of your layouts, which is a strange way of handling prototypes in my opinion.

Maybe a bug in Construct 3? I have never had this problem in version 2 and I still use that to develop. Just bought subscription to 3, but have not really used it except for some testing.

So you are saying that if I create something in layout5 instead of it being a clone of the instance in layout5 it will be a clone of an instance in layout3 for example, if there is one already there?

Yes, that's how things currently work. The most convenient solution for this would be to handle it like most other engines do: objects in your project window are the prototype instead of some instance that is lying around somewhere in your project.

I think i had the same confusion once how that worked i long time ago, and i see its still the case

it presumes that you setup the stage with all your base objects

if you multiple instances, its not clear what the prototype is, its more a managing thing at that point

why they do it like this?:

in the end, i think its because its easy to set up initial value's for the prototype like this , so you dont have to specify or change certain properties manually, easy for testing like different sizes, etc..

---

on the other hand it could take and set basic default properties, then you change in code once created.. and trow away the need for instancing objects in the level editor , it would be more a standard way of working,

not sure if its worth changing it at this point..

perhaps a button that directly jumps to the prototype that will be used , is faster and easy

You're right, a prefab system would totally work - but it's also a huge undertaking (of course adding tons of value besides fixing the described issue once it's done).

Something that worked great in another engine I've used is this: Objects in your project window are prototypes which you can select to change properties, like you would do with instances in your layout. Dynamically created objects inherit these properties. Changing properties of an instance on any layout makes a button appear next to the property for resetting the value to match the prototype.

Unity has a similar system where you can right click values and reset them to match the prototype in your project window.