It’s been busy today but I want to get… anything done to get back into the pace.
So let’s start with the theoreticals and we’ll see how far we go. I might finish a whole task, I might stop at the practical part.
As a refresher, we have four menus to finish, of these four we’ll be starting with the one that’s an exception. It is an exception because it’s the only non-procedural one of the bunch. What does “procedural” mean? In this context it means the one where the content has to be hand-crafted instead of it being generated automatically.
…the picture might not be entirely clear, allow me to elaborate.
There’s five menus we have to finish. Out of those, four of them will use the same buttons but with different configurations and functions. These buttons can (and should) exist in a list and then a function should basically go “grab these objects and make them show up at these intervals to create a grid”.
And that’s the “procedure” in question, the fact that aside from the image it uses, I don’t have to code each individual menu and its positions when a loop of some sort can do that for me.
Which leaves us with the last out of those five menus.
Unlike the others, where the same buttons will be repurposed for different functions and said buttons can be consistently set through code, the Look menu is meant to feature an image whose clickable elements aren’t gonna always be the same, and moreover they might change depending on certain in-game conditions.
Let’s create an example.
We start with a backdrop.
Next we add an element that’s out of place.
Now, at this point there’s already something to remember which is that the clickable element being overlayed must be the same size as the background, given that we’re gonna need to create a mask out of it.
Something like this.
So to recap, every Look window will need its background (let’s call it “base”) and the elements over it you can interact with (let’s call them “clickables”). Not every clickable will need to a separate asset, an element in the base can be masked in order to make it interactable.
Before we add it to the game, however, we need to make some adjustments. The first of which is making a “template” of sorts to set the right size for all future Look windows.
First let’s do some math.
The resolution of the menu is 1280 x 1080.
The anchor point of everything is at the middle of the screen meaning that to any amount we must add 640 and 540.
Everything moves by (1200/8)x3 and (1000/8)x3, which leaves us with 450+640 and 375+540 or 1090 and 915. But we need the margin left on the other side so we instead have 190 (1280-1090) and 165 (1080-915).
I’m gonna take the chance to adjust the corner button.
As you can readily appreciate, however, Nashira is working on the UI so that calculation wasn’t enough.
The tape texture is 48 pixels wide, which means that we gotta add an extra 24 pixels to our calculations. So for starters we’ll reduce the button to 166 x 141.
…actually, let’s make it 160 x 135. That gives it some breathing room and the numbers are prettier.
Okay so we’re set with those calculations, we can use them to create the template.
Let’s go back to the earlier numbers.
The pre-margin size we mentioned was 1090 x 915, to this we subtract the 24 from the tape texture and we have 1066 x 891, then we add the same 6 pixel offset to get 1060 x 885.
And so Scrunt was replaced with a yellow square.
…except not quite. I forgot that as a placeholder, the Scrunt image wasn’t an object proper, so I was just replacing the image of a sprite node.
Translation: Scrunt cannot be fully removed. Until I do this.
“looktemplate” is effectively the default. A couple of devlogs ago I explained how you can store objects into variables and we’re gonna do that again here… but first let’s cut the earlier examples to size.
This leaves us with three assets: The base, the clickable, and the clickable’s hitbox.
One more intermediate step, though.
Note: At this point my brain stopped working because whatever brain juice I had left vanished while answering some stuff my accountant asked, but stopping here would be extremely illegible so we’ll continue after I set a note on when I’m retaking the work.
Note 2: Work is resuming at midnight of the 9th.
We create a script attached to the “template”. Later down the line this script will control which Look menu it is meant to switch to based on variables and flags (so for example “show this when you’re at this location”). And we will briefly test that flow by making sure that the object changes to the new menu.
So let’s quickly assemble the test Look scene.
We create a child with a 2DTexture for the background and a TextureButton for the clickable that has a mask to single itself out.
Let’s first test it as-is.
If the Clickable is set right, the message “AAAAAAAAAAAAAA” should print in the console.
No such luck why the fuck.
Running a mental list of possible reasons, it occurs to me that maybe the menu buttons, which are meant to be disables, still overlap and cancel the clickability of it.
Let’s play just the Look scene on its own and check.
Bingo.
Now, I did a lot of testing around. I changed the layers, checked the z ordering, eventually it occurs to me to check what the remote resource tree shows.
And it basically shows the exact issue: The Look screen is basically being generated BEHIND all the buttons and as a child of the background, which actually explains why I had to tick the box that makes it go all the way to top level.
Which apparently changes the rendering but not the clickability, which is interesting.
It’s also good I caught this NOW because this would’ve been a pain in the ass down the line.
So let’s add this variable.
Make it do this.
And then we do this.
Idea being that it will attach one level above, as it were.
I foresee one error, but let’s take it one step at a time.
So let’s fire it up and………
Exactly as expected. It did prove to solve the problem for starters, though.
The solution, I suspect, will be easy, we just gotta add this so it addresses the child node at the higher level.
Before I post the solved version, let’s do a couple of changes.
For starters Nashira made the new buttons for the UI so let’s add those.
Next, let’s do the bit that this whole diversion distracted from: Instancing the look menu on a conditional basis.
Here’s some details thinking two steps ahead, however.
My original idea was to control this within the look screen directly, however, the game needs to load each look scene and it would be Insane to load them all at once, it’d obviously be better to load the ones needed for the respective chapter. So they’d have to be preloaded somewhere that exists before the Look screen is ever used.
It hasn’t become relevant yet (deliberately because I’m pushing myself towards advancing with cautious futureproofing instead of getting bogged by the futureproofing like last time I tried to make this game) but something I like to make is a global controller, an object that’s always there overseeing all states of the game and containing relevant information and code.
We haven’t seeing it in forever but we actually have one of these which is the one that makes the second screen pop up.
So we’re gonna go back to it and add this.
In the future this function would take which chapter of the game you’re starting and indicate which ones to load.
For now it will trigger at the startup of the game.
Placement that as the comment indicates, should change later.
Now, we need to create a signal that triggers when you click the Look button that changes which Look scene to show. It needs to be a signal because the ready function only kicks in once and we need this to change whenever things change in the game state.
Note: I felt incredibly stuck so I stopped for a moment to play Aion 2.
I am now back with the answer. And as is often the case with this sort of stumping, the solution was easy.
The problem is that the ready function only triggers once, well turns out there’s a function called enter_tree which triggers whenever the object enters a resource tree by being added.
Now we need to call the loaded scene into that bit of code.
First we do this, which checks the chain of parents of the node until it finds the one with that name.
Then we execute the function to preload the look scenes (as the comment indicates, this will change later).
Now with this testlook exists, so we do this…
WAIT.
That last bit was redundant.
Let’s reconvene for a moment.
The problem: Child Node needs to access info in the parent node.
Godot has means to go down the tree, but we need to go UP and moreover up from something that’s instanced.
Apparently you can emit a signal with the node pointing at itself. This would in theory give me something I can call back to to reference.
I’m gonna be honest, I’m stuck and it’s 5 AM. Progress was made regardless.
Let’s quickly recap what’s next:
(Temporary) To-Do list:
- Find a good way to call from instanced child to parent.
- Bitch, I might just make every function call its respective parent so there’s a traceable path.
- I think the issue is that the second screen is being instanced and thus it’s trickier to make stuff connected to it from something before said instancing.
- Maybe a signal that triggers a script in the parent?
- From there use that info to call the resource loaded by the parent.
- The final project will have this structure in some way so it’s important to learn that now.
- Instantiate the new Look screen with that.
This ain’t over.