Joysticks - Controller ID?

Started by
14 comments, last by irbaboon 10 years, 10 months ago

A suggestion I have is maybe somewhat farfetched, but may be easier to do than forcing the user to choose a specific controller.

If you can code it out, you can have the game player choose the buttons/axes directly. I think for this you should not have the player choose a specific joystick. Instead, have them click a button for each input "action(say jump, shoot, left, etc...) and then hit the key/button that they want to apply to that action. Then, you go through checking all the inputs waiting for something to move. Once the player hits a button(or hits a keyboard key), you set that button/key to that action, and when in the code for polling that action, you check that specific key. This way, the player never has to mess with what joystick to use. Also, they could easily in theory combine inputs from different devices, which could come in handy. I've heard of some joystick devices that actually work as different devices, like driving wheels that come with separate pedals. Windows would likely have these as separate devices, and if you limit your player to a single device at a time, they won't be able to use these devices very well.

As far as your input code, you would have to somehow identify each joystick/device. This could easily be transparent to the game player though. I assume that whatever code you are using returns some sort of handle to the devices. There is no reason you can't use that kind of thing to identify the joysticks. If you have access to the "names" of the joysticks, you could use those to identify the devices, but if not, a simple joystick 1 and joystick 2 could suffice, especially if the player is the one hitting the keys to choose inputs. Also,if you get a good backend working, it is the kind of thing you can use in future projects, as input is something that once done right doesn't have to be changed much.

I have created a sort of system for input for GameMaker. I won't give the GML code for it here, as you are not using GameMaker and it won't really work for you. The way I do it is pretty simple code wise. I have a separate program I made. You use it to create a "default" input configuration. You input how many actions your game is going to need. Actions are things like "jump," "run," "left," "right," "open," etc... Then a GUI appears for you to choose what input would be the default. In general, for defaults, you should only use the default devices that a computer has, like the keyboard or mouse, since not all game players have other devices. Then, you export a file that would be your "default" configuration. In your game, you would normally load the current configuration, and then if it has not been created yet, load the default, and then resave it as the current configuration.

My code stores the inputs in a grid data structure. It contains the device, the key(or joystick button), the current state of the input, and as extras, a couple values, for example if the key is "freshly pressed" or "freshly released" which only remain true for a single frame, and lastly a "time held" value, which is usually good for "charging" weapons, controlling jump height based on how long a button is held, etc.... Each frame, code goes through the whole grid and updates the values, polling the devices. Then, the game code itself only calls the update function. When you need to check if it is time for the player to shoot, you call code that checks action #1, assuming that #1 is the one you have set to "shoot." You could also check instead for the "freshly pressed" value instead, in order to force the player to first release the key before shooting again, which would replace your "canShoot" variables.

This type of system is very versatile, and it can be upgraded to support any device you can read in code. If you keep configurations in files, you can easily keep more than one. Also, in my case, I have code that turns the grid into a string, so that you could save to your own file format. This would be useful, for example, if instead of having a single "current" configuration, you could instead use that string to save the configuration along with player profiles, or something along that line. You'd also keep around the default configuration file, or in my case the external "default configuration creator" can also copy the string to your clipboard, which you can paste into your code, so you don't have to keep an external file for it.

Anyway, I guess I've rambled on long enough. Hopefully I have given you some ideas that you can use to create a robust input system for your games.



Advertisement

I am going to support configuring new controllers, but I still want to have preset controllers.

So that the user does not have to configure the controllers themselves. A better user experience basically.

I got an idea though, I can just have the XBOX360, Nintendo 64 and other presets in there, and when the user selects a controller, they have to specify what controller it is.

If it's a GameCube controller for example, they have to add a preset themselves, but if it's an XBOX360 controller, they can just select the 'XBOX360 preset'.

This could work out pretty well.

Anyway, thanks for your input on it, kburkhart84.
I'm not sure if you implied what I just said in your message, but I suppose this works best either way.

If you want to have presets for certain joysticks, then that is fine. The catch is is detecting for sure that the controller is that type of device, and so configuring controls. If it is a single player game, and you use a system like mine, you could simply create defaults that use the device, instead of just using the controls. My system makes no limitations on input configurations in that manner, and you can have as many files(or strings) for defaults as you want. The input configuration program also receives all inputs for devices, as it uses the same code as the run-time part. So even for my system, there is nothing that says you can't create default controls using devices other than keyboards if you wanted to.



Yeah, that's what I'm doing.

Right now you can add as many configurations as you want. The only problem is to set the presets automatically by detecting the controller.

What I'll do now is just make the user select what controller he has, and the game will then either select a preset or prompt user for a new.

Yes, the C-buttons are in fact buttons. They don't appear that way to your code because your adapter is remapping the controller data so it more closely matches the standard gamepad layout, and is thus more readily compatible with existing PC games - which it might as well, as controllers for older consoles use transfer protocols that are completely incompatible with USB, so the controller data has to be translated anyway.

So it maps A and B to buttons 2 and 3 (typically the bottom and right face buttons), L and R to the left and right triggers, Z and Start to the mid-pad face buttons (back and start on the 360 layout), and the direction pad are mapped to the standard ids for the directional buttons.

It maps the analog stick to the axes normally used for the left stick, and the C buttons to the right stick - it also likely scales the analog sitck axes, because the N64 analog stick doesn't actually use the full range of values (the controller represents each axis as a signed byte, but they are mechanically constrained to the range of -81 to 81).

Yes, the C-buttons are in fact buttons. They don't appear that way to your code because your adapter is remapping the controller data so it more closely matches the standard gamepad layout, and is thus more readily compatible with existing PC games - which it might as well, as controllers for older consoles use transfer protocols that are completely incompatible with USB, so the controller data has to be translated anyway.

So it maps A and B to buttons 2 and 3 (typically the bottom and right face buttons), L and R to the left and right triggers, Z and Start to the mid-pad face buttons (back and start on the 360 layout), and the direction pad are mapped to the standard ids for the directional buttons.

It maps the analog stick to the axes normally used for the left stick, and the C buttons to the right stick - it also likely scales the analog sitck axes, because the N64 analog stick doesn't actually use the full range of values (the controller represents each axis as a signed byte, but they are mechanically constrained to the range of -81 to 81).

Thanks for your comment!

That explained some stuff.

This topic is closed to new replies.

Advertisement