[SUGGESTION]Event sheet for objects

In large projects I find it difficult to separate the logic enough and often end up with lots of events triggered by different objects, sprites and states. When the flow is non-linear it gets almost impossible to keep track of what you are doing.

I am an experienced programmer and I miss the possibility to use design patterns for my projects, but at the same time I really like the simplicity of using event sheets. I would suggest the possibility to add an event sheet to a sprite, where the sprite could itself control it's behaviors, much like in flash. It would also need to be able to send events to the layout and maybe other sprites as well and it needs to be able to expose methods for the master sheet to be able to call.

I understand that this might be hard to implement but have you anything like this in the pipe? Or is there a plugin that facilitates this kind of functionality?

Thank you!

I'm not sure I understand, but this is what I do.

I like oop. So what I do is have my master event sheet and include each component (their own event sheets).

I usually have groups that can activate/deactivate different components (include event sheets).

I structure my project by creating folders and subfolders which store individual components and merely include those where needed.

I also use "Functions" to reduce repetitive code.

And families

And bookmarks and search - these tools help keep you ontop of the a project with 1000's events.

Makes bug sniffing easier too lol. Cause it is structured you just browse to Folder/subfolder/eventsheet. you choose your own names for folders, eventsheets.

I'm not sure how associating event sheets to objects would work, especially since objects don't have to be in every layout.

Then there's the order, how would that work since events must run logically in order?

We already have a few decent tools, such as bookmarks, groups, and comments. Also, functions are nice, but they can get a bit annoying since you can place them almost anywhere.

We have 10 000+ events(no joke) and it is still easy to manage.

For every Layout we have 1 eventsheet (14 actually) and for every bigger functions(like viewpoint functions or often used family/image management) another event sheet which gets included every time we need it.

The eventsheets are grouped up by objects/functions.

Eg. The player or the top bar is a big part so we create an group named "player" includes the groups "functions", "control or handling", "effects" and so on and every group includes more specific groups like "Creation" or "Attack".

This makes it for us quite easy to manage and every team member can easily find what he searches ;)

I always thought being able to add sheets to individual objects would just make it worse. Instead of going through a simple event sheet list you now have to remember which object you put those events in. It could make all your events even more scattered and unclear. Do you really think it would genuinely help?

I think groups, including event sheets, functions and folders are enough. Not sure if I understand it, but wouldn't include already enable stuff like this with a single event?

I always thought being able to add sheets to individual objects would just make it worse. Instead of going through a simple event sheet list you now have to remember which object you put those events in. It could make all your events even more scattered and unclear. Do you really think it would genuinely help?

This could be of tremendous help for making widgets, especially if we could attach events to groups.

It would be a dream for managing windows and UI as well.

You can add a tiny 16x16 icon to the object to highlight the fact it has an event sheet associated with it.

Aditionally, we could have hooks for functions: a private function is only available in the scope it was declared, but a public function can be called from outside the object, so an "enemy" object could have its own custom "chase the player" function. This relies mostly on features already implemented, and has the added benefit of keeping concerns separate.

This would be wonderful!

We have vague plans for broader modularity features in the long-term, but they'd go a lot further than just an event sheet hidden away behind an object. So maybe we'll address this eventually anyway.

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.

I have not been working with multiple sheets per layout and I will try this approach to see if it makes it somewhat what I look for. nice to read that you have exciting plans for the future, keep up the good work!

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.

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.

+1

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.

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.

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.

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.

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 :)