[Ohrrpgce] Slice based menus

Sun Feb 19 06:59:22 PST 2012

On 17 February 2012 05:31, James Paige <Bob at hamsterrepublic.com> wrote:
> On Fri, Feb 17, 2012 at 02:30:55AM +1300, Ralph Versteegen wrote:
>> On 14 February 2012 04:28, James Paige <Bob at hamsterrepublic.com> wrote:
>> > I think that slice collections are already very close to being able to
>> > do everything we need for special screen layouts.
>> >
>> > The fundamental feature of menu items that sets them apart from any
>> > slices we have right now is the fact that menus need to have a concept
>> > of keyboard-focus, and they need a way of knowing how they are connected
>> > by arrow key movements. (btw. I believe this was the main intent of the
>> > original "slices" from the ohrrpgce-fmf implementation that inspired the
>> > ohrrpgce's slice system in the first place)
>> >
>> > The GridSlice can already do a good job of arranging menu items into
>> > menu-like shapes.
>> >
>> > Complex menu items, like in the Save menu or the Load menu can be
>> > separate slice templates. Or to explain that another way, the save menu
>> > could use two templates. One for the save screen, and one repeated for
>> > each save game slot.
>> >
>> > What we are really missing is features for controlling keyboard focus.
>> >
>> > (James commences thinking-while-typing)
>> >
>> > Suppose every slice has the ability to be focused, although all slices
>> > are non-focusing by default.
>> >
>> > If I was creating the Save menu, I would mark the save slots as
>> > focusable... I mean in the layout template for the whole save screen.
>> > Nothing in the slice layout for individual save slots would need to be
>> > focusable.
>> >
>> > Focus needs to be displayable somehow. This is the same as the selected
>> > and unselected animations you were talking about.
>> >
>> > A selected and an unslected mode for a slice is more or less the same
>> > thing as bifurcating all the slice's visual properties.
>> >
>> > Imagine if a SelectableSlice was a special type of container slice that
>> > has two children. The first one is displayed when it is unselected. When
>> > it becomes selected, the first child becomes hidden, and the second
>> > child becomes visible.
>> >
>> > A SelectableSlice could also contain the properties that describe how
>> > keyboard focus changes. We could certainly have a simple spatial
>> > heuristic that would make a good default. Press the left arrow, and move
>> > the focus to the next slice with a smaller X position. Or maybe a
>> > smaller X center.
>> >
>> > We could also have focus handlers like: press the up arrow and move
>> > focus to the first selectable ancestor. or press the down arrow to move
>> > to the first selectable child. We could also have handler that would
>> > jump to a specific other slice by lookup code in response to a key.
>> >
>> > Besides directional arrow keys, we could also have handlers for Confirm
>> > and Cancel.
>> >
>> > I probably shouldn't be using the world handlers here, because that
>> > sounds like a script thing. Maybe I should call them focus-actions, ...
>> > although triggering a plotscript would be a great focus-action.
>> >
>> > Does any of this make sense? Does any of it jive with what you are
>> > thinking about this issue?
>> >
>> > I looked at all those screenshots that you mentioned, and I think that a
>> > SelectableSlice could handle all those situations without too much
>> > trouble.
>> >
>> > ---
>> > James
>>
>> At first this sounded orthogonal to what I was talking about, but then
>> I thought it seems a bit incompatible, since you seem to be talking
>> about SelectableSlices handling input themselves, without an explicit
>> menu anywhere, but after another reread, it seems like you might be
>> talking only about replacements for the builtin menus, completely
>> separately to usemenu- or MenuDef-based menus.
>
> Yes, you are absolutely correct. I am only thinking about replacing
> built-in screens, and not thinking about usemenu/menudef stuff.

I see now that I started out by stating something along the lines of
"it would be nice if someday all the built-in menus could be built
using customisable/MenuDef menus" and at some point I started assuming
that they must be unified. I'm still attempting it, but I have a fresh
point of view.

>> I'm not sure that I'm keen on the focus handlers, though, because it
>> sounds like it's doing away with having a menu object (by which I
>> guess I mean MenuState), which is probably the idea. But without a
>> menu object, how do you get things like page up/down, scrolling, and
>> activing or deactivating a whole menu?
>
> I think that MenuState type features are a different thing. But you are
> right. To do menuish things we do need another type of slice that
> encapsulates the features of the MenuState, and that would still be
> compatible with the SelectableSlices solution for more spatially complex
> but less menuish things.

Now I see that MenuState-less slice selection could be useful for more
than just targetting enemies: some menus like the load/save screen are
weird.

So maybe MenuSlices (the root of a menu's slice collection) and
ItemListSlices (associated with a MenuState) should be separate
things? I'll have to think about that more.

Or rather, you could add extra buttons (e.g. New Game, Quit) to a
menu's slice collection as SelectableSlices, and need to tag exactly
one slice with the "menu item list" lookup code.

> Consider the Equip screen. The equip screen boils down to a collection
> of decorative and informational slices, plus two separate menus. One for
> the menu slots, and one for the available equipment. Suppose the slice
> layout template for the Equip screen has two MenuSlices, and two
> selectable slices. In this case, I guess there would be no place for
> focus handlers on the two SelectableSlices, they would just be there for
> changing the appearance of the two menus as focus changes between them,
> but the actual focus change would be done by selecting slots and
> equipment in the menus.

I think the available equipment menu should actually be treated as a
separate menu (with a separate slice collection); it's basically the
same as spawning a new menu from a menu item.

Normally when focus changes to a submenu, the parent menu stays
visible. We should add a bitset to cause inactive menus to become
hidden. But what if the menu has both menu items and
decoration/background, and you don't want to hide the background? I
guess it should just be shown separately, then.

(On that tack, it would also great if menu items could serve as anchor
points for submenus. Think of regular menus in any application.)

>> SelectableSlices could work, but sounds like unnecessary complexity
>> and something that should be abstracted a little: if you have a simple
>> textual menu item, then having to modify both children when you want
>> to do something like add an icon on the fly with a script sounds bad.
>
> Good point. Updating two copies of a child would be a pain.
>
>> Rather, we could use the two-children-one-hidden system for maximum
>> flexibility, and something simpler the rest of the time: change the
>> appearance of your children whenever your focus changes. Have some
>> functions/script commands to abstract the difference.
>
> That seems like a good compromise
>
>> To facilitate that, an idea I just had is adding "compound UI colours"
>> (or "menu UI colours"). Each such compound colour (which preferably
>> would have a single UI colour number from the point of view of user,
>> though I guess it would be multiple uicolor() entries) would consist
>> of the following:
>> -normal
>> -selected (2 (or more?) colours)
>> -disabled
>> -disabled selected (multiple)
>> If you set a text slice to a normal (master palette) entry, or a
>> regular UI colour, it wouldn't animate when selected, but if set to a
>> compound, then the display colour could automatically adjust if used
>> anywhere inside a SelectableSlice/MenuItemSlice (are these the same,
>> or do disabled colours only make sense in the later?)
>
> I like that
>
>> You might remember that I suggested some "texttags" (markup) that
>> would cause the text colour to toggle or shift randomly. That could be
>> based on compound ui colours too.
>>
>> Getting back to "simpler" SelectableSlices, the only thing that would
>> change automatically would be the display colours of anything using
>> compound ui colours.
>
> That reminds me! right now there is no way to use uicolors for text
> slices or rectangle slice colors! That was on my todo list, and I forgot
> about it :P

I finally see a set of starting points for this. I may do that one as well.

>> > On Fri, Feb 10, 2012 at 03:57:59AM +1300, Ralph Versteegen wrote:
>> >> 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?).
>> >> _______________________________________________
>> >> Ohrrpgce mailing list
>> >> ohrrpgce at lists.motherhamster.org
>> >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >>
>> > _______________________________________________
>> > Ohrrpgce mailing list
>> > ohrrpgce at lists.motherhamster.org
>> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org