[SUGGESTION]Event sheet for objects

Discussion and feedback on Construct 2

Post » Mon Nov 04, 2013 3:01 pm

I really like the idea of objects having their own event sheets, or someplace where I can define object specific functionality that would be bound to a specific object. Regardless of what layout I use that object on, the event "code" always goes along with it. Being a professional developer, who works in OOPs all day, every day the concept of binding object specific functionality to that specific object appeals to me.

I also like the concept that each instance of an object would have it's own codebase as well so if I wished to tweak just one instance, I would be able to without any impact on the other instances.

Many people attemtp to simulate this by defining an external event sheet with the object specific code, then just including it in the main level's event sheet, which is close but still not quite the same as binding them to the objects themselves.
B
14
S
6
G
1
Posts: 143
Reputation: 1,795

Post » Mon Nov 04, 2013 9:05 pm

[QUOTE=jeansson] Thanks for your tips and thoughts. To clarify, what I want to be able to do is to create custom behaviors for sprites the same way that I now create events in the event sheet. For me it would be far more OOP to place the logic on the sprite instead of mixing it with the general flow of the game. We should of course also have introspection on the public methods and parameters (code hinting) and the possibility to open the declaration (or event sheet) for the object from out master event sheet (like pressing F3 in eclipse).

This is somewhat possible now by coding custom behaviors in javascript but it would be really nice to be able to use the fast workflow in the event sheets.

[/QUOTE]

+1
Win7 64- i7 [email protected], p6t Deluxe v1, 48gb, ATI 7970 3gb, EVGA 590 3GB, Revodrive X2 240gb, e-mu 1820. Screens: 2 x Samsung s27a850ds 2560x1440, HP 1920x1200 in portrait mode
B
30
S
10
G
8
Posts: 170
Reputation: 7,074

Post » Tue Nov 05, 2013 7:28 pm

Yep. I remember making this request a while ago. I would like to see this. BUT lately

I would rather see Modularity be locked into making GROUPS more advanced.
Groups can have Objects like Arrays, Sprites..... which don't appear in the Obect list. Just in the Group on the Event Sheet. I would also like Function baked into the Group. As well as expressions to make variables in a Group open or private.

Then I would love to see it all get wrapped up into a non viewable plugin. Which can be updated by Drag and Drop into other peoples projects.

So if someone used an advanve gamepad tool made by someone. They can drag and drop and now the group is in the project. With Functions and Expressions accessible as it were an Object itself.

Then if the tool was updated the other person can drag and drop to update.

This I think would work well for both OOP design and modularity.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Fri Nov 08, 2013 6:27 pm

[QUOTE=jayderyu] Yep. I remember making this request a while ago. I would like to see this. BUT lately

I would rather see Modularity be locked into making GROUPS more advanced.
Groups can have Objects like Arrays, Sprites..... which don't appear in the Obect list. Just in the Group on the Event Sheet. I would also like Function baked into the Group. As well as expressions to make variables in a Group open or private.

Then I would love to see it all get wrapped up into a non viewable plugin. Which can be updated by Drag and Drop into other peoples projects.

So if someone used an advanve gamepad tool made by someone. They can drag and drop and now the group is in the project. With Functions and Expressions accessible as it were an Object itself.

Then if the tool was updated the other person can drag and drop to update.

This I think would work well for both OOP design and modularity.[/QUOTE]

Yep this is exactly what I had in mind all along, that I can share 'object groups' between my different projects. It will allow reusable objects and make my workflow much faster. I am currently already creating a separate event sheet and layer/group for each important widget in my project just for the sake of clarity and ease of debugging.

+1 to this idea.
B
10
S
3
G
1
Posts: 11
Reputation: 1,554

Post » Sun Nov 17, 2013 7:35 am

This is a tough one. We need to have in mind that the target audience is non-programmers. As a long-time OOP developer, attaching events sheets to objects makes sense to me.

MIT's Scratch is an example of an tool targeted to non-programmer in which each sprite has its own collection of scripts. However, there are limitations as sprites cannot invoke other sprite's methods. The following statement in C2 takes non-trivial work to replicate in Scratch:

If bullet collides with ghost then
...ghost destroy
...bullet destroy
...add 1 to score

In Scratch there are two ways of going about this:
1. Both, ghost and bullet check for collision with each other and decide to destroy themselves. One of them, though, has to be responsible for updating the score. The problem here is that this approach creates a race condition. One of the sprites will determine the collision first and destroy itself; when the turn comes for the other sprite's script to execute, no collision is detected.
2. The other approach is to have one sprite to coordinate all the actions and send "signals" to the other sprite telling it what to do.
This works, but the "simplicity" seems to be gone.

If in C2 each sprite is going to have its own event sheet, then either the bullet or the ghost will handle the collision; but which one? Either way, it would not be easy to "reuse" either sprite in other projects as they depend on the presence of the other object for their sprite sheets to work. This problem will always be there with Object-based languages, as opposed to Object-Oriented languages.

For real reuse, you either move to an OOP approach, or introduce the notion of "slots" for the scripts (a kind of "generic" programming) which are instantiated at runtime. This way, you can take your sprite to another project and provide the appropriate sprites instances for those "slots". Also, you would want to have something similar to inheritance so you can really create classes of reusable widgets and sprites. Either way, we loose simplicity.

I like the idea of strengthening groups as middle-ground compromise.
B
14
S
3
G
5
Posts: 5
Reputation: 3,809

Post » Sun Nov 17, 2013 8:45 am

After this post I made a thread on the subject "A call for Modularity" Ashley made a reply. Double edges of course :D

The ideas are in the works, however since this would require doing a structural change to C2 egnine; this is not in the near future :( I'm glad it's on the to do list, but this will be a while. It's sad because to me I feel the lack of easy modularity is the last bit holding C2 back from reaching the last hurdle to move from "toy" making tool and move onto playing with the big boys.

it's likely Multiplayer will be approached first(not that I'm happy about the approach), but i feel the modularity in place now would benefit everyone. oh well. It will come it's just patience now :)
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Sun Nov 17, 2013 10:51 am

Wouldn't it end up looking exactly the same as what we have now? I mean for convenience the objects event sheet would probably be in the project list with the other event sheets. And included in the primary event sheet.
Just like any included event sheet.
So the only thing this request actually does is add a hot link to an object that opens the event sheet? Paradox2013-11-17 10:53:00
B
233
S
62
G
33
Posts: 902
Reputation: 40,398

Post » Sun Nov 17, 2013 12:29 pm

I really dig the idea of being able to copy an object along with its individual actions to another project. That's awesome, you could code a whole sort of a game engine and reuse it.

On the other hand I don't think it could make the code even harder to follow. While I liked coding in Flash it sometimes almost drove me crazy when I forgot where did I put a piece of code that was doing something and had to go around opening various MovieClips and frames muttering 'here? no. maybe here? nope. HERE? no. sh***tttt".

So I don't know about this.

ps.
@Darklinki 10 000 events??? wow.
B
16
S
7
G
1
Posts: 161
Reputation: 3,131

Post » Wed Nov 20, 2013 6:20 am

@pirx yeah Its a simulation game, If the progress go on like atm we will publish it in 6-12 months.
B
15
S
6
G
6
Posts: 512
Reputation: 5,555

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 9 guests