sub scenes/child scenes

GDevelop general Feature requests
1

As you may know, I’m working on my little space sandbox game with the possibility to move between interiors and exteriors by using external layouts and layers. Finally I come to the conclusion, it not going to work this way. To make such game I would need a feature called sub scene or child scene, call it however you like. You can see similar feature in RPG Maker. The point of this feature is that, we can create sub scenes for every scene and the main scene would share all it settings, and variables with it sub scenes but not the actual objects, objects are kept completely separated between main scene and it sub scenes. This way we can use sub scenes to create interiors and move between interiors in the game world and make changes in interiors (kill an npc, place an object, pick up an object, mission…etc) without actually restart a scene and use global variables to share information what just happened and where.

“Scenes” are not ideal for such thing because scenes are restarting every time when it loaded and need to use global variables to share information between them.

I hope you get the idea, please think about it.
Thanks.

2

Can’t you just simulate it using external layouts and external events? E.g. if variable subscene=2, load external events sub2, destroy all objects, load external layout sub2.

3

Indeed, external layouts are made to solve this kind of issues. In a large game, scenes should just be used to create the game engine and external layout are used for level design.
Don’t forget to use a group to differentiate between interior/exterior objects, so that you can hide/show/delete them in a single event :slight_smile: Using external layout this way also allow to keep objects alive like the interface/HUD and things like menus.

Or maybe the real solution would be the ability to pause a scene and go to another then go back to the first one without resetting everything. This would be really interesting !

4

Honestly? I prefer doing game design the other way around: Engine in external events and level in scene editor. Because of that if one scene needs to have slightly different events, it is easier to do. I’m using external layouts for two things: Either huds, etc. or multi-object props that would be too hard to set up in scene.

5

I didn’t say that engine shouldn’t be in external events, on the contrary it is made for. :slight_smile: The same for external layout, they are made to be used for either for a whole scene or just for a part of a level or a HUD.

But in both case, what I said is still true: the scene is a central point that should contains only a few things, and the most important things should be in external events/layout.

But we’re getting a bit out of the topic: In all cases, I’m not convinced with this sub scenes thing. :slight_smile:

6

Actually external layouts causing my problem as once the content is loaded, it remain in the scene forever only can be hidden :imp:
And even if it hidden you still interacting with it objects. For example, even if you hide the layer with the layout that has walls, you still colliding with the walls. And I’m talking about multiple layouts loaded and present in the scene not only 1 and to do way more complex interactions than colliding with walls.

I’m already using tons of them also object variables to identify which objects belongs to which layout and layer and make things work but the list just getting bigger and bigger it juts getting way too complex now :imp:

It funny as you probably have more experience then me, but i have to disagree. Layers are useful to hide/show things, that’s it. Layouts are useful to load complex parts for the scene, not only few object but multiple objects in a predesigned way/order using a single event.
But what I’m talking about is not few objects I’m talking about complete scenes, custom interactions on each. To store and load such scenes, honestly layouts are simply useless and to use groups and object variables in such scale are really painful.

Let see an example of how sub scene could help you out.

Imagine GTA.
See the city, vehicles, civilians in front of you.
Now imagine that you go inside a house and the house have multiple rooms, maybe even upper level.
Now imagine that you turn a light on in a room and go back to the street but you see an accident.
Now you go back to the house and the light is still on because you left the light on.
Now you go back to the street, and the ambulance just arrived to the accident and the cars are still there, bodies are still there, and crashed cars are still crashed, dead civilians are still dead.
To achieve this, would you use groups, object, global, scene and child variables for every single interior, every single vehicle, every single house every single civilian, for every single light on every single layout on different layers for each or simply the street and all vehicles and civilians would be on the main scene and the house interiors with it lights and rooms would be on sub scenes and you can simply move back and forth between them using a single event?
Are you still not convinced about that sub scenes can be useful?
Now imagine this 100 different locations in the same city in different houses with different lights in different rooms of the houses, with different vehicles and civilians on the street and wherever you go you just want to see how things really are! :angry:

Not exactly, what I really want is to be able to change “scene”, location in the game world in “real-time” but to not reset scene every time when it loaded, would be a good start.

Maybe from your (engine developer) point of view, it makes no different. It can be really difficult and complicated to add such thing, but from my (game developer) point of view, sub scenes would make my life a lot easier to make such game,
Basically sub scene would be similar to layouts and layers, but the whole point is, objects are kept separated. I don’t want to hit the wall on the main scene when I’m on sub scene 2 and I don’t want to get killed by enemy on sub scene 3 when I’m on the main scene, and If I kill an enemy on sub scene I want it to be dead even when I go back later but don’t be dead other places if not killed. Simple as that. Using groups, variables, layouts and layers just really painful in such scale in such game. Yes possible , but it is just brutal to identify every single object on every single layer and layout to know, which object belongs to which layout and layer and when the player is in the same location as such an such object of such and such layout on such and such layer, and what action is used where. Just crazy, sub scenes would make it a lot easier to achieve such thing.

1 Like
7

I think you’re asking too much from GD.
For that kind of persistant sandboxed openworld, you need a more evolved game engine, such as Unity3D, where you can put objects into objects, and create complex hierarchies of parent-children, while managing them as you wish.

A good game designer isn’t the one who conceives a complex and deep game.
It’s the one who conceives a playable and enjoying game within the constraints of his tools.
Maybe you should revise your ambitions, and build your game design around GD limitations.

As I see it :

  • interiors and exteriors are within their own scene, so the “game” pauses when entering interiors
  • a very limited variety of interiors, so it will be easier to manage their variables, with lots of interactions
  • exteriors with limited interactions, so they can be built fast and easily managed

Example : Out There, totally feasible in GD while offering an illusion of openworld

8

I don’t think that it too much as GD already has this features. Basically what I’m asking for is
external layout with the possibility to show/hide layout similar to layers and to have it own events and objects similar to scenes.
But I can even deal with that if I have to use separated layer for each layout to be bale to hide it, the most important part would be that to keep objects and events separated between scene and other layouts. I mean not to create the same object multiple times in object editor for each layout or something, what I really mean, when we add an object to a layout from scene object editor, that object inside the layout should become a “local” object of the layout and should belong to the layout, and when the layout is hidden the objects belongs to the layout must be inactive, when the layout is visible, the object belongs to the layout must be active and every layout should be able to have it own events in case we wish to add something that affecting gameplay only when specified layout is visible. Similar to objects, when layout is visible layout events are running, when it invisible, layout events are not running but layout can still be affected by scene events even when it hidden.

True, but after all the purpose of this topic (feature request) is to suggest features that helps to reduce it limitations :laughing:
But yes agree, If I can’t convince 4ian, I need to revise the whole thing and make a stripped down version of the game which is not necessarily a bad thing, maybe something good and even better can born this way, but it not something I wanted :cry:

Out There looks pretty interesting but as far as I can see it more like a click and go, click and do type of game. My game would be a bit more action oriented game with more keyboard and mouse interaction and freedom of exploration, but yeah probably I have to think about a more simplified gameplay/gameworld. :frowning:

9

Okay, I was think about my game.
I decided to drop ship interiors and the idea of have a crew on board of ships that we can control similar to FTL. Just makes no sense to keep it only to start to fly ship and dock on stations. We can simply enter/exit ship similar to GTA. And I decided to keep station interiors, but only as a storage place and crafting place. So you can store you ships, weapons, items on station (interiors) and you can dock on stations to use them, to upgrade ships, change fitting or craft new ships, items, but no advanced gameplay take place on these stations. Only a hangar where you can walk around, enter ships, craft things using crafting computer, change fittings of ships and undock to space with any ships.
But as I really want to have gameplay, not only as flying a ship in space but also as walking with character(s) on stations and surface of planets, I decided to use different scenes to have such gameplay such places. Space would be used to travel between such “scenes”. But to make this happen I would really need the feature to be able to pause scene as the main scene would be the space with stations as “storage”, other scenes would be basically only mission places that can be found, discovered and completed as you explore space. So when I load a new scene, this “scene pause” feature can be useful, otherwise I need to store everything of scene of space and it would require awful lot of variables.

Honest question, could you pleas try to implement this “scene pause” feature so I can pause the scene of space when I load a different scene so I don’t have to use global variables to store what ships with what fittings I have on which station and what items in storage and what part of space is already explored and such?
If you would, I can develop my game in mind going to use such feature but if you won’t, I don’t try to convince you or anything but I just start to use variables and external files to store actual state of space and will see if I can get any further that way. Honestly, just say Yes you going to try or Not at the moment because you have no time.

Thanks. :wink:

10

That’s quite a big change to the way the scenes are managed (and, shall we keep the textures in the RAM or delete them when changing scene without destroying the other ?).

11

I think we can safely keep them in RAM. With today amounts of it, it won’t be a problem. Textures should be only unloaded when scene is unloaded (i.e. changed w/out pausing).

12

So, there is the risk to keep too much things in the RAM…

13

No, I don’t think it is. Even computer with 2GB of RAM could handle such thing and now computers have 8GB of ram on average.

14

Ram is not the problem, if the scene is still alive in memory it will obligatory use some ram space but it’s cheap.
The real question of victor was should we keep textures loaded (in the VRAM) or unloaded them when going to another scene.

The answer is: the most simple way of (properly) implementing this multiple scene feature is too have, instead of having a unique “RuntimeScene” alive, an array of “paused” scenes. As “RenderAndStep” won’t be called on these paused scenes, nothing will “move” and events won’t launched.
So this implies that, as objects will stay alive, the reference to the textures will also be alive and so (as textures loading is done using smart pointers) textures will be kept in VRAM.

At least one action should be added for the GD user: an action to go to a scene without stopping the current one (i.e, the current one is added to the list of paused scenes). (The action already existing will still be there and won’t change).

15

I see this more like a stack with three actions :

  • Add a scene on top of the others (the previous one is paused)
  • Remove the current scene from the stack (stop it and forget everything about it) and play the previous (or the first of the scene if there are no more scenes in the stack)
  • Clear the stack and open a scene (which is “Go to scene”)
16

I see that no new action would be needed. We can add yes/no option (seriously though, it should be represented by checkbox, current way is a bit confusing) to change scene action labeled “Pause current scene” (defaulting to no as to not break current events using this command). This way we could implement this without adding another action and destroying backward compatibility.

17

Victor, I thought about it, but the stack implies that the user is able to open the same scene multiple time… Technically it can be done in the same way, maybe the stack is just a bit more difficult to understand compared to a model where the user has just a single action to change the scene without quitting the actual one.
The stack is useful to make a pause menu (because it allows to go back to the previous scene). It is useful to reuse the same scene multiple time. It is a bit more complicated to understand, but it should be ok. So names of the actions would be:

“Pause this scene and play […]”
“Quit this scene and go back to the previous paused scene”
“Quit this scene and go to […]”

Edit: in any case, backward compatibility must not be broken. :slight_smile:

18

I was think about this as well, and yes you are right, I could store all the sectors, rooms, interiors, exteriors in individual layouts and use scenes only to run events and load layouts. But the problem is, in my game you can move back and forth between layouts so I should be able to save actual state of layout, such as number, position, animation, varible of objects in the layout. I could use variables, and external files to do it, but I just worry about that it just getting too complex after a while as it is now.

So, if you find it difficult to implement “stop scene” feature how about “save state of layout” feature to be able to save state and changes of layout in game, realtime before delete everything from scene and load an other layout?