Codes: Hover Tooltips, Two Ways

Part of the GUI work I did for Xenopathy was converting traditional buttons (in the quick menu, game menus, and confirmation screen, for example) into images, with hover tooltips that provide an explanation.

This is fairly straightforward to do in the quick menu/game menu case, where the location of the tooltip is fixed. You can even apply AT effects to the tooltip to make it fade out or whatever. I believe this is also the more “traditional” way of doing tooltips.

First thing’s first: We’ll need to define a screen to hold the tooltip text and a transform to show and hide it. In this case, the tooltip fades in as it moves leftward out of the buttons, and fades out as it moves rightward back into the buttons.

screen mm_tooltip(ttcontent):
zorder 9999
text ttcontent:
xanchor 1.0 yanchor 1.0 ypos 1035 xsize 300 ysize 100
at mm_tooltip_show
font gui.name_text_font
transform mm_tooltip_show(delaytimer=0.0, duration=0.25):
alpha 0.0
xpos 1305
linear duration alpha 0.5
linear duration xpos 1265
on hide:
linear duration alpha 0.0
linear duration xpos 1305

Next are the actual menu items themselves. You can lay them out however you want, but the important part is the “Show” action for their hover attributes. (I’ve also added ATL effects, not shown above, to the buttons themselves so they fade in and out, in addition to the tooltip text.)

screen game_navigation():
style_prefix "navigation"
xanchor 1.0
xpos 1800
yanchor 1.0
ypos 1045
spacing 4
imagebutton auto "gui/menu/return_%s.png":
hovered Show("mm_tooltip",ttcontent="Return")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), Return()]
at qm_at
imagebutton auto "gui/menu/main_%s.png":
hovered Show("mm_tooltip",ttcontent="Main Menu")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), MainMenu()]
at qm_at
imagebutton auto "gui/menu/history_%s.png":
hovered Show("mm_tooltip",ttcontent="History")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), ShowMenu("history")]
at qm_at
imagebutton auto "gui/menu/save_%s.png":
hovered Show("mm_tooltip",ttcontent="Save")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), ShowMenu('save')]
at qm_at
imagebutton auto "gui/menu/load_%s.png":
hovered Show("mm_tooltip",ttcontent="Load")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), ShowMenu('load')]
at qm_at
imagebutton auto "gui/menu/about_%s.png":
hovered Show("mm_tooltip",ttcontent="About")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), ShowMenu("about")]
at qm_at
imagebutton auto "gui/menu/prefs_%s.png":
hovered Show("mm_tooltip",ttcontent="Preferences")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), ShowMenu('preferences')]
at qm_at
imagebutton auto "gui/menu/quit_%s.png":
hovered Show("mm_tooltip",ttcontent="Quit")
unhovered Hide("mm_tooltip")
action [Hide("mm_tooltip"), Quit(confirm=not main_menu)]
at qm_at

So this is all well and good… but notice that we’ve had to hardcode the position of everything above. In particular, the location of the tooltip screen’s text was hardcoded to be placed next to the menu buttons.

What happens now when we’re dealing with a modal screen (like the confirmation dialogue) that isn’t always located at a consistent place on the screen? We can’t exactly place the text at a certain x/y coordinate and expect it to look right all the time.


I tried a few different things for this… the most naive approach was to copy the above approach, and use the “use confirm_tooltip” to include the screen next to the buttons. While this does indeed show the screen, it also strangely results in the screen being shown twice: Once next to the buttons as expected, but again in the top left corner of the screen on hover.

Instead, I kind of hacked around the problem, using simple text elements that are rendered (or not) based on the state, and attaching ATL effects to them. This is definitely not ideal, but it does work.

In this case, we only have one screen (the confirmation dialogue itself) and attach transforms directly to text elements within it.

screen confirm(message, yes_action, no_action):
modal True
zorder 200
style_prefix "confirm"
add "gui/overlay/confirm.png"
default tt_val = ""
default tt_last = ""
xalign .5
yalign .5
spacing 20
label message:
style "confirm_prompt"
xalign 0.5
text_font gui.name_text_font
null height 25
spacing 4
yalign 1.0
xalign 1.0
if tt_val != "":
text tt_val:
yalign 0.5
font gui.name_text_font
at confirm_tooltip_show
text tt_last:
yalign 0.5
font gui.name_text_font
at confirm_tooltip_hide
imagebutton auto "gui/menu/confirm_%s.png":
hovered [SetScreenVariable("tt_val", "Yes"),SetScreenVariable("tt_last", "Yes")]
unhovered SetScreenVariable("tt_val", "")
action yes_action
at qm_at
imagebutton auto "gui/menu/cancel_%s.png":
hovered [SetScreenVariable("tt_val", "No"),SetScreenVariable("tt_last", "No")]
unhovered SetScreenVariable("tt_val", "")
action no_action
at qm_at
key "game_menu" action no_action
transform confirm_tooltip_hide():
alpha 0.5
xoffset 0
linear .25 alpha 0.0
linear .25 xoffset 50
transform confirm_tooltip_show():
alpha 0.0
xoffset 50
linear .25 alpha 0.5
linear .25 xoffset 0

And… voila! I first attempted to do this with a single tt_val text element, and an “on hide” directive in the transform, but it didn’t work, for some reason. The second tt_last text element is a hacky workaround, but it does do the trick.

May Updates

There wasn’t much to report for May… until a few days ago. The day job had gotten really busy, and there was no real YAGS asset progress – my sprite artist was on a crazy work schedule for his webcomic (and therefore has had no time for sprites since the first week of April), and my background artist had been unresponsive since January – so I kind of put gamedev and game projects (i.e. AFS) off to the side.

So, of course, the right thing in my dearth of gamedev motivation was to start a new game, for Yaoi Jam. (/s)

It showed up in my Twitter feed (on a rare day when I was actually checking it), and we came up with an idea, so now I’m working on a new game with @pmscenarios​. It’s tenatively titled Xenopathy, and is a sci-fi romance thriller kind of thing that will hopefully be a lot of fun to write. (We’ve also enlisted the talents of @soulsoftea​ on sprites, which will be amazing.)

I’ve spent some of the long weekend working on the GUI for the game. It’s mostly done, minus cleanup of the screen contents (preferences, load, save) and a possible redesign of the start screen. But it’s already easily my deepest dive into RenPy screen language and ATL ever, and I think it turned out pretty well.

In YAGS news, I found a new background artist, Vui Huynh, to finish up the final two backgrounds, so I hope to have all backgrounds replaced in-game by the end of June. Here’s a sketch of the game room.

YAGS’ music is also making progress. We’re only missing two more demo tracks, at which point I can start staging music into the game. I also received the shortened version of the YAGS theme, which I’m going to use to throw together a game trailer (using RenPy!). I assume none of that is happening soon, given the game jam, but hopefully by the end of August we’ll have a lot more progress to report on YAGS.

So that’s been my May… it’s been busy, especially considering almost everything above has happened within the last week.

Not really sure what I’m doing with AFS at this point. I do want to finish it, at some point, but RenJS is proving to be a pain to work with because I can’t run the game locally, and I’m not in the right frame of mind to either be developing live on a server or uploading changes constantly for testing. I might have to research other HTML-based visual novel engines, because using RenPy (and forcing players to download the game and run it) seems like overkill.