It is unclear to me if you support directional or not. If you have up, down, left, right and two buttons… That's six buttons!
I'll assume you don't have six buttons like that. Just two.
Let us not pretend that you would have to adapt to the limitation of this two button engine. If you play it to its strength then you would pick auto-runners, auto-battlers (see "Menus" below) or rail shooter games. And of course rhythm games.
Also know that with only two buttons, the impact of speed to difficulty is going to be large. Thus, the game might need to be slower than expected for the same difficulty.
And no, I'm not claiming these are every posible two button input scheme. But the approaches I describe here should - at least - help with any game genre.
Well, you need are four commands (five with "do nothing", which will let press nothing be): "Next option", "Prior option", "Enter" and "Exit". And you have a hierarchy of menus.
In fact, actually, you only need three: "Next option", "Enter", "Exit". And have the options loop.
We can do better:
- Next option
- Do option
- Change menu
So you would have a menu of menus that you go to when you use "Change menu". From there you can select which menu you want to use. Once inside a menu, you operate with "Next option" and "Do option". And you use "Change menu" when you want to go to another menu.
I would make "Change menu" be holding both buttons. Then "Next option" and "Do option" can be each a button. Or if you prefer to have "Next option" and "Prior option" each be a button. Then "Do option" can be holding one button.
And then build your game control scheme around that. This approach would fit well with visual novels, quiz games, or with menu based RPG combat. Also board games, card games, idle games, element combination games, and good chunk of puzzle games can also be menu based. And text adventures could be adapted by providing a menu of the valid options (see also "typing" below).
I want you to frame in your mind all the control schemes here as menus. They are special menus. And there are ways to change menus. So, if there is some special game mechanic I didn't think of… Make it another menu! A Tetris piece falling? That's a menu!
By the way, there is a proper name for this: input modes. But I'll call them menus for this answer.
Strategy game and such
Let us make it difficult, we want an strategy game. So you need to select units, and point to where you want them to move.
As we said, there are multiple menus:
The unit select menu. Each unit is an option. "Next option" means next unit. "Do option" means toggle selection.
The point menu. This one gives you a pointer. The options are direction (up, down, left, right). "Next option" means next direction. "Do option" means move.
The command menu. This one also works with the pointer. The options are commands you can issue to the selected units. (e.g. "move here"). The available options may differ depending on the position of the pointer (e.g. if it is on an enemy unit, the "attack" command is available. Or if it is a building where you create units, there are commands to create them). Or you could use it to deploy units (for example for a tower defense or a tactic game).
How about a MOBA? I think it is similar enough to an strategy game. Something I would do different is adding a path menu, where you can pick or change the path your units will follow. There must be an ability menu, which is where most direct combat would happen. And a purchase menu, for items and upgrades, or even extra units.
By the way, I imagine something similar - but simpler - would do for a lemmings-like game.
Alright, probably not what you had in mind, but you said "any possible types of game".
If we want something more action oriented. Where actions need to happen fast. Then we got to be creative. For example for a side scroller:
- Hold Button 1: Move to the left
- Hold Button 2: Move to the right
- Tap Button 1: Attack left
- Tap Button 2: Attack right
- Double Tap Button 1: Dash left
- Double Tap Button 2: Dash right
- Tap Button 2, Button 1: Grab left
- Tap Button 1, Button 2: Grab right
- Tap both buttons: Jump
- Hold both buttons: Change menu
And use context! For example:
- If you dash away from an enemy, it is a dodge.
- If you time your attack with an enemy attack, it is a parry.
- If the enemy is away, the attack is a ranged attack.
- If you attack while jumping, it is a ground slam.
- If you are grabbing, then instead of dashing, you throw.
- If you are grabbing, then grab is a finisher.
- If you grab a wall, you climb.
- If you are jumping and you attack a wall, it is a wall jump.
It does not have to be like this. Perhaps your character does not jump. Or does not grab. And so on. Perhaps it does other things, like charging power for an attack. Or it can flip gravity. Or it uses a grappling hook, or whatever… Listen: you got to make your game unique.
In fact, replace the grabbing thing with changing weapons (let grabbing be a weapon if that needs to be the case), and attack is using the weapon.
Action top down
Let us say we want a top down game. The menu approach works. Each direction is an option. "Next option" is change direction "Do option" is walk.
Now, if you consider the environment, it works better. For example, you can make every doorway and every object you can interact with an option.
But let us say, this is a top down action game. There are enemies, and you need to attack in real time. Then we need to get creative again. What comes to mind are tank controls:
- Button 1: rotates to the right
- Button 2: rotates to the left
- Tap both buttons: attack
- Hold both button: move
You can use context again! If the enemy (in the direction you are attacking) is nearby the attack is melee, if it is away, it is a ranged attack. Or if the character does not have ranged attacks, then perhaps attacking in the direction of an enemy that is away is a dash and attack, closing the distance. Oh, and that does not have to be "attack", it can be "interact". You know, pick an item, talk, and so on.
Alternatively, you can make attack by running into the enemies. So that you don't need to distinguish "attack" and "move". Yes, that won't work if you want ranged attack, but lets you nicely add "Change menu":
- Button 1: rotates to the right
- Button 2: rotates to the left
- Tap both buttons: move/attack/interact
- Hold both button: Change menu
One menu can be "shooting" mode, where you don't move, just shoot. And you can change to other menus. For example, your character and equipment menus for those classic top down RPGs. And just so you don't have to tap so much to move, you can make move toggle.
By the way, those being tank controls, they also work to control a vehicle. for example for a racing game or a vehicular simulator on land.
Something that would certainly be a problem is a time sensitive shooter (first person or over the shoulder). Auto target I say. What to shoot is a menu. Perhaps fallout pip-boy style. Or just Ocarina of Time auto-target style. By the way, the same general idea would work for point and click games.
Of course, in a shooter we don't only aim. We also move. We can base movement on the tank controls idea:
- Button 1: Rotates to the right
- Button 2: Rotates to the left
- Tap both buttons: Attack (auto target)
- Hold both button: Change menu
Another menu would be to select a target:
- Button 1: Next target
- Button 2: Prior target
- Tap Both buttons: Do
- Hold Both buttons: Change menu.
In fact, if also include nearby areas, not only enemies. It might even include other things, such as destructible enviroment. Then "Do" depends on what the target is. If it is an enemy, the character attacks. If it is an area, then the character walks to that area. You can make the character walk until it reaches the destination, but still allow to select targets and shoot.
Yet another menu can be to change weapons. Or even to select abilities for a hero shooter.
You could, of course, use the pointer with directions idea from the strategy game for aiming. Perhaps with auto-bullet time.
A variant would be:
- Button 1: increase
- Button 2: decrease
- Both buttons: change axis/slider
Which I could work for steering in a flight simulator. You could also distinguish tapping both button and holding both buttons to add a shoot function.
For most ball games, you should be able to automatically pick player closer to the ball, plus tank controls.
If you are doing boxing, each button could be punch. But it does not make sense to hold a punch. So those could be blocks. Holding both could do something else. Different sequences of taps one and the other could be combos.
Other games can be simplified further, for example tennis could be move left, move right, auto swing, like pong. By the way, an interesting take on football is an auto-runner.
I believe the changing axis/sliders approach I was describing for the flight simulation would work for golf, bowling and similar.
You might need a way to escape some of these control schemes to access a game menu. Let that be another reason to put a Change menu option.
However, there is another way to make a game menu: make it diegetic. Place something in the game world that the players interacts with, and that is the game menu.
Also, the menu should come up on game over. Which reminds me. If there is saving and it makes sense, have auto save, and have it rotate slots. So the player does not have to open a menu to save, and on game over the player can pick which auto save to load.
Hmm… You say "any possible types of game". But how do you make a typing game? I suppose you could make a virtual keyboard. Each key is an option. "Next option" means next key, and "Do option" means press. In fact, you could make "Do option" be toggle press.
Furthermore, you can make a virtual game controller, and make "any possible types of game" work with that. I didn't promise it would be a fast input system.
We can do better, with Binary search!
- Button 1: Go to left child branch
- Button 2: Go to right child branch
- Both buttons: Go to parent
So you make your menu of options (e.g. the keyboard) as a tree. Where the effective options are the leafs of the tree (e.g. a key or a letter). And when there are no child branches, then either Button 1 or Button 2 are "Do option".
Also, if you are trying to help the player to type (instead of typing being the game), you can make a binary search for words in a dictionary instead. Or you could be writing letters, but when you are on a leaf, Button 1 types the letter, and Button 2 takes you to an autocomplete menu.
Combining single button schemes
I will also remind that there is always the "tell me where to stop" approach. You would have the options of the menu passing one by one. "Change menu" can be an option. And then the player press a button when the current option is the one they want. That is a single button input scheme.
A variant of this would be holding to select the option. That is, tapping does the default option. But if you hold, the options will be changing, and whichever is the current option when you release is what you do.
I can imagine something similar for an asteroids inspired game, where the ship is turning as long as there is no input. Holding the button moves. Tapping it shoots.
Now you have the second button free to do something else!
Here is something else to do with one button: Taps and Holds. It is like morse code. Or binary. You can encode the options in a binary tree (again). A tap takes you to the left branch, and a hold takes you to the right branch. A long pause is "Do option" (if the combination of taps and holds took you to a valid leaf, otherwise it does nothing), and takes you back to the start to type another combination.
Imagine: On your left hand you have the "tell me where to stop" menu. The first option is "attack", so if you keep tapping, you do normal attacks. Or you could wait until an useful special attack appears on the menu. Meanwhile, on the right you have the "tap and hold" menu, and there your input is reactive to what the enemy is doing (the enemy could telegraph what to input), if you do it correctly, you may dodge attacks or even counter.