[Ohrrpgce] Slice based menus

[Ralph Versteegen]

I've been struggling to decide how slice based menus should work, so I
need some input. I've been thinking about it for years, but could
never decide where to start (writing this helped a lot though).

This isn't about making menus draw themselves using slices, but to
allow more complicated menus, like some of the features in these
examples:
* Our existing items/spells menus. (In future, it would be nice if the
item and spell-list menus were slice-menu-based.) That means allowing
'empty' menu items too. I'm including the Desciption line at the
bottom; to support that (generically), you need to be able to edit a
slice collection for the editor, and tag slices (lookup codes?) to
show data on the currently selected menu item. I imagine that such
menus should have "types" (eg. items, heroes, spells), and contain
menu items which are of the correct type (or "typeless" like our
current ones)
* Our existing save/load menu. After all those wonderful animation
features are implemented, we could allow creating "selected" and
"unselected" animations on sprites... but defining a "selected"
animation on a hero battle sprite which is used only in the save menu
is just too obscure.
* http://rpgmaker.net/media/content/users/45/locker/MenuWIPX.png
  (This seems to the standard RPG Maker VX menu, themed a bit) --
notice the 'cursor' is a highlighting rectangle behind the menu item.
That type of cursor will be tricky to implement if menu items can be
variable size, and if it should move smoothly between items.
* Everything on this page:
http://www.rpgmpavilion.com/index.php?page=rpgtdseditor
  Things can change colour or image when you select them; the cursor
can be both a litle hand icon and an outline rect; paginated menus
(next/prev page icons/buttons)
* http://www.mobygames.com/game/iphone/doom-ii-rpg/screenshots/gameShotId,430863/
  (The OTHER Doom RPG) Custom scroll bar, mouse support. (Guess the
background could easily be part of it too)
* http://www.roc.noaa.gov/WSR88D/Operations/EPSS_B10/rpg_epss/selectable_parameters/rpg_products_window.png
  Menu items (unselectables here) which look totally different. Yes I
know that's a completely different type of menu.

I don't want to spend a lot of work on something that's overly complex
and won't be used. Both static menus created entirely in the editor,
and what can be done with scripted menus should be improved. However
complex features which are only useful in combination with scripts,
and which don't save much work over scripting from scratch should be
avoided. (I seem to be bad at determining this cutoff.) So here are
the ideas I wanted to bounce.

I see a lot of patterns in the above examples. Focusing on just some
of the features for now, I suggest that for each menu should have two
editable slice collections: the menu itself (background/rect,
scrollbar, things like a 'Description' line, additional decoration),
and a menu item template slice collection. The thing is, without
scripting, the only variable part of the template would be (I imagine)
the text slice inside it flagged with the 'caption' lookup code.
(Maybe lookup codes are too restrictive for flagging slices for this
purpose.) To allow more variability, we need one of:
* add more properties to (all) menu items, like "icon", "description".
I guess extra data could also be used, but how exactly are you meant
to apply an integer to an arbitrary slice type?
* "typed" menus, as I mentioned before. Then we can have lots of
type-specific flags (lookup codes), like "item value" and "text
describing who can equip item"
* some way to define new menu item properties specific to a single
menu (using slice lookup codes to flag wouldn't work so well, they
would have to be dynamically allocated)

Also, these lookup codes could be applied to slices in the menu slice
collection and be set using the selected item (such as for a
'Description' line).

If menu data was RELOAD-based, it would be easy to just store slice
collections inside the menu data; unfortunately they aren't. So I
guess they'll go in separate slice collection collections.

Being able to edit menu's slice collection is a big problem, because
this duplicates a lot of existing options, such as menu size and
placement and box visibility and text alignment, in much more
complicated ways. And once you edit the slice collections manually,
your changes won't necessarily be mappable back to the existing
options. So maybe we would need to make these two editing methods
mutually exclusive. This sounds like additional complexity and
confusion though.

Cursors could be implemented as a third slice collection, allowing
lots of flexibility, but I won't get into that.

On to some implementation details. Currently my idea is three new
types of slices:
- MenuSlice
  Top level slice. Just a container, eg. for the menu items container,
background box if any, etc. Associated with a menu (freeing it would
close the menu; have script command to get the menu handle), but
probably nothing else special about it.
- ItemLayoutSlice
  A container to which all the menu items are parented. Freeing
directly not allowed. Similar to a GridSlice, but we need more
flexibility, especially menu items with variable heights. In
particular, we need a type of container which resizes itself to
contain all of its children, rather than the other way around. This
would be independently useful for users, as an alternative to
GridSlices.
- MenuItemSlice
  Also a container. Associated with a menu and menuitem (freeing would
delete the menu item; allow reordering menu items too?).