Let’s make a menu today.
First, the proof of concept. Last time I stressed about morphing shapes and whatnot, but in the… *checks notes* MONTH in between work sessions, a smarter solution came to mind
Instead of doing any super duper fancy morphing, the idea is to grab a very big image behind a mask and move it around.
Like so.
Okay, not like that hold on…
Liiiiiiiiiiiiiiiiike so.
As you can tell the effect is great when the motion is constant instead of wavy… also as you can tell, I need to consider the size of the box.
I need to consider the size of everything, actually.
I can always upscale, and since we’re not doing something meant to be retro-looking it’ll probably have high resolution assets scaled accordingly.
So as a base I’m going to work with 1920×1080 for the main screen and 1280×1080 for the second screen with an option to scale either of them accordingly with your machine.
The more keen-eyed among you might realize that’s the screen resolution in the Ayn Thor. Too early to really say anything and at this point it’s more of a pie in the sky sort of thing, but it’s a good starting point if nothing else.
So with that in mind, the menu image needs to be basically twice the resolution which means… 2560 x 2160. Let’s round it to 2700 x 2300 to give it some bleed on the edges.
We make a Node2D that has a Sprite2D and…
Next, since we don’t have buttons in the usual sense, we need hitboxes.
I turned two of the buttons invisible, but you get the point. Now there’s white “buttons” and they can be turned invisible.
Also yes, I know the purple line is imperfect, there’s a lot of adjustments I need to do anyways.
So from my stint trying to get this project going last year (hello to everyone still visiting the blog from that first post, by the way) I remembered signals and such in buttons.
Basically we double click on the “pressed” signal of the top left button.
We tell it to go to menubg’s attached script and it will conveniently create the code connecting both.
To that code we add an arbitrary number to test that things move.
However, as you can appreciate, movement is instantaneous and not ideal.
So we expand the code a little…
Here’s how it works: _process is code that’s checked every frame, if we want something to move the code should be there. Inside of it there’s movemenu, which will run as long as it’s true, and then depending on which menu is activated, it changes where it moves with Godot’s equivalent of a Switch.
The result is this:
I’ll stop here since I need to sort what assets I need to continue, but let’s go through the list:
To-do list:
Create buttons that morph as intended- Solved in a more clever way.
- Finish the movement pattern for all menu states.
- Make each menu spawn buttons.
- The state machine for this has been set up.
- Also disable, the main buttons when the state changes.
Attach rudimentary actions to each button to adjust later.Changed to: Create a Rudimentary shift when the state of the menu changes.
Now, this is usually where things would end but I figured it’d be fun to add some progress for the characters and such. Don’t expect them all the time but expect them every so often.
Let’s go a bit more in depth about the one character I’ve already teased:
Fujinomiya Yuri
The new protagonist. A very sheltered sort of creature that accepted the role of assistant of the eponymous Detective.
Nashira’s comment about them:
“The game is called Everyone’s Detective, so I pulled a lot of design inspiration from detective procedural dramas that I enjoy. Yuri is the player’s character, and I wanted to start with an homage to the iconic detectives from Kamen Rider W. Since Yuri’s image color is green, I bet you can guess what color our dear Detective will be, right? 😘“
I might be able to get more coding done this week, but don’t expect the next teaser until at least next week.