Greetings and salutations!
For this week's screenshot, one more look at the key-mapper testing-game that I've been working on; this shows a new player-ability that's been added to the game, as well as the final boss:
Most of the work of the week just past was technical in nature, focussed once again on upgrading the key-mapper to support Panda3D's new input-device handling:
To start with, something (slightly) aside from that: I polished (and have just about finished) the key-mapper-testing minigame that I showed last week, and which is shown in the screenshot above.
As part of this, I added one more feature to the game: the player can now press a button to emit a burst of power, shoving away enemies and destroying all projectiles.
It's not without cost to the player, however: using it removes a quarter of the player's health at the time. This means that it will never remove all remaining health--it's always safe to use in and of itself--but overuse can leave the player vulnerable...
And in terms of key-mapping, it gives the game an "activate on button-press" control to test.
On the technical side, I continued to work on the functionality of the key-mapper, including the polling of axial-inputs; keeping proper track of the axes in use, and of what controls they're bound to; and saving- and loading axial inputs.
This work proved quite difficult, I'll confess. (Perhaps in part because I was rather short on sleep over the week just past.)
Still, I think it's almost entirely done: to the best of my knowledge--and presuming that nothing comes up in testing--I have only one more minor feature to implement! ^_^
One feature that I'm quite happy with is that, in addition to the usual axis-polling, axial inputs can be used as button-presses, calling press- and release- callbacks just like key-press events.
In all fairness, this is done via the standard polling interface, meaning that a sufficiently quick press or a sufficiently low frame-rate could result in such an input being missed. However, under most modern conditions I think that it should be fine, and it broadens the options available to players.
I also did a little work intended to make the key-mapper module more friendly to other devs.
One such change that's perhaps worth mentioning here is that the key-mapper no longer assumes the use of my game-saving module. Instead, it now requires that devs provide their own file-saving methods, allowing them to approach the matter as they prefer. Conversely, however, I provide a separate convenience-script that implements saving and loading via my game-saving class, for both my own use and that of any others who might wish to use it.
On the non-technical side, I also did a bit of cleanup and documentation regarding the key-mapper module.
And finally, I removed my old key-mapper example-game. While I did like it, and it had its charms, it also had some elements that might have called for more work given the key-mapper's new functionality. On top of that, its files were largely included in the base key-mapper directory, cluttering the place somewhat.
That then is all for this week--stay well, and thank you for reading! ^_^
