• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Diventurer

Joysticks - Controller ID?

15 posts in this topic

Hello! This is a bit long thread about a little issue I've encountered.

 

Yesterday I started looking at joysticks, and how to use them in my games. I found this to be fairly easy. I made an input system so I could register new controllers fairly easy. However, a problem has come up!

 

In the settings in my game, you get a list of all controllers connected to your computer. So you basically just choose one, and you can play with that controller.

 

Right now, I have configured an XBOX360 controller and an Nintendo 64 controller. After adding the N64, I realised the problem.

I needed to know which controller was which. So I added an "id" property to my joystick class. The game would then set an "id" to each controller, so it would know which action to do. 

 

The code to add an input looks like this, pseudocodeishly:

int ACTION_PAUSE = joystick->add_input();
joystick->add_trigger(ACTION_PAUSE, new button_press(XBOX360_BUTTON_START, CONTROLLER_XBOX360, input_state::pressed));
joystick->add_trigger(ACTION_PAUSE, new button_press(N64_BUTTON_START, CONTROLLER_N64, input_state::pressed));
joystick->add_trigger(ACTION_PAUSE, new key_press(key_return, input_state::pressed));

So it's all fine, until I realise I have to actually idenfity the controller.

What I thought first I could do was

joystick->open(controller_index, CONTROLLER_XBOX360);

Then I realised... I have no idea which controller is which.

 

I know I can call SDL_JoystickName for the name of the controller, but the Nintendo 64 controller, which I can use through an adapter, names the controller for "USB Controller". I have two of those, as there are two ports in the adapter. So what if I get, let's say, a GC adapter, and use a GC controller. Then I get possibly another "USB Controller" name. So I can't just use that name to identify the controller.

Also, I noticed that an XBOX360 controller of a friend of mine was a special one with a unique name. So I can't even see which is which of the same type.

 

So I'm wondering if there is a way to figure it out?

I thought of making a function that checks how many buttons, axes, hats and balls the controller has - but what if it's a special-made N64 controller? I saw one online that had special buttons on it. Regardless of that, it's a stupid idea anyway, lol.

 

So yeah, any thoughts?

 

Thanks in advance.

0

Share this post


Link to post
Share on other sites
Well, I would probably have the game do the best it can to map input based on the number of buttons and the name of the device name but then allow the user to customize the input. You could try to have a good layout for the most common input devices but you will never be able to have the perfect layout for all input devices because new devices hit the market all the time.
1

Share this post


Link to post
Share on other sites

Yeah, I know.

I guess I can try to make a function that tries its best to recognise a controller by its name and amount of buttons.

 

However, it would be so much better if there is some sort of signature in the controller...

 

I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.

Is there a logical explanation for this? The B button has ID 2, and then the left shoulder button comes next at ID 6.

0

Share this post


Link to post
Share on other sites


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.
Is there a logical explanation for this? The B button has ID 2, and then the left shoulder button comes next at ID 6.

Is the D-pad mapped to the 4 missing buttons?

1

Share this post


Link to post
Share on other sites

 


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.
Is there a logical explanation for this? The B button has ID 2, and then the left shoulder button comes next at ID 6.

Is the D-pad mapped to the 4 missing buttons?

 

There are 6 missing buttons in total.

The D-pad is button 12, 13, 14 and 15. It's also a hat which has the dpad sum.

 

Here's the list of the IDs I have figured out:

// Buttons
static const int N64_BUTTON_A          = 1;
static const int N64_BUTTON_B          = 2;
static const int N64_BUTTON_LEFT       = 6;
static const int N64_BUTTON_RIGHT      = 7;
static const int N64_BUTTON_Z          = 8;
static const int N64_BUTTON_START      = 9;
static const int N64_BUTTON_DPAD_UP    = 12;
static const int N64_BUTTON_DPAD_RIGHT = 13;
static const int N64_BUTTON_DPAD_DOWN  = 14;
static const int N64_BUTTON_DPAD_LEFT  = 15;
// Axes
static const int N64_AXIS_X            = 0;
static const int N64_AXIS_Y            = 1;
static const int N64_AXIS_C_VERTICAL   = 2;
static const int N64_AXIS_C_HORIZONTAL = 3;
// Hats
static const int N64_HAT_DPAD          = 0;
Edited by diventurer
0

Share this post


Link to post
Share on other sites

Did they leave extra space for the attachments (rumblepack and such) that fit in the bottom of the controller?

The memory card I had for mine had a "Page up" and "page down" button for the four pages/memory-blocks of the card. I also had another card that had a four-position slider.

Edited by Servant of the Lord
0

Share this post


Link to post
Share on other sites


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.

You must have a non-standard controller. The stock n64 controller has:

 

- a start button

- an A button

- a B button

- a central trigger

- 4 directional buttons

- 2 shoulder buttons

- a 4-way D-pad

 

For a total of 14 buttons.

 

Additionally, some controllers have Turbo and Slow buttons, which brings you up to 16.

0

Share this post


Link to post
Share on other sites

 


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.

You must have a non-standard controller. The stock n64 controller has:

 

- a start button

- an A button

- a B button

- a central trigger

- 4 directional buttons

- 2 shoulder buttons

- a 4-way D-pad

 

For a total of 14 buttons.

 

Additionally, some controllers have Turbo and Slow buttons, which brings you up to 16.

 

I have a normal N64 controller.

 

What's a "central trigger"? I don't have anything like that...

Also, the 4 C buttons doesn't work as buttons for me, I can only use the axes.

 

I guess it'd make sense what you explain though. Are you 100% certain the C buttons are buttons?

 

 

Did they leave extra space for the attachments (rumblepack and such) that fit in the bottom of the controller?

The memory card I had for mine had a "Page up" and "page down" button for the four pages/memory-blocks of the card. I also had another card that had a four-position slider.

I suppose what you and swiftcoder says about that might be correct. As I explain above, it still doesn't quite make sense for my controller though...

Edited by diventurer
0

Share this post


Link to post
Share on other sites

Or maybe this controller explains it? If the C-pad are axes instead of buttons, I count 16 there. Though that's not actually plugged into an N64, so maybe not. This implies that the C-pad are actually buttons, and that there are two unused spaces (that is, two spaces that the author of the article left blank, so maybe they are used but he just didn't know about it).

 

 

1

Share this post


Link to post
Share on other sites

I suppose the LodgeNet controller could explain it. Maybe Nintendo made support for 16 buttons on the original controller to make the LodgeNet controller easier to make. I don't know, is it a modified Nintendo 64 or just a TV that can play N64 games... I got a bit confused.

 

Anyway, the link you sent me doesn't really say the C-pad buttons are 'buttons', or am I missing something?

Even if they were, it's still not a better explanation than the LodgeNet controller, as that has 16 buttons in total.

0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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.
1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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).
1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0