I am currently trying to create a so-called skill tree in the menu scene.
However, since camera controls are not active in the menu scene,
I am having trouble because the camera does not move when I try to create a wide tree that extends beyond the camera’s view.
Is it necessary to create the skill tree in the game scene and then transition to it from the main scene, given the current situation?
I also considered moving the objects in the menu scene to simulate camera movement, but I have put that idea on hold as it seems like it would be quite labor-intensive.
How is the skill tree built, and what is the kind of movement you are looking for (shifting the tree or shifting the camera)?
AGM is built on the assumption that menu scenes are fixed to the screen size and devs would use scrolling, tabs, or other sub divisions to manage an inventory or game settings.
The inability to pan the screen within menu scenes is indeed a current limitation of AGM.
Previously, I worked on a large map where I constructed several small buildings and opened them to upgrade various modules.
In menu scenes with fixed camera views that do not allow screen panning, I simply used direct pop-up menu scenes.
However, I created a dedicated chat scene that required screen panning to build depth of field. To achieve this, I launched a new game scene, which allowed me to implement the functionality.
The only thing to keep in mind is that switching scenes resets various internal variables, so special attention must be paid to the transition between scenes.
My recommendation is that for features that exceed standard dimensions and require camera movement, you should create a new game scene to implement them.
As a note, various internal variables are reset when switching scenes, so special care is needed when transitioning between scenes.
Thank you. I will store the variables as project-level variables.
One thing worth trying before you commit to a separate scene: moving the tree does not mean moving the objects one by one, which is the part that made you shelve it.
Keep every node at its fixed tree coordinate and hold a single scroll offset. At draw time you draw each node at its coordinate plus that offset, and you skip any node whose result falls outside the visible rectangle. Panning is then one variable changing, not per object work, and the skip is what keeps a big tree cheap to draw.
It also sidesteps what serbow flagged, because you never leave the menu scene, so nothing gets reset on a transition.
The separate game scene is still the better answer if you want real camera easing, parallax, or anything with depth to it. For a flat tree that only needs to pan, the offset is usually less trouble than the scene swap.
I haven’t built this in AGM specifically, so treat the exact API as unverified. The pattern itself is the ordinary one for a scrolling panel and it survives most engines.
