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

Post reply
0 favourites
From the Asset Store
100 items casual and logic games
$6 USD
100 items casual and logic games. All icons are of a high quality.
cruizRF's avatar
cruizRF

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

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

  • I still don't see much use in any of these examples.

    Take an event like this:

    + On Player collides with Powerup

    -> Destroy Powerup

    -> Add 1 to Player score

    Suppose you somehow bind that to the Player object. How does it run then? As far as I can tell - exactly the same. So there doesn't seem to be any purpose to it. In other words, the way Construct picks instances already does everything necessary.

    If you want to create different sets of events per instance, then I can see major downsides to that. Firstly it would have a high performance cost: Construct would have to re-run entire sets of events for individual instances, rather than picking sets of matching instances like normal events. It would be in the ballpark of having a 100x performance overhead if you have 100 instances, similar to moving an entire event sheet under a "for each instance" loop which needlessly re-ran everything repeatedly per-instance. Secondly it would seem to have a significant maintainability cost - you can no longer just look at an event sheet and know what will happen, now you have to sift through individual instances and review their logic independently; if you see an instance misbehaving, now you have to figure out which instance that is exactly, identify its corresponding set of events, and debug those individually. I have to say, that sounds like a nightmare! And thirdly, it's limited: which events run for dynamically created instances? There doesn't seem to be a good way to set that (and then imagine debugging that).

    The current design of centralised event sheets shared across the whole project is deliberate: it's good for performance and maintainability. I'm not convinced anything much in this area would actually make anyone's life better. At best, maybe you could attach an event sheet to an object so it goes with it when you copy/paste it, but in all other regards it would work identically to event sheets now - but that seems to be something different to what people are talking about here. Still, I'm open to reconsidering if someone can clearly and concisely describe a really great example that explains why this is valuable and avoids all the potential downsides, but I remain sceptical.

  • (please ignore)

  • Test test test

  • Test test test 2

  • Test test test 3

  • Test test test 4

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Test test test 5

  • (please ignore)

  • (please ignore)

  • Test test test 8

  • Test test test 8

  • There's a weird forum bug going on here which stopped my reply appearing until I added several other replies... and deleting them makes it disappear again :P So apologies for the spam and please ignore the intervening posts...

  • What about how I described it earlier though? I also don´t like the idea of adjusting events on a per-instance basis. I pretty much want it to be exactly like a behavior, except via events.

    Also I just noticed my earlier post ceased to exist :V luckily chunchun quoted it so here it is again:

    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.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)