Sure! It’s gonna be a bit long though, so here it is under the cut:
STEP 1:
First, you start with a loop. Inside the loop, you’ll have five conditional branches listening for button input: the select button and the directional keys. I don’t recall if the 5 frame wait was actually essential or not... it was either there for aesthetic purposes or to keep the loop from spinning too fast for player input to actually register. I left it there just in case. Since the loop exits when the player makes their selection, you have a Break Loop line goes in the select button conditional.
STEP 2:
(I’ve grayed out the unimportant lines so that the ones we’re adding are highlighted)
Above the loop, we’ll place these lines. The Move Route line tells the player to repeatedly wait, locking them in place so that button input can be used for the menu instead and they’re not scurrying around in the background the whole time. :P Show picture shows the graphic for the cursor (an empty rectangle) and the menu, which in my case, was eight boxes with headshots and a title. The next line is the Index--aka the ID of which player the cursor is currently hovering on:
This is the index number that’ll correspond to each character, eventually.
Anyway, back to the last code screenshot: The X and Y positions are the default starting coordinates (in pixels) of the cursor. Keep in mind, the 16 and 129 are for my menu--if yours isn’t shaped exactly like mine, they’ll be different. Getting the coordinates right so that everything lines up can be a bit time-consuming--I suggest measuring the size of the RPG Maker game screen and your planned menu and cursor when you make the graphics so you know approximately what values you’re going to need to use. In Step 3, I give you some guidelines for calculating coordinates.
Finally, under the select button conditional, we’ll set the permanent player ID to the current Index value. This way the player will be set before the loop is exited.
STEP 3:
Here’s the code to move the cursor when the player presses each button. My menu is 4 items long and 2 rows tall, so moving the cursor down one row increases the index by 4. Moving it right increases it by 1. Moving left or up is the opposite of that, so you subtract the value from the index instead of adding it.
Similarly, we increase and decrease the X and Y positions depending on how the cursor object moves. Move it right and the X position will go up, as it moves further from the left side of the screen. Move it down and the Y position goes up as it moves further from the top of the screen... you get the picture. The conditionals check to make sure the cursor coordinates stay within the bounds of the menu (so you can’t move down if you’re already on the bottom row and can’t move left if you’re already on the left edge of the screen, etc). Simple enough, right?
Now, how did I get those boundaries and how did I determine how many pixels to move the cursor? To calculate how far over to move the cursor, you want to look at the size of the items on the menu and the space between them. Say, for example, each headshot (or whatever you use) is 100x100px in size and has 20px of empty space on all sides. That means you’d want to move the cursor 120px each time to move it to the next one.
Calculating the bounds of the menu works similarly. If your menu is three items long and has 50px of empty space to the left of it, you’d want 50 + 120 x 3 = 410 to be the right boundary of it. The left boundary would, of course, be 50.
The main loop is now complete!
STEP 4:
Now, for cleanup. After the part with the loop, I zero the index and X/Y position variables because it’s good practice and I may want to reuse those temporary variables for another menu later. I erase the cursor and menu background graphics. I then change the player’s default name and graphic to the one that corresponds to their ID value, as I set in Step 2.
Finally, after the block that sets player graphics, I end the player selector with a non-repeating wait, which stops the endless wait loop they’ve been in while the menu code was running and returns control to the player.
Aaand that’s it! I think that’s everything. I hope it’s been helpful! Let me know if this doesn’t work for you. I don’t think I missed a step but it’s possible.
By the way, this is the same logic I use for most of my custom Wishbone menus--with alterations, this can be a custom inventory, crafting menu, or anything else you might want!