I'm not entirely sure I'm following your "text transitions to a corridor"... but let me have a crack at it.
Okay... first things first, RenPy will cope if you put your bits of code anywhere. The default names are just that... defaults. You could rename script.rpy to wibble.rpy and RenPy wouldn't care. It scoots through all *.rpy and *.rpyc files at the start (even the ones stored inside an .RPA archive) and processes the contents, not based on the file name.
All that said, conventions exist for a reason... and so it's easier to keep those script.rpy, options.rpy, etc. files... because they make sense.
Normally your
imagebutton:
would be part of a screen definition and that would be stored within the screens.rpy file.
You'd build up a screen with a background image, overlaid with images for anything you want to click on (these are your idle images) and a second version of those same "buttons" that is highlighted in some way (your hover image).
Both images are a format that support transparency (PNG or WEBP generally). Anything that isn't transparent become clickable. Anything that is transparent (0% alpha) isn't. This is controlled by the
focus_mask
parameter.
I usually make the
imagebutton:
idle and hover images the same size as the background image with lots of transparent area - since it means I'm doing all the alignment and positioning in something like GIMP or Photoshop and not within RenPy code.
But if you want to use smaller images the same size as your buttons/arrows and position them with
pos=(x,y)
or
xpos=x, ypos=y
that works too.
A neat UI trick is the make the hover image slightly bigger than the idle image... perhaps with a sort of glowing edge or halo. So when the
imagebutton: idle
image captures your mouse cursor and activates the
hover
image - it takes a little more effort to move the mouse away from the button.
I have an example of what I'm talking about here :
https://f95zone.to/threads/finding-...-point-click-game-on-renpy.25325/post-1565577
Maybe scroll up a few posts too. Rich's post includes actual code examples and was the basis for my own post.
So if you had a corridor with 4 arrows... You'd start with a background image, then 1x idle and 1x hover image for each arrow. For a total of 9 images and 4x
imagebutton:
definitions (one for each arrow). Each
imagebutton:
would have an associated label that the program jumps to when the arrow is pressed.
So now we're back to the code...
You reach a point in your program where you've displayed some text and now want the player to pick an arrow. So you do a
call screen {screen-name}
probably in your script.rpy. It shows all the elements of your screen... including the background image and the four clickable arrows.
You might want to even show the background image for the corridor, display some lines of dialogue before actually calling the screen to show the arrows and let the player pick their destination.
When the player clicks an arrow, the program jumps to whatever line of code you've specified in the screen definition. From there - it's up to you. Show new pictures. Display new dialogue... Whatever. Including calling another screen with more clickable areas.
Most of the stuff that will be going on will be within your script.rpy file, except the actual definition of the screen and it's clickable areas (and where those clickable spots jump to within your code).
Obviously, I've talked about 4 arrows. It could be one. It could be a vase or a light switch or a person or a doorway. It's purely about your imagination.
As I've said in the other post I linked... I found a good example to look at was
You must be registered to see the links
, which you'll need to unpack using a tool like
You must be registered to see the links
. Thankfully it's use of imagebuttons (for buildings in this case) is really near the beginning of the game... so you can play it a bit... see how it works from a user standpoint... and then use UnRen to pick apart how it's actually doing things and the images it's stitching together to make things clickable.
The code I personally wrote eventually ended up in
Cuntswell Academy. That's not right at the beginning of the gameplay, but the actually code is probably a bit simpler to pick apart (in my opinion). Obviously any game with irregular shapes as clickable areas is probably doing more or less the same thing.