Just a quick plea to all project boost designers: I love your games, but please, please, PLEASE don’t do the default controls. They work fine for most people, but I, along with around 10% of population, am left-handed, and it’s extremely awkward for me to use these controls. At least give a choice of keys to use on both sides of the keyboard, or just do a set of keys in one place (such as W for thrust and A/D for rotation), otherwise 10% of people all over the world will say “well, frak this, I’m not twisting my arms to play this thing”.
1 Like
You mean you are not willing to just turn the keyboard upside down Maciej? Outrageous! 
You raise a very good point, a similar issue arises in Terminal Hacker, as by default the keypad numbers aren’t accepted for entry, they are just ignored.
Configuration options haven’t been covered by this part of the course yet, but it wouldn’t be too much of a stretch for it to be implemented, even with just a simple right hand / left hand option which perhaps either uses WASD and the arrow keys accordingly.
Why don’t you pop up your solution to providing configuration in the game for others to see 
Great idea! Here is my solution.
First, for the thrust input:
private void RespondToThrustInput() {
if (Input.GetKey(KeyCode.Space) || Input.GetKey(KeyCode.UpArrow)) {
ApplyThrust();
} //and the rest of the code
}
Second, for rotation input:
private void RespondToRotateInput() {
//blah blah blah
if (Input.GetKey(KeyCode.A) || Input.GetKey(KeyCode.LeftArrow)) {
//rotate left
} else if (Input.GetKey(KeyCode.D) || Input.GetKey(KeyCode.RightArrow)) {
//rotate right
}
//blah blah blah code code code
}
2 Likes
Very nice.
Another option may be to use the cross platform input functionality, you could then refer to both the space bar being pressed, or the up arrow being pressed as “Vertical”, and for rotation just “Horizontal”, thus you wouldn’t need to hard code the keys directly into your code, or, provide an endless list of options in your if statement.
From memory, this is introduced in Argon Assault (Lecture 84 - Using Cross Platform Input), so it’s coming up soon and you could always go back to Project Boost and implement it to see what you think, whether its easier/better than the coded approach.
One advantage of using it would be that you could provided a configuration screen to the player where they can set the keys, for example, I might be one of those kind of people that wants to use my right hand, but for the IJKL characters. Having a customisable options scene that allows me to enter whatever keys I want would be great, you then support everyone (everyone with fingers at least) and all you do in the background is map their key selection to “Vertical” or “Horizontal” etc.
Hope this is of use 
One note on using the CrossPlatformInputManager: The ‘gravity’ and ‘sensitivity’ give these inputs a fall-off and a ramp-up (respectively). To be more explicit, allow me to compare a couple cases:
- You use GetKey for rotation of the player vessel; result: instant-on (value is either 1 or 0) and instant-off.
- You use CPIM for rotation; result: depending on settings, it will take X (sensitivity) amount of time for the value to go from 0 to 1, and X (gravity) amount of time to go back to zero from 1.
- You can have CPIM be extremely sensitive with very high gravity and it would theoretically take only 1 frame to toggle (I don’t know what values, off-hand, would be needed for those results).
Personally, I’ve made use of the ramp-up/fall-off effect of CPIM in several games now, to give the keyboard play more of an analog controller feel in-game. I can understand why Ben doesn’t want to officially cover it just yet; for many students they will have barely finished Terminal Hacker, and getting into CPIM is not required; it would certainly cause mass confusion with some of the fresher students, thanks in part to the cludgy way of accessing and changing the settings.
1 Like