okay, let me try it out, and I’ll get back to you with the result.
Edit: so the problem I,am having is I,m using a laptop and thus there is a long palmrest (that blocks my palm movements) just before the keyboard, thus making the use of my thumb difficult, also I may have over exaggerated the use of the camera while moving as I was only moving the camera when I needed it.
Thus I was able to move my hand comfortably, between your camera layout and a layout of laying my pinky, ring finger, and middle finger between the ASD keys and keeping my index on the spacebar.
If you looking at that layout, then you would see that I had to reach pretty far to reach the “Q” key, so what about this, move your AWSD layout one key towards the right so it would be SEDF? that way the “A” can be used in place of the “Q”.
Edit2: replying to your keyboard solution, they are suggesting replacing the keyboard with a “anit-ghosting” model, my keyboard is integrated, heheh, yep the nature of apple products, so my bad heh heh heh.
Edit3: well, what if it is not a one size fits all kind of deal, since not all keyboards are the same, maybe adding a feature where the player can edit a special text file to configure the controls would be a better option.
You can do that, but be warned that some users may find it unexpected and thus awkward; I feel that WASD is very much standard these days. If the spacebar is a serious problem, then I suggest finding a replacement key for that, instead.
Hmm… Here’s a thought: what about using WASD to control movement, the mouse to control the camera, and the mouse-buttons to control spinning and “Twirl Diving”?
Or, if camera-changes are fairly rare, and not required mid-action, perhaps put them on the arrow-keys, movement on WASD, and some other pair of buttons on the right-hand side of the keyboard for your two actions?
Indeed, I think that it’s generally a good idea to offer rebindable keys!
By the way, if you want a GUI-based key-binding UI, I’ve made available for public use my KeyMapper module. Note that it is very much “use at your own risk”!
Question, if the key mapper is a module, then I would simply import into my script right? also if this is the case, when it comes time to distribute the game, how would it include into the wheel?
Edit: on your response about the AWSD suggestion, I get that, and like that it feels more “consolely” however, the directional keys are best suited for movement for my case because it is the first thing the player is going to go for when considering how to move, also, my laptop kinda lacks a mouse and individual buttons…
Pretty much. Take a look at the example game to see how it’s used, but the basic idea is this:
Place the KeyMapper file in your project directory
Import into the relevant part or parts of your project
(I don’t install it to some official place on your system–it’s just a “download and add to your project directory” module.)
I believe that the build system should pick it up automatically–it’s just another Python file, really.
I wouldn’t say that it feels more “consoley” to me–WASD is as standard PC control-scheme, I believe.
If your intended audience are gamers, then I’d expect them to go for WASD first. That said, if your intended audience are not gamers, or are console gamers newly switching to PC, then yes, they might go for the arrow keys first indeed.
(But then, if they’re not expecting WASD to do anything, then they might be confused as to how to operate the camera. And if you’re teaching them how to use the left-hand side of the keyboard to control that, then it’s a small step to teaching them to use it for movement, it seems to me.)
oh, okay, right, thanks I’ll check out your mapper then, sorry my PC gaming experience is limited, hahaha, right, funny enough I have actual code in my game already implemented from before it’s released that actually displayed the camera keys onscreen at all times, however time ran short and I wanted the get the game out there.
I already see the push to get it out there, but configurable controls throws a monkey wrench at this, I might have the take a look your mapper’s code to see if it is possible to add onscreen key directions.
Sorry, I typed that last comment out a little quickly, what I should have said was, how would I grab a key character from one that is binded from your key mapper? for example lets say someone used your key mapper to assign “S” to spin.
So in my onscreen game HUD I want “S” to show up with “Spin” next to it because of that, how would the key mapper communicate that to my main script? or at least send “S” back to the script so I can place that letter into a panda text node for it to show up on the on-screen HUD.
If I’m reading you correctly, then that’s what’s being done in the snippet that I gave in my previous post.
Simply put, given a button-name (that is, what you refer to the control as internally, regardless of what key it’s bound to), you can get the raw binding simply by getting the key-binding object from the KeyMapper’s “keyBindings” dictionary, and accessing its “binding” variable.
That gets a raw name, which might be fine, or might look a little technical, depending on what input it came from.
However, KeyMapper also defines a method called “getBindingName”, which is intended to get a more user-friendly name, as I recall. The default implementation is really basic–I don’t think that it handles much more than identifying axis-directions for inputs like gamepad thumb-sticks. But you can override this with your own implementation–or just stick with the raw input-name.
So would “getBindingName” retrieve key character? and Imagine this can all be done from my script’s end right? and the snippets you give me, are they from your code? I ask this because I,m not familiar with your code.
Are there different objects in your code assigned to each mapped key, how would “getBindingName” be used? I imagine it would be “self.object.getBindingName()” but to what object would it be used on? sorry for too many questions, and thanks for your help
It’s not too many questions, and it’s my pleasure.
Not really–they’re just examples, intended to be interpreted as appropriate to your code.
Technically, the name of the input. So if you were to bind a gamepad thumbstick, you might get something like “Axis.left_y”, I think. However, in the case of keyboard-keys, you should just get the name of the key, if I recall correctly.
Yup!
That depends on what you mean by “each key”: are you referring to keyboard keys, or the controls for your game?
That is, do you mean for example the keyboard key “S”, or the game-control “move camera down”?
I might well have variables holding the names of my game-controls. I could just use text-strings whenever I want to reference them, but accessing them via a variable is a bit less error-prone, I think.
The object would be an instance of KeyMapper.
In short, you call it from your KeyMapper object, passing in the binding (as retrieved from KeyMapper’s bindings, as shown in my previous post) and some axis-information (as retrieved from KeyMapper, and shown in my post before my previous one).
I suggest that you look at “KeyMapperTester.py”, which should come with KeyMapper–that should demonstrate basic usage of KeyMapper.
No–“twirl” is just a string there, it doesn’t have a “getBindingName” method.
Let’s say that you made a KeyMapper object, kept a reference to it in a variable named “self.keyMapperObj”, and wanted the binding for the control named “twirl”. You might then call something like this:
rawBinding = self.keyMapperObj.keyBindings["twirl"].binding
# Let's skip over the axis business for now...
bindingText = self.keyMapperObj.getBindingName(rawBinding, 0)
Yeah, I was looking at your example and it seems I need to create all new lines for each action wrapped around a key mapper object each, that way they become objects in of themselves for the key mapper to use.
With that being said, I think I,m ready to attempt this, but before that, I,m curious to know what you meant by “use at your own risk”, other than assuming it might crash the program are their other issues? would this damage my script, computer, OS, etc?
Hmm… That doesn’t sound quite right, to me. In basic usage, there’s only one KeyMapper object. You do, however, call a method (“addKey”) on the KeyMapper object once for each control.
I hope that it won’t do any such!
However, this isn’t something that’s gone through rigorous quality assurance, I don’t have the means to fight legal battles if something does go wrong, and I’m making no guarantees that I’ll offer support or updates. It’s just a module that I made for my own use, and that I’m making available for others to use, for free.
Thus I’m saying, roughly speaking: use it if it might be useful to you, but go in knowing that it’s up to you to be vigilant against any issues that may arise, and that I’m not in much of a position to take legal responsibility against the possibility of issues arising.
In short, it’s a disclaimer.
(You’ll probably find similar statements in licenses for other free works, I imagine.)
So after some work, I attempted to run it and it was missing the “SaveLoadDummy” module, but I found it in your github, so I copy pasted it into a py file, but then this module reports it is missing “GameSaver”
What is that? I didn’t see it any where in your github.
As I said above, KeyMapper doesn’t handle saving and loading for you. GameSaver is my own general-purpose saving module–however, at the moment I don’t intend to put that up on GitHub. Thus it falls to you to replace the “dummy” code in “SaveLoadDummy” with code of your own, whether to save- and load- keybindings, or to silently not do so.
(I might remove the reference to GameSaver in the GitHub code, come to think of it.)
[edit] Ah, looking at that code, I see that I have it importing GameSaver–sorry about that! It’s likely a holdover from my own code, which does use the GameSaver module. You should be able to safely delete that import-line, I believe. I’ve done so in the GitHub code, at least!
Ah, I see. In short, you don’t need the “True” bit: KeyMapper handles that for you. (Without looking at your code I’m guessing slightly, but if my guess is accurate then you likely don’t need the “self.satKey” bit, either.)
Note that we just pass in the control-name (“twirl”), not the full pair of parameters that you were having passed to “satKey”.
To explain: If I’m guessing correctly, “satKey” managed a dictionary of key-states–that is, when a key was pressed, the corresponding dictionary-entry was set to “True”, and when a key was released, the corresponding dictionary-entry was set to “False”. You then checked those dictionary-values elsewhere in your code in order to control your character.
KeyMapper does something similar–but all the “setting things to True or False” business is done in the background for you. You tell it what keys you want it to manage, and then check their states in your code as you usually would.
Thanks for clarifying, sorry, I should have been more clear to mention that it uses the same “satKey” setup as the roaming ralph demo, but if your code is automatic I’ll have to change more of my code, I don’t know, it may even break the game.
As there are more subtle events that use them as well as the character movements, however I can try to employ a “Middle Man” system where it can take your key presses and transform them into satKey responses, I,m going to try that first.
