Summary:
In which a WIP main-menu for a side-game is shown; the tutorial continues to take time; and key-mapping complexities for A Door to the Mists are contemplated.
Greetings and salutations!
The week just past was once again taken up by my "Panda3D Beginner's Tutorial", so once again A Door to the Mists remains on hiatus. Having no screenshot for it, let me instead share an image from a side-game that I've been developing during off-hours. It's a short "ghost corridor" of sorts; a set of little spooky set-pieces for the player to encounter. It's titled "Night River", and this is the work-in-progress main menu for it:
As I said, the week just past was taken up by work on my tutorial. I'm making progress, I believe--I'm partway through the writing process at the moment--but it's proving to be a much bigger task than I had anticipated!
Indeed, I've already written nearly as many lessons as I had originally planned--but I'm only about halfway through the set of lesson-programs that I had set out.
Still, I'm hoping that the pace of things will speed up a bit: much of the expansion of the tutorial came from discovering that some of the most fundamental elements of Panda3D seemed to call for more explanation than I'd realised. In addition, some of the upcoming lessons may be less Panda-related than the early ones, and can perhaps be somewhat skimmed over. We'll see!
With all that said, A Door to the Mists hasn't been forgotten. Indeed, with Panda3D having recently added support for gamepads (and other input-devices, I think), I've been giving thought to how I might handle support for those.
There's nothing terribly complicated about any one input system, I think. The complexity lies in unifying them, and upgrading my keymapping-module to handle them in a manner that's elegant and convenient for both me as a developer and for players interacting with its UI.
For example, right now A Door to the Mists uses button input for movement: the player presses the button assigned to "step left", an event is called, a flag is set, and when the player-character is updated, its movement code checks that flag and responds accordingly.
But a gamepad thumb-stick doesn't generate events in that way. Instead, one is expected to poll an axis.
I don't want to complicate my player-code by including multiple approaches to handling input. Instead, I want my keymapper-module to present a unified interface, so that the player-code can just query it and respond.
And then there's the player-end of it: how should this be presented to the player? Should there be different key-mappings presented depending on which input-method is selected? Should I allow players to mix-and-match input-methods as they like? And so on.
I have things to think about here, I feel.
That then is all for this week--stay well, and thank you for reading! ^_^
