Greetings and salutations!
This week's screenshot shows further progress in non-mouse navigation: on from the menus to the minigames!
The week just past was another busy one, I feel! Once again, most of the work went into non-mouse navigation, with a few tangents and digressions along the way:
The navigation system itself saw a number of tweaks and upgrades in the week just past:
When a movement-control is held down, the related navigation-action is repeated. That is, holding the "up" button results in the selection of the UI-element above the current one, and a moment later the one above that, and so on.
However, the system should now also respond pretty much immediately to an initial press of the relevant button, regardless of the repetition delay. Thus a series of key-presses results in navigation at the rate of those presses, while a held key navigates at a steady speed. This should, I hope, result in navigation feeling responsive and flexible, while nevertheless not moving too quickly.
Speaking of which, the speed of that held-key repetition can now be altered via the options menu.
When navigating a menu-screen, the system will now skip over disabled UI-elements (unless it has been instructed to navigate specific UI-elements anyway), moving to the next enabled control (if any). This means that disabled controls no longer stop navigation.
There is an argument against this behaviour, I'll confess: if a control is initially disabled, skipping over it might imply to players that the control is never available for navigation. Hopefully, however, the visual change in a control becoming enabled will be enough to make it unsurprising that said control also becomes navigable!
As to menu-specific implementations, the navigation-logic of the game-menus themselves is pretty much done, I believe. With that so, I moved on to the navigation of the various minigames found in A Door to the Mists.
If I recall correctly, I decided to start with the jigsaw-puzzle minigame, reasoning that it was likely to be the simplest of the lot.
Conceptually, it's straightforward: the player selects a puzzle-piece, moves it around, rotates it, and puts it down. Repeat until the pieces are correctly arranged, or the player gives up.
But there are some complications, as it turns out:
To start with, how does one select a given piece? They're initially arranged somewhat arbitrarily, and the player can drop them more or less freely. Thus they don't have static positions relative to each other.
I considered implementing automatic layout-generation. However, I fear that there are cases in which navigation would be unintuitive, or in which multiple pieces would be candidates for a single navigation-direction.
In the end, I settled on just cycling through the pieces, using either the "forward" movement-button, or the "next-" and "previous-" tab-selection buttons.
Next is the issue of how one rotates the pieces.
With a gamepad (or keyboard-only play), this is easy enough: the movement controls move the current piece, and the "looking" controls rotate it.
But as I had it, with a keyboard-and-mouse layout the mouse controlled the movement of the current piece--and the movement controls rotated it. I could have used the "looking" controls in this case, too--but they aren't necessarily assigned in this case.
Here the decision was somewhat tricky. I didn't see a set of controls that I could presume to be set in a keyboard-and-mouse layout that also made for intuitive rotation controls. I eventually settled on using the "jump" and "crouch" keys. Not wonderfully intuitive, perhaps, but workable, I think.
I'm not happy with making the default control-scheme worse, but I don't see a better solution here, I fear. :/
With that done, the next minigame attended to, as I recall, was lockpicking. This actually went relatively smoothly--a workaround was employed at one point, but otherwise this proved rather easier than the jigsaw minigame, I believe!
(I'll confess that it doesn't work very well when playing with keyboard alone--four keys lack the nuance of either a thumbstick or a mouse. :/)
Last dealt with, and still a work-in-progress as I write this, was the translation minigame.
The layout of this is particularly complex: it has a grid of buttons near the bottom, and above that another grid. Each cell of the latter contains a vertical column of buttons below a horizontal row. Worse, I recall that at least one of these grids turned out to be ordered in an inconvenient manner.
Still, progress has been made--indeed, I think that it's near-done! ^_^
On a game-design note, I've made the decision to remove the ideogram minigame. A few points brought me to this decision: For one, I'm seeing little space for it between its first use in the prologue and its uses much later in the game. For another, it quite closely resembles the translation minigame. And for a third, I'm not confident that it works all that well as a puzzle.
It is a pity: the ideogram minigame is a little unusual, and I do quite like it. But so it goes.
And along the way I made a number of changes and fixes that don't seem worth mentioning here!
Finally, I think that I've mentioned that I'm working on a little side-game, a "wandering visual novel". That too, has made progress, both on the game itself and on related tools. Here's a brief look at a new character-action--to start with, a depiction of one of the hazards of being incautious with scaling; after that, the corrected version, now with a bit of "stretch-and-squish":
That then is all for this week--stay well, and thank you for reading! ^_^