[Ohrrpgce] Slice based menus

Mon Feb 13 07:47:46 PST 2012

One more afterthough on this-- although the SelectableSlice seems like a 
really obvious and simple feature (to me) for the implementation of 
customizable special screens, I have no clear idea in my head about how 
SelectableSlice would work for purely plotscripted slice collections, 
and I am especially fuzzy about how plotscripted keyboard interaction 
would work together with SelectedSlice's focus-action handlers for arrow 
keys and confirm/back keys.

---
James

On Mon, Feb 13, 2012 at 07:28:33AM -0800, James Paige 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
> 
> 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
> 