So this is all well and good… but notice that we’ve had to hardcode the position of everything above.
Hovered Show("mm_tooltip",ttcontent="Quit") Hovered Show("mm_tooltip",ttcontent="Preferences") Imagebutton auto "gui/menu/prefs_%s.png": Hovered Show("mm_tooltip",ttcontent="About") Imagebutton auto "gui/menu/about_%s.png": Hovered Show("mm_tooltip",ttcontent="Load") Hovered Show("mm_tooltip",ttcontent="Save") Hovered Show("mm_tooltip",ttcontent="History")Īction Imagebutton auto "gui/menu/history_%s.png":
Hovered Show("mm_tooltip",ttcontent="Main Menu") Hovered Show("mm_tooltip",ttcontent="Return") Imagebutton auto "gui/menu/return_%s.png": (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(): You can lay them out however you want, but the important part is the “ Show” action for their hover attributes. Next are the actual menu items themselves. Transform mm_tooltip_show(delaytimer=0.0, duration=0.25): Xanchor 1.0 yanchor 1.0 ypos 1035 xsize 300 ysize 100 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. I believe this is also the more “traditional” way of doing tooltips.įirst thing’s first: We’ll need to define a screen to hold the tooltip text and a transform to show and hide it. You can even apply AT effects to the tooltip to make it fade out or whatever. This is fairly straightforward to do in the quick menu/game menu case, where the location of the tooltip is fixed. 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. Posted by admin JDecemPosted in Main Tags: updates, xenos, yaoijam Leave a comment on Xenopathy: Week One Codes: Hover Tooltips, Two Ways My goal is to have a super rough draft of the first half of the game done, and possibly also some further GUI cleanup.
Next week is likely to be more of the same. We’re also 7000+ words into it, so that’s some decent progress. We have a (very) rough draft of day one, along with the beginning of day 2. We got a few different variants to start the conversation on character design, and got to a rough sprite for him, but he’s already looking amazing!Īs for me, after getting some stuff done on the GUI, I’ve mostly been writing. There’s not a lot to directly show there, but suffice to say, this is probably the largest part of what’s gotten done over the past been hard at work on the first sprite, Axton. You can also set the screen to return with a variable so for example, if you want the player to have a selectable quest, the return() can be used to advance to the appropriate part of your script.We’re one “week” into Yaoijam (only because we started early), and we’ve made a lot of great been doing a lot of research, story planning, and world-building. Since you mentioned tasks being finished or unfinished, you can use variables you've set in your script to change the display (grey out quests that have been completed or add new tasks when information is gathered, for example). You can add in lines of dialog, images, buttons, etc. When you want the screen to go away, you can use returnįrom there it entirely depends on what you want to do. So for example in this file you could set the name of the screen as:Īnd wherever you want to call the quest menu, from a button or at a point in your script, you can call it with: rpy file for your quest screen to keep it seperate from your other defaults. This question is pretty broad, so I'll approach with a complete beginner in mind and what I recommend is looking into creating a screen:
0 kommentar(er)
