Native 'menu' feature creep: cursor control, cursor detection, and dismiss detection

Pulp Feature Requests
1

I'd like three new features in the native menu implementation:

  • cursor control: an option to emit an event (e.g. from the player.draw handler) to control which option the cursor is pointing at
  • cursor detection: an event emitted by the menu when moving the cursor between options, indicating which option is currently selected by the cursor
  • dismiss detection: an event emitted by the menu when either the root or a submenu is dismissed without selecting an option

1. Describe your reason for requesting this feature. What problems are you running into?

  • cursor control: this would enable code to let users control a menu using the crank. it would also allow developers to record the "most recently used" menu item and to pre-select that item. these are convenience features to make a game with complex menus more enjoyable
  • cursor detection: this would enable custom animations or other draw events to run alongside the menu. e.g. to display a large multitile sprite representing the currently selected option
  • dismiss detection: this would allow for custom draw scripts running alongside the menu to be closed appropriately when the menu is dismissed (selecting an option, rather than dismissing, could set a flag to indicate this - but we can't currently detect when a menu is dismissed instead)

2. How would this request improve your experience with using Pulp?

  • I currently have to create my own menu-like widgets using windows, labels, and control logic in order to approach functionality as described above. This is made even more difficult when the player uses the d-pad and the character moves around the screen behind my custom menu. In this case I need to undo those movements - a custom menu cannot trap and redirect user input to prevent this. Undesired movements may spring traps/etc in the game, which therefore require additional control logic to check "should this movement be ignored"?
  • Native implementation would allow for more time spent developing the game itself, and less time spent trying to make a complex menu structure usable by the player.

3. Include any other details you have relating to this request.
I'll admit that advanced features might be best suited to the SDK. Still, I suspect that Pulp devs might make good use of these features if they were available.

2

also worth considering:
a [menu] variant which does NOT close when the user selects an option. instead it would only close on a dismiss event.

This would be useful for creating a breadcrumb trail for submenus where players can drop several layers deep into menus then back out gracefully one submenu at a time.

It would also be useful for menus full of options might be used in relation to each other. e.g. in my current project a user can switch between "autonomous" and "manual" modes, so i have a menu option for that. if you switch to manual mode you'll almost certainly want to then scrub down the list and select a new tool (from a submenu) to use in manual mode. If you switch to "autonomous" mode you'll almost certainly want to scrub down the menu to select a specific autonomy script (from a submenu), and perhaps to another menu option to edit that script (in yet another submenu).

For all of the above functionality my current implementation looks like this:

  1. in player.draw handler, check if mnu_draw==1. if so, call a complicated script called drawSelf located in a tile called MENU
  2. in MENU.drawSelf, check if mnu_open==0. if so, call a script to render the root menu then set mnu_level=1
  3. in MENU.drawSelf, draw a window and some labels to show all the dynamic data associated with the current mnu_level. note that player.draw will call this script every frame, so any changes to variables will affect the next frame
  4. in MENU.drawSelf, if the user selects an option (and therefore closes the menu) set mnu_open=0. this causes drawSelf to render the menu again when called on the next frame
  5. keep track of the current mnu_level throughout this process, updating the variable as i navigate deeper into submenus, and only setting mnu_draw=0 when the user selects the "Return" option on the root menu. setting mnu_draw=0 causes the player.draw script to stop calling this MENU.drawSelf script on each frame

as you can see it's a fairly messy solution - still a work in progress, perhaps i'll find a cleaner way to approach this?

1 Like