Keyboard and Mouse Bindings

[PyTom]

Now that we have a number of engines (at least 5, by my count) in the original English-language visual novel community, I think it makes sense for us to at least make an attempt at standardizing the keyboard and mouse bindings available in our games. The advantage of standardizing bindings will be to make it easier for a user to sit down at a game and leverage the knowledge he has from other games to start playing immediately.

This grows out of the discussion started in this thread.

Anyway, let me start by presenting the list of key and mouse bindings present in Ren'Py 4.7.1.

Code: Select all

keymap = dict(
    # Bindings present almost everywhere, unless explicitly
    # disabled.
    rollback = [ 'K_PAGEUP', 'mousedown_4' ],
    screenshot = [ 's' ],
    toggle_fullscreen = [ 'f' ],
    toggle_music = [ 'm' ],
    game_menu = [ 'K_ESCAPE', 'mousedown_3' ],
    hide_windows = [ 'mouseup_2' ],

    # Say.
    rollforward = [ 'mousedown_5', 'K_PAGEDOWN' ],
    dismiss = [ 'mouseup_1', 'K_RETURN', 'K_SPACE', 'K_KP_ENTER' ],

    # Keymouse.
    keymouse_left = [ 'K_LEFT' ],
    keymouse_right = [ 'K_RIGHT' ],
    keymouse_up = [ 'K_UP' ],
    keymouse_down = [ 'K_DOWN' ],
    
    # Menu.
    menu_mouseselect = [ 'mouseup_1' ],
    menu_keyselect = ['K_RETURN', 'K_KP_ENTER' ],
    menu_keyup = [ 'K_UP' ],
    menu_keydown = [ 'K_DOWN' ],
    
    # Button.
    button_select = [ 'mouseup_1', 'K_RETURN', 'K_KP_ENTER' ],

    # Input.
    input_backspace = [ 'K_BACKSPACE' ],
    input_enter = [ 'K_RETURN', 'K_KP_ENTER' ],

    # Imagemap.
    imagemap_select = [ 'K_RETURN', 'K_KP_ENTER', 'mouseup_1' ],

    # Bar.
    bar_click = [ 'mouseup_1' ],

    # These keys control skipping.
    skip = [ 'K_LCTRL', 'K_RCTRL' ],
    toggle_skip = [ 'K_TAB' ],
    )

Notation: mouseup_ and mousedown_ are the appropriate mouse events, with 1 to 5 being left, center, right, wheel up, and wheel down, respectively. Keys are either given by the character they produce or a keysym... K_KP_ENTER is the enter on the keypad, which I had left out for a few releases.

Some of these bindings are obvious, and some are obviously Ren'Py specific. I gave a bit of thought to most of them, but some (Tab for toggling skipping) were the best key I could think of.

Anyway, hopefully this can serve to start a discussion. If we can achieve consensus that a binding is wrong, then I will change Ren'Py to go with the group's opinion.

[esperknight]

I'm interested in standardizing events in VN's also... never relealized some many ways different games do it. For me, when I played VN's I didn't have a third mouse button (nor a scroll wheel) so right click was to get rid of the text box. Of course most of the time, ctrl buttons were fast skip and for choices... I had to click them. But, I'd be interested in putting in a standardization I'll keep the left click as just that, a left click (I did it mostly for me so i can bug check a little quick but enough to read it). I can agree with ESC on the menu 'cept Jon says to do right click, then left click to get in, then right click to get out (which I'm used to right click canceling things other than menus). Otherwise, I have no clue about the rest I wouldn't mind going along with ease of use though

Doug

Reverse engineering is the sincerest form of flattery. -- Engineers' saying in Silicon Valley (Rick Cook)

[papillon]

Does your skip function skip only read messages? I think that that's an important feature for an engine to have. (And "readness" usually persists across sessions.)

This is something I haven't done at the moment. Instead, I've implemented various break points where even if you are in skip-mode, the skip will stop. Usually this is because time or place have changed (finished an activity and gone back to the dorm, or gone to bed and woke up the next morning)

This form of skipping is handiest for me personally testing things, since just because I've read everything doesn't mean I want it *all* to pass in a featureless blur... I need to get my bearings now and then to get to the point I'm trying to check.

I can look into setting it to skip only previously read text, but I'll need to leave the breakpoints in for my sanity's sake. If people associate skipping with 'read' and stop-skipping with 'unread', will they be confused if the skip stops even though they HAVE seen that text before?

Ren'Py does support using icons for doing things like skipping and hiding the screen, but I haven't given a good example of how to use them in practice. I think it's because I'm a text/keyboard oriented kind of guy.

Whereas my main tester was so irked about having to find his keyboard again to navigate the mapscreen that he made me rewrite it to be fully mouse-controlled. (For those who remember the early demo - the spacebar-to-enter will still work, but the instructions now tell you to double-click on the building instead).

Adding a bunch of keyboard versions of the controls I already have isn't a problem except in that it will make documentation longer (and probably need to be HIDDEN in the documentation so as not to confuse people. Long lists of controls upset casual gamers a lot more than they help - mouse control is considered king, or so I hear on the business boards.)

The one thing I can't currently do that some engines can is "back up". I can't show previously displayed text, I don't have it stored in a method that would allow that. Is this an important enough feature in people's minds that I should look into it?

[Grey]

One of the problems with Flash is that I don't get any mouse events to play with other than just main click, so it has to be keyboard controls to hide and show the text (H/S both do this.)

CTRL is skip through (though implementing a previously read stop-skipping would probably be a pain to code.)

To advance text, or accept options you can use Enter, Space, Z and all the arrow keys (though it does feel a bit odd to be moving forward by pressing the left and up keys)

To cancel something its X and backspace (can't remember if that bit is in Kasukas engine, but its in the newer version of it, which I'm using for my NaNoRenO project)

Theoretically I could implement readback in future versions of my engine if people think it's important...I don't think I should try this month, since I should be storywriting

I could implement the F-fullscreen and M-music/sounds shortcuts easily enough if people think its worth it.

[Yang Sei Fu]

Since I had a part in designing (concepts) the Paths system, allow me explain a little.

Paths was designed straight-out from the Japanese industry standard - a GUI interface that can be fully operated on both keyboard and mouse, and simple to use.

Mouse keys are defined as left, right, upwheel, downwheel, and clickwheel.
Usual keyboard keys used are the CTRL keys, enter, space and esc. Sometimes in older games F1 may be used for help. That's it.

I currently have no intentions of using standard alpha-numerical characters for engine operation. This is too dangerous for the standard user to do (who knows what crazy things might happen if someone crashes a ball onto a bunch of keys).

"Complexity by Clarity."
If there is anything about the Paths engine, it's the simple, yet advanced layout as per 2002~2004 J-Bishoujo game standards. We hope to continually follow innovative ideas of new game engines, but first things first.

[chronoluminaire]

I'd advocate letting the user do the fundamental action, advance from one paragraph of text to the next, with as many different keys as possible. Let the right and down arrow keys, space, return, enter, page-down and left-click all do that. This is complicated by the question of what to do in readback (which ideally should be accessible by each of page-up, backspace, left arrow and up arrow). I don't have a clear answer to that.

Tab to hide text and Esc for menu feel natural. I'd say right-click should probably be hide text rather than menu, but don't feel too strongly about it.

[PyTom]

Ren'Py games should be playable with only a keyboard or only a mouse, although some features (skipping) are currently only available with the keyboard. I should probably fix that in the next release.

I also need to consider how these games will work on other platforms, especially now that a mac port of Ren'Py seems like something I'll eventually want to do.

The f=fullscreen shortcut is needed if the game is to default to fullscreen status. On certain platforms (VMWare-emulated windows machines), the mouse does not work when the system is in fullscreen mode. So we need a keyboard based approach to toggling things out of fullscreen mode.

m=toggle music is actually a leftover from the days before Ren'Py had a preferences interface. I wouldn't recommend it for new games, but it don't think it hurts anything.

s=screenshot is an easter egg in Ren'Py, basically. It's there to help me with game publicity.

I think you do need to assign keys that are used for menu access (up and down arrow keys), and for paging back and forth through the game history. (I picked pageup and pagedown for this.) Game history is something that every modern game has, and it really is useful. (For example, in the case that you double-click.)

I don't know if there are actually any Japanese game standards to speak of. In general, each engine that I've used has its own minor idiosyncrasies. The most notable difference is the behavior of the space bar. Half the time it advances the game, and half the time it hides the various windows on the screen... IMO, the former is a far more useful behavior for such a large and easy to hit key.

Sure, there are de-facto standards... and I think that's what we're trying to do here, to develop de-facto standards for our games.

[papillon]

Okay, adding stuff in:

f toggles window/fullscreen (although with my setup you will almost always want window)
m toggles sound

up_arrow/page_up moves us into the backlog - from this point, hitting space or enter will jump back to the 'current' display.
down_arrow/page_down moves the other way through the backlog

GM doesn't inherently support the mouse wheel. I don't know why. It may be possible to hack in support for it using a dll; I might to it eventually.

My primary tester votes no on skipping only previously-read text, and it will cause me headaches (not to code, but on keeping track of distribution files) so for the moment I'm not doing it.

[chronoluminaire]

I think you do need to assign keys that are used for menu access (up and down arrow keys), and for paging back and forth through the game history. (I picked pageup and pagedown for this.) Game history is something that every modern game has, and it really is useful. (For example, in the case that you double-click.)

I don't disagree with any of this; but nonetheless, I think these keys should all do the obvious things during normal reading as well. If there's no menu displayed, then up should readback and down should advance; and if we're not in readback, then pagedown should advance. Let the user do what they want to avoid irritating them.

[Grey]

OK, minimal storywriting in my free time today in persuit of readback. My engine can now display previously read text.

I'm also experimenting with getting the Pascal shell to pass knowledge of which mouse button, or scrollwheel direction has been pressed over to the Flash movie.

I am not distracting myself from writing story with interesting programming challenges

[PyTom]

I think these keys should all do the obvious things during normal reading as well. If there's no menu displayed, then up should readback and down should advance; and if we're not in readback, then pagedown should advance. Let the user do what they want to avoid irritating them.

Hm... I think the normal advance key should work in readback, but I question if the readback advance key should work in normal. I think there should be a way to trivially catch the user back up to where he was, without accidentially showing him something new.

[chronoluminaire]

I agree that there should be a way to skip straight to the furthest read text / the point from where readback started. I was thinking that left mouse button would serve this role. I'm not that fussed about precisely what it is really; I just want as many people as possible to be able to play my games easily using whatever comes most naturally to them. Of course, we're not going to be able to reach that state for everyone, but for as long as adding extra understood meanings to keys moves towards that goal, I think it's a good thing

[papillon]

I've set mine so that any of the 'standard' advancement methods - space, enter, or left click on text - will jump immediately out of backlog and to the 'current' display.

Since I already have three standard advance keys, I think the user should be able to find SOMETHING they're happy with without making the log-reading keys do different things outside of the log.