first of all, I’m new to this engine and am testing a bit in order to understand how Paradox works (I’m also quite new to game development in general, just worked with XNA back when it was still a thing).
I understand that the engine is just being created and doesn’t have full documentation until things are fixed, so I decided to speak to the community.
Now I’ve got a couple of questions regarding the engine.
I’m wondering what a scene exactly is.
My current approach is that i created two scenes, one for the main menu of my game and one for the game itself. Is that the correct way to do this? And how could i change the current scene in my code?
I created a basic screen system so i can change the root of my UI component to the current screen root, but as I’m going to have different scenes and thus different UI components (the scene manager is accessible using my game class), I also don’t know how to get the right component.
When i change the current scene, will the old one be destroyed and completely built again if i swap to it again? And does this apply for the entities, scripts, etc. in that scene, too?
Do I have to use a script for every functionality of my game? E.g. I want to update a UI screen each frame, will I have to create a script that calls this method of my scene manager?
Thanks for your feedback. We have lots of work to do on the documentation side as these questions are highly relevant on how to use the scene system. I will try here to give you some insights:
A Scene is a collection of entities with a particular rendering pipeline setup. As a scene can contain and render child scene, think of a scene as a layer for your game and the main entry point for compositing your game. A scene can contain “2d” or “3d” or “ui” entities all in one: when rendering a scene camera, you can decide to cull some objects from a group (for example, render only 3d with a perspective camera). You can also decide to separate parts of your game into different scenes (as you are suggesting). A scene for the game play of a level, a scene for the overlay UI, a root scene that will coordinate these two scenes. Usually you don’t change the root scene but simply change child scene through an entity having a SceneChildComponent and possibly a Render Child Scene in the scene graphics compositor. For a scene UI, you could choose to let it in-memory for the whole life of the game, and just enable on the SceneChildComponent.Enable directly.
As the design of the API is quite recent, we didn’t have time to test and provide some pragmatic samples that demonstrate this kind of use cases. This will be part of our work on documentation. Also, if you have any feedback with this design, let us know!
Not sure exactly what you mean that the “right component”… but one clue is that you need to decide where you want to coordinate all these things and tie them together. Which scene will coordinate other scenes…etc. Any script running in a scene has access to the entities that it contains, including underlying child scenes.
When a scene is loaded, every assets that is referenced indirectly in the scene will be loaded as part of the scene. Once loaded, a scene in itself doesn’t trigger any other changes (unless it it the main root scene).
Then, if the scene is added as a scene child component of another scene, all the components of this scene will be updated as part of the update process of the child scene. If a child scene is also part of the parent scene graphics compositor, it will be also initialized for rendering. Each of these steps has a cost in terms of initialization/memory…etc. So if you need to have a scene quickly up for rendering, it is better to keep it registered in the parent scene, and enable/disable it whenever you need to.
If you remove a scene as part of a child scene, all update/rendering items allocated will be deallocated. But the scene won’t be unloaded from memory. You can then unload a scene by using Asset.Unload. For each Asset.Load you need to have an associate UnLoad.
It mostly depends how you want to organize your code and scripts. A script is just a piece of code that is called by the engine, so basically, scripts have the same constraints as when you are architecturing regular code. For a particular script, you could decide to stay in a loop and coordinate things from there (for example from a root scene, using await Script.NextFrame) or you can have several micro-scripts that are triggering/reacting to different kind of events. It all depends on how much things are coupled or can be decoupled in your design.
As I said earlier, we will try to update the documentation accordingly to your feedback.
Thanks
thank you for your reply, that really helped me a lot on planning my game structure.
I have got another question, that is if a scene is unloaded will its entities get destroyed and does that also apply for scripts added to those entities? E.g. I added a script to the camera entity of a scene that I load at runtime and when I unload the scene it seems that the scripts destroy method is not called and the script is still running (in Execute() since it’s async). Also the camera entity itself is not being disposed, even if I call a scene.Dispose() after I unloaded the scene. If this is what it’s supposed to do, then what would the proper way to dispose entities, their components (including scripts), and scenes be?
Well, as long as both scenes can run concurrently, and I can lock their updates together. Also, I need to know if transferring objects between scenes is fast, as there will be a lot of that for my use case. Can all loaded scenes share object memory so that I don’t have to reallocate in the case of an object transfer between scenes? This is very important for my performance case.
