Plan for improved mouse support

Jump to: navigation, search

Currently, mouse support in the OHRRPGCE is quite limited. Normally the mouse does nothing, but there is a plotscripting information for getting mouse position and button state.

One possible way to handle mouse support would be to allow special mouse handlers in certain contexts.

better mouse functions[edit]

Right now we have commands for detecting which mouse buttons are and are not being held down. I also want to add commands for detecting if a mouse button has just been clicked down (true first tick since pushed) and if a button has just been released (true first tick after release)

map mouse handler[edit]

  • Manual - this is the current setting. Mouse input can be plotscripted, but never happens automatically.
  • Pathfinding - clicking on a maptile causes the hero to walk to that tile using some kind of pathfinding (A* would be nifty, but not essential). clicking on an NPC adjacent to the hero causes a spacebar press. right-click causes an ESC press to bring up the menu (obviously better than "Simple" but requires a lot more work to implement)
  • Luddite - Any click results in the display of a help screen that explains the standard keyboard controls. (This might be the best/safest default for old games that don't use any mouse plotscripting commands)

Emulator-style touchscreen overlay is already implemented for the Android port via sdl-android. That implementation is superior to what we could do inside the OHRRPGCE, because it has multitouch support.

menu mouse handler[edit]

Special handler only used when at least one menu is open. We probably want to have a global default for this, but allow individual menus to override it. Need to think about how to resolve the situation of multiple menus being visible at the same time.

  • Manual - manual mouse support by plotscripts only
  • Use Map Mouse Handler - no special menu handler, defer to the map mouse handler instead.
  • Clickable menus - point to a menu item to focus it. left-click to activate it. right-click to send an ESC to close the menu. Scroll-wheel should scroll. Clicking outside the menu should probably also close the menu.

battle mouse handler[edit]

Special handler used only inside the battle mode

  • Default - point to menu items to select, click to activate. right-click for ESC to close menus or skip turns. Click enemies and heroes to target attacks. double-click to spread optional focus attacks. (Needs further thought for touch screens where right-click may be impartical)
  • Manual - (future) When battlescripting is enabled, allow scriptable mouse control. Probably using the same commands as for scripting the mouse in map mode.

special mouse handlers[edit]

Non-scriptable special menus also need mouse handlers

  • Item menu mouse handler
  • Spell menu mouse handler
  • Equip menu mouse handler
  • Order/Team menu mouse handler
  • Quit menu mouse handler
  • Save menu mouse handler
  • Load menu mouse handler
  • Shop-buy menu mouse handler
  • Shop-sell menu mouse handler

(Did I forget any?)

This would be a great time to convert these screens to use slice trees instead of manual layout. Plan for converting special screens to slices

If/when any of these menus become optionally scriptable, they could also get optional manual mouse control.

backwards compatibility[edit]

  • current games that use the mouse must call init mouse this command can force both the map mouse handler and the menu mouse handler to "Manual". The command can be deprecated for new games, but kept around to keep old mouse-driven games working correctly.
  • new commands can be added to change various mouse handlers.

crazy ideas[edit]

Accelerometer mouse handler - Use mouse movements to simulate an accelerometer. This would be cool because for future Wii/iPhone/Android ports this mode could be controlled by a real accelerometer. This mouse mode would need to exist so that games which require the accelerometer could still be played on platforms that lack one (Windows, Linux, Mac) Special care would have to be taken to make this emulation reasonably accurate to the behavior of a real accelerometer. Much testing required.