my mockup and ideas for Scene Graph

Post reply
0 favourites
From the Asset Store
Retro Game
$49 USD
Music Loops will turn your old school 80’s vintage production or idea to life!
Epic Stock Media's avatar
Epic Stock Media

  • imgur.com/cdJkTYV

    i.imgur.com/cdJkTYV.png

    This is my mock up for a scene graph system for Construct 3!

    A Scene is a new Object Type, that when double-clicked opens up a new kind of page - "Scene view", which shares the design language of the Construct animation editor / Layouts. Object Types on the Project view simply display as any object, and can be treated as an object similar to a sprite in Events.

    Once opened, a hierarchy window is available that allows you to sort the hierarchy (Parent and children) of objects dragged into the Scene view. Object children, when moved in editor (and with Events in runtime) conform to their parent's movements and rotations, as well as other events like Destroy.

    If an object is created either through events or editor as Scene 1 object

    -It should contain the parent/child associations, and so in runtime, if for example "Torso" is being manipulated, it's children should also follow suit.

    If an object is created through events or editor as Torso object

    -It does not contain any parent/child associations and so if it is manipulated, it is simple an ordinary sprite.

    It should still be possible to spawn objects of for example 'Torso' as an individual object, without spawning the rest of it's children within a Scene as long as the object that is being spawned is Torso and not "Scene 1".

    There should be a way to pick objects by parents and children for individual control of parts.

    Being able to Nest Scenes would be amazing, but I can imagine that being a lot of work.

    There is a show image point option in the Editor properties to toggle showing all origin point and image points to better align composite sprites.

    There is a Z order window in my mock up. But I am not sure if it is needed with a hierarchy. It could still be useful to be able to control whether a child is above or below it's parent.

    It would be very useful if we could composite different object types, mainly Sprites, 9-Patch, Particles, Text, Sprite Font, Tiled Backgrounds, Tilemaps (not really that important).

    Just my ideas, but hoping the team takes some of these ideas!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks for making this, it's interesting to get a better idea of how people imagine the scene graph working.

    I like the approach of having a hierarchy bar that shows all the connections as a tree.

    At the moment the proposed way of treating "scenes" like "object types" is awkward to fit in to Construct's current architecture. An object type is something that directly has instances, variables, behaviors, picking capability in events etc. itself, and scenes don't seem to be quite the same kind of thing as that, so I think it would be better to approach that differently. Perhaps there could be a separate view that shows all objects at the root of a graph, which is what a "scene" appears to basically be.

    The scene editor also seems to duplicate a lot of what the Layout View does - it seems to make sense to me to just do all that in the Layout View directly.

  • Im wondering if having scenegraphs work just like a layout would be a good way to go.

    I mean since we no longer have to have objects in the layout they will be used in, and a lot of people use asset layouts anyways.

    I dunno maybe.

    Sub-layouts?

  • Some of my assumptions about the use of scene graphs - if you perform actions on a parent node, the children should be effected relative to the scene graph tree. For example rotation, offset, scaling, z-order, etc. should be well behaved to keep the scene graph consistent.

    In Rory's example, during runtime, I would expect to be able to rotate the elf by rotating the parent (torso) and the components (leg, arms, head) would rotate with respect to the parent so the 'elf' would stay connected (e.g. the children would not just rotate in place.) I think this may be 'obvious', but good to state. Similar for scaling the parent.

    Right now it seems like the relationship between child and parent will be mostly x,y offset, is that correct? Are there other relationships possible (without going too crazy and trying to recreate Spriter / Spine style animation.)

    This post is interesting to check out, a relationship they explore is rotation around a parent.

    archive.gamedev.net/archive/reference/programming/features/scenegraph/index.html

  • It would be very useful if we could composite different object types, mainly Sprites, 9-Patch, Particles, Text, Sprite Font, Tiled Backgrounds, Tilemaps (not really that important).

    I think this would actually be pretty important, so this way we could use the scene graph to create systems like menus, dialogs, huds, etc... wich are usually composed of diferent objects types.

    The scene editor also seems to duplicate a lot of what the Layout View does - it seems to make sense to me to just do all that in the Layout View directly.

    I like this, would also be easier for users to get started with the new feature.

  • Some basic version of this already exists in the aekiro's ProUI collection of addons. GameObject behavior allows to combine several objects into a group, where child objects will move/rotate/scale with the parent.

  • Thanks for taking my ideas seriously!

    What I feel would be missing from using Layout View for a scene graph is the event level control of layouts within layouts. For them to be useful to make composite objects, they would need to have some of the behaviors of a layout and some of the behaviors of an object.

    Some basic version of this already exists in the aekiro's ProUI collection of addons. GameObject behavior allows to combine several objects into a group, where child objects will move/rotate/scale with the parent.

    Yes, I'm using that in my game right now, and I worked with Aekiro to help find all the kinks in it early on. It's good, but ultimately it lacks what the C3 SDK doesn't allow him to do.

    I think a good way to see if the official system will be capable is that it does at least everything that Aekiro's plugin does!

  • Thanks for making this, it's interesting to get a better idea of how people imagine the scene graph working.

    I like the approach of having a hierarchy bar that shows all the connections as a tree.

    At the moment the proposed way of treating "scenes" like "object types" is awkward to fit in to Construct's current architecture. An object type is something that directly has instances, variables, behaviors, picking capability in events etc. itself, and scenes don't seem to be quite the same kind of thing as that, so I think it would be better to approach that differently. Perhaps there could be a separate view that shows all objects at the root of a graph, which is what a "scene" appears to basically be.

    The scene editor also seems to duplicate a lot of what the Layout View does - it seems to make sense to me to just do all that in the Layout View directly.

    I want to be able to filter out all the objects under the tree structure through the parent object.

    For example, if A collides with B, let A> A1 > aa change the transparency. Let A > a2 > a_text.text= "dmg"

    I think it is very important to be able to accurately select the required child objects under the parent structure.

    In many games, the enemy's head will have <a blood bar>, and the top of the blood bar is the <text> of the blood bar (100 /100). Then these can be used as children of the enemy. When the player collides with the enemy, it can accurately change the blood bar and text on the enemy's head. (that is, the blood strips and words on the enemy's head can be changed based on the enemy's own variables. For example, hp_text.text=self.parent.hp;). It can select the variables of its parent object.

    This is the example I would like to cite.

    The parent object can easily obtain and change the variables or properties of the child object you want, and the child object can also obtain the attributes and variables of its parent object through self.parent.***.

  • > Thanks for making this, it's interesting to get a better idea of how people imagine the scene graph working.

    >

    > I like the approach of having a hierarchy bar that shows all the connections as a tree.

    >

    > At the moment the proposed way of treating "scenes" like "object types" is awkward to fit in to Construct's current architecture. An object type is something that directly has instances, variables, behaviors, picking capability in events etc. itself, and scenes don't seem to be quite the same kind of thing as that, so I think it would be better to approach that differently. Perhaps there could be a separate view that shows all objects at the root of a graph, which is what a "scene" appears to basically be.

    >

    > The scene editor also seems to duplicate a lot of what the Layout View does - it seems to make sense to me to just do all that in the Layout View directly.

    I want to be able to filter out all the objects under the tree structure through the parent object.

    For example, if A collides with B, let A> A1 > aa change the transparency. Let A > a2 > a_text.text= "dmg"

    I think it is very important to be able to accurately select the required child objects under the parent structure.

    In many games, the enemy's head will have <a blood bar>, and the top of the blood bar is the <text> of the blood bar (100 /100). Then these can be used as children of the enemy. When the player collides with the enemy, it can accurately change the blood bar and text on the enemy's head. (that is, the blood strips and words on the enemy's head can be changed based on the enemy's own variables. For example, hp_text.text=self.parent.hp;). It can select the variables of its parent object.

    This is the example I would like to cite.

    The parent object can easily obtain and change the variables or properties of the child object you want, and the child object can also obtain the attributes and variables of its parent object through self.parent.***.

    To put it simply, through child objects or parent objects, you can easily filter out any objects based on the tree and manipulate them.

  • My advice is to check out how Prefabs work in Unity.

    I believe that's pretty much what we all want from this scene graph feature.

  • My advice is to check out how Prefabs work in Unity.

    I believe that's pretty much what we all want from this scene graph feature.

    I agree with this view. The Prefabsof UNITY and the NODE of godot are good references.

  • Im wondering if having scenegraphs work just like a layout would be a good way to go.

    I mean since we no longer have to have objects in the layout they will be used in, and a lot of people use asset layouts anyways.

    I dunno maybe.

    Sub-layouts?

    One suggestion if you do use a layout for this Ashley

    Make sure that if you go to that layout just to edit something it doesn't run that layout...

    Using an empty layout for assets like this gets freakishly annoying as you have to go back to the layout you want to preview.

    Then if you do make the mistake of running to asset layout you have to wait a few seconds after closing it as the editor doesn't respond very well to quickly starting another preview.

  • Make sure that if you go to that layout just to edit something it doesn't run that layout...

    By this logic, when you switch to a layout you do want to preview, it won't run that layout either.

  • > Make sure that if you go to that layout just to edit something it doesn't run that layout...

    By this logic, when you switch to a layout you do want to preview, it won't run that layout either.

    I think when you click on the object-based layer, you can also run it separately to preview the current object-based layer. No connection with other layers and game scenes

  • I think when you click on the object-based layer, you can also run it separately to preview the current object-based layer. No connection with other layers and game scenes

    Layer, or layout? I don't see where you would want to preview every scene graph on that layout.

    There should be an option to run an individual scene graphs animation like we can view objects animations in the editor.

    Then an option/checkbox to not run an asset object layer sounds like it would solve everything.

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