Today’s objective is very specific and in a way it’s wrapping up the current phase.
First I need to make it so the Settings button doubles as a Return button when inside a menu.
Then, I need to make some placeholder appear when a menu is deployed. Sounds kinda short as a list but you never know with coding.
First we need to code the part that tells the game to go back to its default state, AKA the state that the menu will go back into. We’ll call it “state 0” because it’s 0 in the switch statement controlling that.
Those that can visually parse what’s going on the code will see the first issue we have at hand: It needs to discern if it was on a positive or negative position. This is because the menu us set so its anchor point is dead in the middle of the window.
Man, I’m so glad I’m not doing something low resolution, otherwise that middle point would’ve driven me insane… though I guess I would’ve put the anchor on the top left corner in that case.
The other problem is that because the window has different width and height, it only stops when one of the axis reaches the point so the return trip could be a tad messier math-wise.
Hm…
Okay so hear me out…
We need to standardize the amount that the UI moves. Define a specific unit that it will move towards and then return from.
First let’s establish the resolution here in case that ever changes.
Next, let’s find a number that both can be cleanly divided by.
And then let’s save that unit into a variable that we’ll use for the movement.
So let’s do some math.
The window is 1280×1080, each menu moves it 600 pixels in the x axis because it’s in the center so it moves until roughly the 80 pixel mark.
With the standardized unit approach, each unit is 150 and 125 for width and height respectively. so if we tell it to move 4 units in the x axis it will reach that same mark.
And with the approach the code had before (that you see in the first image), if we divide 600/50, we see that the code took 12 steps to get to that mark, this mark also leaves the y axis at 40×12 or the 480 mark.
With the standardized approach, we’d need 4 steps to get to the 600 pixel mark, which would also leave the slightly shorter y axis at the 500 pixel mark. However, since the borders are also real estate that will be used, let’s see how it looks by moving 3 steps instead.
Like this.
We divide xstep and ystep by 2 so the movement is more smooth and closer to what we had earlier. I don’t make stepamount 16 because one is already 125 and that divided by 2 is 62.5 and I don’t want rogue .5s in the UI.
So we test and…
Perfect. The button on the corner is just a placeholder so it’ll change, but I like that it almost snugs it perfectly.
Okay, so now we have a standard movement unit, we have to revert it.
But first we need to make the button change whichmenu to 0, and if you’ll remember, that same button already changed to 5 so we gotta add a condition to the signal bit of the code.
Simple enough, if it’s in 0 (the default) pressing it makes it become 5 (settings), otherwise (anything that’s not 0) make it become 0.
We still gotta make the button change color to reflect this state change, but we’ll get there in a moment.
The goal of that chunk of the code is to see if x and y are above or below 0 (reminder, it starts at 0), and then move until it is 0 again.
But first a test.
It resets to 0 directly without movement, but that way we can confirm that the button works as intended.
Now, the code we used here gives us a good starting point, the code is going “as long as x isn’t 0 run this bit and when it’s 0 stop the movement”, so now we just need a chunk that checks if x is above or below 0 and one that checks if y is above or below 0.
Alright so let’s…
Okay what the hell the code should be a simple “undo what you just did”, what’s wrong?
…oh.
Do you see the error?
Here, let me highlight it.
The bit of the code that checks for the y position is still checking for x.
I didn’t even copy and paste the bit right above it PRECISELY out of fear that THIS EXACT TYPO would happen.
So anyway, we fix that and…
Perfect.
Let’s add some placeholder image once the movement ends so we can pinpoint where in the code the routine of showing stuff would go.
The best place to add that would be in the bit of code that’s like “movemenu = false” because that’s not just the part where process stops checking that bit of the code, but it doesn’t run more than once.
Now, instead of cramming whole chunks of code there, what we’re gonna do is make functions for each menu.
Like these.
And then we add them to the code…
Like so.
By the way, if you’ve kept track of all details, you’ll notice I changed Look to the top left, that’s because it’s the one button that doesn’t use the frame so it aligning with the return button in the corner works better.
One perk from Godot is that I can make scenes and instantiate them, scenes are basically “room objects” so what this means is that I can code a whole separate room and overlap it on top of the current scene.
So I make a whole scene, preload it like this…
Instance it like this…
And then we add a line to the function we made earlier, like this…
So we press the Look button and…
Now, this poses the next question on how to remove the menu once you return to the base menu.
Well, that one’s easy. If we save the instance to a variable, we can just tell the code to delete whatever’s stored in that variable.
So we create this…
Then we do this…
THEN on the return button we add the bit of code that deletes things…
And with that…
So let’s quickly add other placeholder scenes, just repeating the same process, and…
Mind you, all of these are scenes with a single image, so moving forwards I can edit that scene and I’m editing that menu function.
Right, so the last loose end for today is making the button change color when it’s in Return mode and I’m just noticing that button doesn’t have the same lock the others have of “if things are moving do nothing” and oh hey if you double click the button everything crashes, what are the chances.
Wait, no. The problem is actually that queue_free deletes things in such a way that if you press the button again it crashes.
Hm…
Oh okay, I needed to use remove_child because otherwise it basically unloads the whole asset. Good to know.
The gif can’t show it, but in the last one I was clicking really fast to see if things would crash again.
Okay so, changing the sprite of the button. The key thing is that it only happens once when pressed… so what if we create a signal that goes towards itself?
First let’s do a quick logic test with a Print statement which I just remembered is something I can do. Oops.
The idea is that if you press it while it’s at 0 it will change to the Return colors (blue) and if you press it while in another menu mode it will go back to settings mode (red)… wait no, it’s the other way.
We test and…
Okay now that we know it works as intended on the logic front, let’s make the colors change.
First we preload all the stuff.
Then we assign it to each state.
And then…
So we’re done, right?
WRONG.
You see, the code is a signal, which means that it only triggers when the red button is pressed.
But there’s an easy fix to that.
First we move all that color-changing code to a function.
Then we connect the Pressed signal from all other buttons.
And we make them trigger the function we just created.
Aaaaaaaand…
Phew.
Alright let’s check the list…
To-do list:
Create a state change where the settings button becomes the return button.Done.Create the “return to start” motion.Done.Make each menu spawn a placeholder.Done.
Alright so starting from the next one, let’s tackle each quadrant individually. We’ll start with Look (top left).
To-do list:
- Instantiate an image of the proper size (or roughly close to it since the menu movement and its outline aren’t final yet).
- Instantiate clickable elements within said image.
- Instantiate elements according to flags and variables.
- Instantiate different images altogether depending on other flags like where the player is and when.
Lots of progress! Let’s celebrate with one more character teaser!
The Detective
Nobody knows his name, but everybody knows you can trust him. If you’re haunted by trouble that nobody seems to be able to solve, you’ll find his door in the place you least expect…
Nashira’s comment:
“As hinted in my comment on Yuri’s appearance, our dear detective’s image color is purple! Inspired by the Joker half of CycloneJoker.
Hm, what’s that? you’re curious about the pointed ears, pointed fangs, and suit jacket worn in the style of a cape? Unfortunate, I’m going to point to his upsettingly expensive periwinkle eyeliner and his (empty) ear piercings as his charm points instead. A purple haired character is one of my favorite flavors of character, so I wanted to make sure he looked pretty!”
Proud of today’s progress. Let’s keep it going.