chunchun's Forum Posts

  • Or an enemy:

    You bind it to an event table: [mobile] [pathfinding] [attack judgment] [damage judgment] [attack animation] [mobile animation] [defeated equipment drop] or [defeated event trigger].

    Once created, you clone a lot of enemies and they all have these behaviors. They are essentially the same as in the overall event table directly.

    But when you want diversity, you can directly click on the enemies you want to change and modify them. For example, let some have a special pathfinding mode, a special attack mode, or trigger a special event after defeat. Without affecting the other enemies, Obj..

    You may be able to select the enemy obj, I want to change by filtering directly in the overall event list, but when the complexity is too high, the structure can be very messy.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • > 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.

    You asked about the difference between an event table in an event table and an event table bound in a separate obj.

    I will use a practical example to illustrate the difference.

    If there are 10 instance A. Common event: they play music when they are clicked.

    Three of them disappear after being clicked, the other three change the animation after being clicked, and the remaining four change color after being clicked.

    You can do this in the current event list:

    1. Click on instance A and play the music.

    2。. Through different uid or setting its own variables to filter out different instance A.

    3. Then do different operations for the [filtered] InstanceA,

    You can do this when you can bind an event table to a separate obj:

    1. Create a Instance A.

    2。. Bind him to an event and set the click to play music.

    3. Copying or cloning 10 instance A (cloned Instance also has a bound event table, and all clicks will also play music).

    4. Click on the instanceA event list that needs to be changed to modify it, such as disappearing after clicking, or changing the animation, changing the color, and so on.

    There is no need to filter directly to the obj that you want to modify directly by clicking on the event table under their obj, affecting only the bound obj. The event table under the obj itself should be valid only for itself.

    You might say that this will be modified many times, that each obj that needs to be modified will be modified, and that the total event table can be filtered once.

    However, you can just modify what needs to be modified and then clone it. It should be that the event table that is bound is also brought with you after the clone.

    Or you can do the common events with a common event table. And the different events can be added to a separate obj..

  • 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!

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • What do you think?

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

  • The browser is currently restricted in it's ability to open external editors for files, although the experimental local folder projects might work around.

    I generally advise that you basically just have function calls in event sheet scripts, then have the actual functions in script files. Makes it easier to work with.

    The text editor we use does have an automatic indentation option, but it's currently turned off as it incorrectly indents curly braces if you follow the brace on newline style. We could make this configurable, but it would likely be off by default.

    I don't know if you've noticed gdevelop built-in JS script editor in the timesheet. I think it's great. Although the experience of gdevelop is not as good as that of C3, I think its built-in script editor can be used for reference.

  • Or improve the function of the IDE. The JS block in the event table cannot be shrunk normally and lacks automatic indentation.

  • You can try adding Persist behavior to all objects on the layout.

    Or you can save everything in an array when leaving layout, and restore all object from the array when entering it again.

    Thank you for your answer!