[Ohrrpgce] Textbox Discussion

[Ralph Versteegen]

On 6 June 2017 at 10:54, Jeremy Bursey <zippywings at hotmail.com> wrote:

> Hey Guys,
>
>
> I'm subscribed to the mailing list digest, not the individual messages, so
> I can't respond to the messages directly, but here's my input about the
> text/menu activation debate you started recently:
>
>
> Regarding *Entrepreneur*, it uses text, menus, and slices to convey its
> information, sometimes all at once. It's just as chaotic as the rest of the
> game's design. But I try not to let any of the elements overlap, though the
> screen size sometimes makes that unavoidable.
>
>
> What I'm moving toward in either the next release or the one after that is
> to use menus as choice box selections to allow for multiple player inputs
> at the shopping level (and wherever else choices are made), which players
> will select while the textbox is open. My preference is to move the item
> descriptions into vertically-placed textboxes (or text slices) that cover
> the right half of the screen and keep the choice boxes on the left, since
> that'll allow the player to see all of the choices at the same time rather
> than having to scroll through them, which I would need to do if I kept the
> text on the bottom and the choices on the top. This also means that I would
> need to take advantage of the custom screen size by changing the dimensions
> from 320x200 to 448x280 in order to fit everything on screen comfortably.
>
>
> So, I would need to display menus and textboxes together, or menus and
> text slices together to keep the current design functional and compatible
> with future development.
>
>
> As far as menus and gameplay is concerned, the only element of the game
> that currently uses menus as a control item is the painting sequence at
> Pine Alley Drive. The protagonist moves according to menu selection, and
> the player has to select either "Done for Now" or "Done for Good" to regain
> control of the character. The text doesn't appear until the menu is closed,
> but it doesn't mean I would never want text to appear while it is
> activated. However, I'm not against writing text slices for that.
>
>
> Regarding two textboxes on display at once (or stacking textboxes), I see
> a benefit to that if the screen size is large enough to justify it, but
> unless the two texts are both clearly visible, I don't see the point. *Powerstick
> Man XE* and *Tightfloss Maiden* both fake double textboxes for their
> displays, and do it competently. Maybe it's easier to do it natively, but
> slice collections really do help make it work without the extra textbox.
> I'd say the advantage of having multiple textboxes on display at once is to
> simplify placement of each, whereas slice collections would have to be
> guesstimated against the existing textbox on display and would be placed
> depending on screen size, which could possibly lead to misalignment at
> higher resolutions. That's not so appealing.
>
>
> Either way, games using two or more textboxes will and do exist.
> *Entrepreneur* uses textboxes to display end-of-day stats natively, which
> I prefer because I can more easily show stats via global variables, whereas
> slice collections require a bunch of strings I wouldn't want to use up in a
> single sitting, even if they're recyclable.
>
You can do this easily. Just use either the expandstring script command to
process ${V#} codes, or use the textboxtext command to simultaneously load
the text of a textbox and expand the codes, which you can then display in a
text slice.


> I'd rather have a textbox that can display an endless number of lines on a
> scroll bar than displaying two eight-line textboxes at once, but I wouldn't
> be against displaying stats in one box and a reaction text from the
> character at the same time in another. As you probably know, if I need it
> and can use it, I'll use it. And you should know by now that I'll probably
> need it. 😉
>
That's definitely a main goal of converting textboxes to a new file format.


>
> So, I hope this sheds some light on your conversation about what's being
> used and what should be used.
>
>
> In short: Menus and textboxes should coexist, menus that control the hero
> should remain, displaying two textboxes at once is preferred but
> negligible, customizing the size and position of the textbox (vertically
> and horizontally) is necessary.
>
>
> Hope that helps.
>
>
> Message: 2
> Date: Mon, 5 Jun 2017 09:06:02 -0700
> From: James Paige <Bob at hamsterrepublic.com>
> To: "ohrrpgce at lists.motherhamster.org"
>         <ohrrpgce at lists.motherhamster.org>
> Subject: Re: [Ohrrpgce] Textboxes and menus
> Message-ID:
>         <CADqBxeYZHaMpTPAXHiJK2R1m5hi94ZgLcj-HFMnn+HUcwX8hGA at mail.gm
> ail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Jun 5, 2017 at 7:39 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
> >
> >
> > On 5 June 2017 at 05:57, James Paige <Bob at hamsterrepublic.com> wrote:
> >
> >>
> >>
> >> On Sat, Jun 3, 2017 at 8:28 PM, Ralph Versteegen <teeemcee at gmail.com>
> >> wrote:
> >>
> >>> Showing a textbox and a menu at once is wonky, and I didn't understand
> >>> at all how it worked until spending 20 min reading the source, so I
> think
> >>> it's safe to say tahat very few people do.
> >>> Keypresses only affect the top-most menu, but they generally are also
> >>> interpreted by the textbox, except the textbox is not affected if the
> menu
> >>> suspends gameplay.
> >>> (Interestingly, opening a menu is the only way to suspend choicebox
> >>> cursor controls)
> >>>
> >>> So, if not suspending gameplay, pressing enter will cause both the
> >>> textbox to close and the menu to activate... unless the selected menu
> item
> >>> is one of the builtin menus, in which case the enter keypress will be
> >>> cleared when leaving the menu, so that the textbox doesn't close.
> >>>
> >>> Even worse, when showing a textbox with a choice box at the same time
> as
> >>> a menu the arrows keys affect both of them! This clearly should be
> fixed,
> >>> but I think the Enter behaviour is bad too.
> >>>
> >>> Currently you can give the menu sole focus by setting it to suspend
> >>> gameplay, and you can give the textbox focus by setting "No player
> control
> >>> of menu", although then you need to use a script to close the menu.
> >>>
> >>> Clearly to change anything we need a backcompat bit, but it's not easy
> >>> to see what to change to. I want to simplify, not make it make
> complicated.
> >>> I think we need to track whether the textbox or the menu has focus
> >>> (whichever was opened last), and maybe even (virtually) put the
> textbox in
> >>> the menu stack.
> >>> So if a menu is opened from a textbox, or a textbox from a menu, then
> it
> >>> takes focus; but we also will want a way to override that; maybe the
> 'No
> >>> controls' menu bit can be repurposed.
> >>>
> >>
> >> I agree, the current behavior is a mess, and anything it does now is
> just
> >> implementation quirks, not planned or desired behavior.
> >>
> >> I love the idea of menus or textboxes having focus. Now that you mention
> >> it, one of my forgotten plans as part of converting things to slices
> was to
> >> allow the text box layer and the menu layer to change their order so
> either
> >> one could be on top.
> >>
> >
> > Hmm. It makes sense that whatever has focus is on top (though I'm a big
> > fan of focus-follows-mouse :). And you would always override it anyway.
> >
> > If a menu or textbox is opened without taking focus, then the
> textbox/menu
> > that opened it needs a way to close it when it closes. Menus can already
> > close textboxes but not the other way around.
> >
> > Thinking about the most common case, a textbox with a menu instead of a
> > choice box, would be helpful. Of course that's another feature. (Should
> we
> > turn choiceboxes into menus? Or put a simplified menu editor in the
> textbox
> > editor (meaning it doesn't create a new menu ID in the menu editor, but
> > does create a MenuDef when you load it)? Or just add a shortcut for
> > creating a new normal menu and linking it to the textbox?)
> >
> >
> Ooh! I love the idea of choiceboxes using a simplified menu editor that
> creates a MenuDef without a menu ID.
>
> I *also* like the idea of a shortcut for creating a new menu linked to a
> textbox.
>
> I can't decide which is better...
>
>
> > If I remember correctly, my original intention for the "No player control
> >> of menus" was a somewhat ill-conceived pre-slice idea bout using menus
> as
> >> informational displays while the player was still waking around and
> acting
> >> normally. I don't know if anybody ever use that bit that way or not.
> >>
> >
> > I think it's used that way in Entrepreneur; or were all those displays
> > slices only?
> >
>
> I don't remember
>
>
> >
> >
> >> Also, maybe we should think ahead to the possible ability to have
> >>> mutliple textboxes open at once, on a stack.
> >>>
> >>
> >> That could be useful, but lets not worry about it too much until
> somebody
> >> has a game idea that needs it.
> >>
> >
> > Maybe it's difficult to come up with a situation where it would be
> > *needed*, but aren't there a number of RPGs that show two textboxes at
> > once? Just don't ask me to name any... I can't remember playing any.
> > It's hard to see how that would actually work, though.
> >
>
> Seems like a stack of multiple open textboxes would be a bit confusing.
>
> If somebody really needs that, they can already script it pretty
> painlessly, just by opening a textbox, grabbing the slice handle, and
> re-parenting it to the script layer
>
> ... we might want a command that just loads a textbox as a slice, without
> triggering any of the apparatus of textbox chaining and conditionals.
>
>
>
> >
> >
> >>
> >>
> >>> (I also think it's strange that ESC doesn't advance textbox, so would
> >>> like to add a backcompat or pref bitset for that.)
> >>>
> >>>
> >> That sounds reasonable to me :)
> >>
> >> I don't remember why I excluded ESC from doing that in the first place.
> >>
> >
> > Also, I suggest we make suspendboxadvance suspend choicebox controls too.
> > They're useless when you can't hit enter, unless you use a script to
> > advance the box instead, but that would be really weird...
> >
> >
> Yes, I think forgetting to disable choicebox controls on suspend box
> advance should probably be treated like a bug.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170606/6ac75f87/attachment-0001.htm>