There are many great games being made out there in the classic gameplay styles of the NES and SNES era, and a great many of them would benefit so much from a control scheme so much more appropriate than the keyboard.
Of course, I'm talking about the joypad.
Now, not everybody has one for their computer (even though all you really need is a Playstation controller and a $5 USB adapter), but a game that can use a joypad just becomse so much more authentic... enjoyable... and downright playable.

Which is why it's such a shame that so few games (even the great ones) support joypad control of any kind. Sure, there are ways around (like ctrl+Y, maybe, or a program called Joy2Key), but even these aren't infallible (if ctrl+Y is disabled, and if the game uses shift as jump).

So, why don't more games support joypad control? Isn't it worth the extra effort? Or is it that difficult to implement?

Why don't I make it easy for you, then...


==========================================================
Customizable Controls and Joypad Support ( using MMF 1.5 )
==========================================================


EXTENSIONS YOU'LL NEED:
Joypad object
Control X

HELPFUL EXAMPLE FILE:
http://www.l-ames.com/logan/joypad.zip

Now, the idea here is to make two frames. The first is the control setup screen, the second is the initialization and play screen. They shall be made in a manner so that the initialization and play can occur even if the setup screen is in a separate application.

THE SETUP FRAME

First off, go to the setup screen and add enough buttons for the controls in your game, and make a little string for each one (these are to change each individual button). Be sure to arrange them so that they make sense to both you and the user. You'll also need a way to select what input device you're using (keyboard vs joypad 1 or joypad 2), and maybe a string to tell the user what's going on. Anyway, I'm sure this part doesn't warrant the explanation that I just gave it, so let's move on.

You'll need to add the Joypad object, the Control X object, an INI object, and some way to keep track of a few numbers (I favor an active object (I'll call it Active) for the case).

The theory at this point is simple. When you change the input device (from keyboard to joypad or whatever), it changes Active's value A correspondingly. When Active's flag 0 is off, the strings all change themselves to the appropriate key (through Control X if Active value A says it's keyboard input) or button, as read from the INI file. We're going to set this flag off whenever there are changes to the controls, so that it'll always stay updated. Of course, currently our INI file is empty, but that's okay.
Pressing one of the change button buttons will set Active's value B to a corresponding value and sets its flag 1 to on, meaning it's waiting for input. And the source of that input will be determined by Active's value A.

Perhaps this'd be easier to explain in a practical environment, so take a look at the first frame of the example file. When it all comes together, you can select an input device, click on any of the buttons, and input any key/button when prompted. And, of course, it's all stored for later.


THE INITIALIZATION

So, now that we've got the controls setup, how are going to get at them during the game? Well, if the control type is keyboard, you use Control X at the start of the frame to set the player controls to the appropriate keys (if you have more than 6 buttons, you can let it spill into player 2's controls. Go ahead, nobody will mind). And if your input is joypad, you set player 1's control to joypad (I'll explain later) and assign the button values to an active object that I'm calling Control-Man. I've allocated its value A to determine the control type, and am using B through I to hold the values for the buttons I'm using (8 buttons total, not counting directions, which we assume are the joypad directions).

That should be it for the initialization, so let's move on to...

THE CONTROL

Now, even though we set the player's keyboard controls to player 1 and player 2's controls, we're not going to be using that in its raw state. No, the only part of the built-in control-detection we'll be using is the directions, up down left and right. Even when we're using the joypad, we'll still use MMF's controller detection. It's a matter of safety, really; When detecting direction, it's best if you don't put any steps in between the button press and the response.

For the rest of the buttons, we're going to go through Control-Man. It's a bit of a tedious proccess, but we'll need to make two events (a press and a release) for each of the buttons for each of the control schemes. So I'm gonna tie it up in a group so it'll look nice.

What's essentially going on here is that holding a button will cause one of Control-Man's values to rise from zero (I've allocated values J through Q for this purpose). Releasing that button will bring the value back to zero. Thus, when a button is first pressed, its corresponding Control-Man value reads 1, and as it's held it reads as the hold-duration.

Hence, Button 1 pressed becomes Button_A = 1, and Repeat while Button 2 is held becomes Button_B >= 1


It should work now! Let's set up a way to test it and try it out!