C3 ideas - Event Sheet Manager and Object Event Sheet

0 favourites
  • 8 posts
From the Asset Store
Very simple code without excess options (15 events for server and 11 events for client)
  • Hellow everyone, this an idea for Construct 3.

    the firts idea is "Object Event Sheet"

    its an event sheet but only for objects using their UID.

    the idea is this:

    you right click and object, then you click "object event sheet" and its appear a event sheet that will only affect that object using their UID, so for

    example, if you have a door in a game and you want that door to be activated with a user that its holding a key, instead of having to create and entire

    event sheet for all the doors in your game, you could easily create events for an specific object without having a mess

    The second idea its the "Event sheet manager"

    its a windows separated from Construct that will show you the event sheets you are editing, so you dont have to stop viewing the layout,

    and you can drag the window to another screen.

    thanks for reading!

  • nice ideas, and the object event sheet would help me alot

  • clickteam fusion has the ability to attach event sheets to objects.

    Inside the attached event sheet you can reffer to the object which it attached to. That way you can reuse the same logic on different objects by attaching it to objects with different names.

    The downside is that the logic can not be instanced, so if you change the event sheet, you have to change it on each of the objects that it is attached to.

    The best case for me is the way it is done in Unity3d. There you can attach the same script on different objects. Inside the script you can reffer to the object to which it is attached to. Changing the script affects all objects that it is attached to.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Not to say these aren't good ideas, but for the doors example couldn't you just create a family for all the doors and then just have one event for opening them? That to me sounds like a better solution instead of having to go into the properties of every door and setting it from there.

  • Not to say these aren't good ideas, but for the doors example couldn't you just create a family for all the doors and then just have one event for opening them? That to me sounds like a better solution instead of having to go into the properties of every door and setting it from there.

    hehe well i think didnt explain well the problem, every door used a different key.

  • hehe well i think didnt explain well the problem, every door used a different key.

    Haha, well in that case maybe something where you could reference the event sheet through the object, and it would only show the events related to that object. Maybe that would be the best of both worlds?

    If each object had it's own event sheet I could see debugging being a major pain.

  • I like the idea. It's more object oriented. Stencyl uses this concept as well: you have events (event sheets) for actors (Objects) and for the scenes (= layouts).

  • I've tried to push this for a few years, but have been able to convince Ashley the benefit of self inferred object design. I know that this design would improve good development practices. Reduce terrible performance overhead. Also would remove elements of the SOL system and just plain make development easier. But I just haven't put forth a compelling argument over the function( object ) of the C style programming. Not even C++, but C.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)