C3 now the operation logic is filtering. Is it possible to bind a single event table to a single ..

C3 now the operation logic is filtering. Is it possible to bind a single event table to a single object in the future

What do you think?

Could be interesting. It would work like a behavior I assume.

I don't understand what you are suggesting/asking.

What is an "event table" ?

Currently in Construct, that doesn't exist, does it ?

Also "bind [...] to a single object".

Are you talking about picking a single instance ?

Because, that is already in and how events work.

From my understanding the idea is to create a special eventsheet that you can assign to objects rather than layouts like a behavior and that also work like behaviors.

I like the idea because it could be useful in terms of reusability and is a step towards the "write plugins with events" idea that Ashley hinted at about 2 years ago.

From my understanding the idea is to create a special eventsheet that you can assign to objects rather than layouts like a behavior and that also work like behaviors.

I like the idea because it could be useful in terms of reusability and is a step towards the "write plugins with events" idea that Ashley hinted at about 2 years ago.

People occasionally suggest something along the lines of "associate events with a single instance", but it's not clear what that would actually do. Would the events run differently? If so, how exactly? If not, what's the point?

People occasionally suggest something along the lines of "associate events with a single instance", but it's not clear what that would actually do. Would the events run differently? If so, how exactly? If not, what's the point?

Let me explain. If you've ever used Unity or gamemaker or godot. Their operation logic is by binding the script to a single obj. As WackyToaster said, it looks like the [behavior] being used in C3. Doing so avoids filtering and makes more complex operations on the Obj. You can clone a new OBJ and continue to modify the events bound to it, and you can see the changes more clearly. In C3, you will filter out the OBJ, you want to change through a number of conditions, and to do so, you only need to directly modify the code bound to the Obj itself.

From my understanding the idea is to create a special eventsheet that you can assign to objects rather than layouts like a behavior and that also work like behaviors.

I like the idea because it could be useful in terms of reusability and is a step towards the "write plugins with events" idea that Ashley hinted at about 2 years ago.

You understand what I'm trying to say. This concept, I think, is a great improvement in efficiency. This repeatability is amazing! And remove [filter] to see the effect more intuitively.

I don't understand what you are suggesting/asking.

What is an "event table" ?

Currently in Construct, that doesn't exist, does it ?

Also "bind [...] to a single object".

Are you talking about picking a single instance ?

Because, that is already in and how events work.

I'll explain. C3 the existing way to select a single obj is filtering. Use variables or different UID to determine which obj to operate on. What I want to say is to bind a series of events or behaviors directly to a particular obj. So you don't have to [filter]. If you say there are a lot of obj, does every obj have to rewrite an event and bind it to them? No, you can clone or copy that obj directly. Because the events are bound to them, the copied or cloned obj also has those events. And if you want to modify something, make something different, just modify the code on them without filtering.

Like behaviors I see it as a mostly self-contained thing that could be used (and especially reused) in a generalized way.

Lets just say you need an object to move in a specific way, for example have it constantly circle around the viewport edges. The eventsheet would allow you to add properties (e.g. speed) that then are exposed in the object properties. Global variables could be exposed in the form of expressions so you can read e.g. how many times the object circled around the viewport.

Further the idea would be that you can´t specify an object inside the event sheet, and the events always automatically reference the instance. This means you can plop it on any object without having to change anything in the code and have it work (including across projects), assuming you don´t access conditions/actions that aren´t available. You can´t "set text to" on a Sprite afterall.

This would also make it easily shareable. Kinda like the plugin database, there could/should be a place to share that kind of eventsheets. Maybe, don´t call it eventsheets just to avoid confusion.

That´s roughly the idea I had in mind, I hope it makes sense.

You fully understand what I'm saying! Thank you. That's what I'm trying to say.

Let me add a few more examples. Maybe you'll see what I'm trying to say.

If you have a NPC character. When the player approaches the NPC, the name of the NPC appears directly above the NPC. You can bind this logical event to that NPC. ).

Then you will consider that each NPC will have a different type. For example, in a store, the task NPC, plot NPC, corresponds to a different event trigger for each type.

At this point you can clone the original NPC and then trigger for different events to modify their respective binding to their own event code.

Of course, it is now possible to do so directly with the event table. Filter out different NPC types through NPC's own variables, such as name, and then execute different behavior codes. Yes, you can do that, and that's the operational logic of C3.

So, in general, whether it is possible to support the use of event tables to create custom behaviors. There are still some differences. For example, in the normal event table, you can indicate that [a collides into b] triggers an event. If the bound obj is a, then the a in the event table does not need to be filtered to bind its own a. Simply put, if an object appears in the event table that the object is a bound object, you can avoid filtering the bound object. You can set his properties directly without filtering. For example, set a. Variable = 55. If there are many as in the scenario, then the a in the change event table is the one that is bound. It will not affect other a.

If you've ever used Unity or gamemaker or godot or cococs2d, you should be able to understand what I'm saying. They don't have a general list of events to drive them. They script each obj. And that script only affects the obj that is bound.

This may be contrary to the concept that C3 drives all obj through an overall event table. But it's not about stopping the concept, it's about letting the two operational logic exist at the same time. I think they'll work well together. This concept is more useful when dealing with larger projects! I admit that the current concept of C3 is great, and you can quickly develop a game prototype or demo, but when the game is bigger, I think the operational concept I have proposed is more appropriate. This concept is used by unity,gamemaker,godot.

Maybe the idea will be buried. May not be understood, because my English expression ability is limited. English is not my mother tongue. What I'm trying to say is that C3 is great, and he put me on the road to game development. I know that your C3 creative team is limited, a few people doing dozens of people's work. But you update quickly and constantly fix bug to provide new features. The great thing is that this community and voting mechanism allow us to come up with new ideas. With regard to the idea of voting, I have looked at some of the opinions that have been rarely adopted recently. I know because you have limited working hours and a lot of ideas are not mature.

Finally, I hope C3 can develop very well. After more and more users enter, it can not only allow amateurs to quickly develop the games they want, but also become a professional tool!