Best way to create Slide Menu

Hello! I want to create a menu that slides from the bottom of the page, contains some objects to interact, and when not in use I want to be able to make it slide off the screen.

I can think of several ways to do that, but I’m sure there is one better than another, or that I can’t think of right now.

This panel contains some simple sprites and some buttons to interact.

I want to be able to make everyone appear and easily hide at the same time, without having to move one by one each time. Thank you!

The best way to do it would be to just do it. You might not even like it, but as you work on it you will get better and find ways to improve it further.

1 Like

1 - NEVER have it always in game
Create it when you need it delete it when you don’t

2 - Tweens and considering #1 you will crate it off screen Like for Y it will be CameraBorderBottom()
For objects you slap them to YourMenuObjct.X()+10 or some other value different for each object
Same for Y
Where you create these objects of screen same as you create menu
And now only thing you need to do is tween your Menu UP
And when not needed Tween it back down

3 - After you Tween it down you delete everything

4 - Put all that crap on separate layer for example call it UI or Menu to avoid Z order problems

5 - MAYBE a boolean var will be useful to control when it should open and close

1 Like

Interesting, I didn’t know the CameraBorderBottom() function.

Expression

CameraBorder Left() Right() Top() Bottom()
You have all there you would ever need

Actually i would say check what other expressions are there
You may find them useful

1 Like

Contrary to what @ZeroX4 wrote, I would suggest creating the menu on its own layer in the scene editor so that it’s below the bottom screen.

Then, when you need the menu, tween the menu layer camera down to slide the menu up into view. Likewise, to slide the menu out of view, tween the menu layer camera up.

This is a simple option, and because the buttons are off screen when the menu is hidden, there’s no chance of clicking the interactive items when the menu is not visible.

1 Like

I’ve been wondering about this as I’ll be making a menu soon and was just going to hide and unhide the menu layer rather than delete and create it. If the hidden menu is not on the screen or even if it was (in my case), I thought it wouldn’t use too many resources because it’s not being drawn.

If you use delete and create, the create part would have a few events to get things placed in the right spot each time. Whereas hide and unhide would mean placement is done only once. Is this a reasonable theory or is my thinking wrong?

Menu with sound music UI size sliders and few text objects is nothing

Thing is i do not believe ppl they will stop on that
You see OP hide his ass behind words like “simple sprites”

Where in reality sooner or later such menus will be spammed with objects
Or effects
Or whatever else that will be resource hungry
And most ppl aim for their game to run on potato devices

So even so it may turn to be little harder to position everything with change position action
I prefer to suggest this approach
Cause ALWAYS when you don’t need something it is better to delete it so it is not processed
Rather than have it use up resources all the time
And if you have a lot of such stuff then you will lag your game

If someone really needs like right hand that menu to be made via editor and not via events
Then save/load all objects section here Save / Load your game (Quick + In Depth Tutorial works on all devices including browsers)

I am not saying this is most user freindly cause it require more work for you than just having that menu there all the time

But then when does ppl start to care about lag? When their game starts to lag
How about let’s teach them to do stuff in a way that will not lag their game?
Or at least more performance friendly way

1 Like

Good points, thank you

If you do take the create-when-needed delete-when-not approach, I’d suggest you use an external layout, and not hard code the menu objects’ positions in the events.

2 Likes

Ok now i feel stupid

I knew about external layouts but i used them only once
That is why i suggest doing it via events

Now that you bring it up
It does feel like making more sense over doing it via events

Definitely use tweens

Doesn’t GDevelop automatically cull off-screen sprites?

Not in a way you think

It works exactly as
If i put rock in your pocket
You won’t see it
You cannot say what color it is or shape
But do you feel its weight?

If you check if player is in collision with enemy
Then you are checking it against ALL enemies that are in your scene
And not only ones that are on screen
So you are lagging your game not because you have more enemies
But because you are checking something to each enemy
You should delete stuff that is off screen and create it back that it comes close to screen (viewport) and soon to be in it

That is how you make object culling and that is how you save performance

Why would he test collision between menu items and enemies? Also, spawning a bunch of sprites at once is not exactly a process that’s light on resources

That was example how you are lagging your game
EVEYRTHING in your game that exist in your scene is being processed
What is off screen just not being rendered
But if you are checking if button is pressed
Or changing its position to be off screen
It still is doing it every single frame even when its beyond your viewport

Ppl 1st lag their game then try to optimize it cause they don’t understand what is lagging it

That is why i am suggesting deleting everything that is off screen