Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Input manager, mapping functionality


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 mmurphy   Members   -  Reputation: 106

Like
0Likes
Like

Posted 26 November 2011 - 02:21 AM

I have been working on an input manager but then I got to a point where I did not see how key was suppose to map to an "action". I read a few topics here on the subject, but I am still not clear on it. I know how to detect my keys, but I am just not sure how I should map functionality. Should I associated certain functions with it? what other ways could it be done? Does anyone have any suggestions?

Sponsor:

#2 zfvesoljc   Members   -  Reputation: 450

Like
0Likes
Like

Posted 26 November 2011 - 03:39 AM

something like this:
BIND INPUT(s) ACTION

on actions you should also track current and previous state, so you can have IsAction, IsActionDown, IsActionUp functionality. a good thing is also to track how long is the action "pressed", so you can if needed differentiate between taps and long presses. another thing is action "value", which should be intended for analog devices, so you can actually get values in range 0.0-1.0. one more nice thing is to combine input actions into vector input action, so for example you can say GetActionVector( look ) and as a result get a 2D vector which corresponds to left/right thumbstick position on gamepad.

#3 L. Spiro   Crossbones+   -  Reputation: 21358

Like
0Likes
Like

Posted 26 November 2011 - 07:56 AM

It is partially a matter of taste but I would heavily recommend against mapping of any kind.
That may work fine for event-based systems such as standard applications, but not for games.

Firstly, let’s say you have mapped a key to an action. B to jump.
But now you are in water. Remap the key to “swim”? Keep the key on “Jump” but add code to check if you are in water during a jump?

The player presses pause. Send a message to all game objects to unbind? Add code to all the action functions to check if the game is paused?
To what end?

The way input is handled varies from game-to-game, and any kind of overspecialization such as a binding mechanism is not only cumbersome but limiting. It makes it a chore to manage what should be bound when, and makes debugging extremely clunky.

I would recommend instead that you simply buffer the input for a given duration into the past and expose the buffer to any objects that need it.
That would be the menu manager/HUD, plus the class that drives the game logic and can cause jumping or other actions to happen on any object.

Just keep a record of the last X seconds of input and let the rest of the game use the data as it pleases.


L. Spiro

#4 zfvesoljc   Members   -  Reputation: 450

Like
-1Likes
Like

Posted 26 November 2011 - 11:39 AM

Firstly, let’s say you have mapped a key to an action. B to jump.
But now you are in water. Remap the key to “swim”? Keep the key on “Jump” but add code to check if you are in water during a jump?


well, to avoid such problems, you can still give a more generic action name, like fire1, fire2, action1, action2, if you have clear action definitions that is :)

#5 DenzelM   Members   -  Reputation: 295

Like
0Likes
Like

Posted 26 November 2011 - 12:21 PM

Firstly, let’s say you have mapped a key to an action. B to jump.
But now you are in water. Remap the key to “swim”? Keep the key on “Jump” but add code to check if you are in water during a jump?

What you described is simple to do with an input mapping system.

The player presses pause. Send a message to all game objects to unbind? Add code to all the action functions to check if the game is paused?
To what end?

There are multiple ways to go about that, but what you just described doesn't even take advantage of an input mapping system. Since the system is centralized you could simply freeze all input from every reaching its intended target. This would allow animations to continue, but would freeze the game to player input.

I would recommend instead that you simply buffer the input for a given duration into the past and expose the buffer to any objects that need it.
That would be the menu manager/HUD, plus the class that drives the game logic and can cause jumping or other actions to happen on any object.

How would you implement priorities in the system? Which objects get first crack at the data? These are all questions that can be easily answered with an input mapping system. In fact, it is pretty standard in the game industry to use such a system.

Back on topic, mmurphy, I recommend you check out ApochPiQ's article on Designing a Robust Input Handling System for Games; he was even gracious enough to provide code for once you are done reading.
Denzel Morris (@drdizzy) :: Software Engineer :: SkyTech Enterprises, Inc.
"When men are most sure and arrogant they are commonly most mistaken, giving views to passion without that proper deliberation which alone can secure them from the grossest absurdities." - David Hume

#6 L. Spiro   Crossbones+   -  Reputation: 21358

Like
1Likes
Like

Posted 26 November 2011 - 09:53 PM

There are multiple ways to go about that, but what you just described doesn't even take advantage of an input mapping system. Since the system is centralized you could simply freeze all input from every reaching its intended target. This would allow animations to continue, but would freeze the game to player input.

Actually there are much more graceful and logical ways to freeze the game which are unrelated to input processing. They are completely unrelated subsystems, meaning that when the game is paused, input or not, the game characters can’t move.

The question here is about how to distribute the input. You wouldn’t “freeze” input, you would redirect it to the pause menu, which would allow selecting the options button or unpausing the game, etc. In other words, changing the context of the input.


My post was meant to illustrate that a rudimentary just-map-a-key-to-an-action system is not the way to go.


I have no qualms with the system explained by ApochPiQ. Conceptually, my system ends up doing exactly the same thing, but is less automated by the engine and more by the game itself.
I have been considering moving this automation over to the engine (where it does need to be), only to be held back by concerns of that rare edge case in which my system would not be able to handle something the game needs.
I am thinking about touch input. Strokes all of natures, for iOS devices. Accelerometers, etc.

I have a few ideas but I am not focused on input for now.

For the topic poster, I recommend just going the way described by ApochPiQ.


L. Spiro

#7 DenzelM   Members   -  Reputation: 295

Like
0Likes
Like

Posted 27 November 2011 - 05:17 AM

I know there are multiple ways to handle the situation, hence the "there are multiple ways to go about that..." I was simply demonstrating a hypothetical example in which there is a paused "state," and not a menu of any kind. Futhermore, in direct contradiction to what the OP was looking for, you recommended against mapping of any kind in your previous post.
Denzel Morris (@drdizzy) :: Software Engineer :: SkyTech Enterprises, Inc.
"When men are most sure and arrogant they are commonly most mistaken, giving views to passion without that proper deliberation which alone can secure them from the grossest absurdities." - David Hume

#8 mmurphy   Members   -  Reputation: 106

Like
0Likes
Like

Posted 27 November 2011 - 04:03 PM

Back on topic, mmurphy, I recommend you check out ApochPiQ's article on Designing a Robust Input Handling System for Games; he was even gracious enough to provide code for once you are done reading.


This is a very interesting artlcle. After reading it I took a look at the source and I noticed there were a few files in that blog mentioned that I don't see in the source, does anyone know what may of happen to them?

I don't see context.xml, inputmap.xml, and inputranges.xml.

#9 ApochPiQ   Moderators   -  Reputation: 18123

Like
1Likes
Like

Posted 29 November 2011 - 02:02 PM

The code I wrote uses a simpler version of the file format than full-blown XML; you can read about the decision behind that here and find the appropriate data files here.

#10 ILoveJesus   Members   -  Reputation: 166

Like
0Likes
Like

Posted 29 November 2011 - 02:36 PM

The code I wrote uses a simpler version of the file format than full-blown XML; you can read about the decision behind that here and find the appropriate data files here.


What I do for my input is when button is pressed I call a function with an argument called string whathappened.

So like ButtonInput("enter") for when enter is pressed.

in that function I determine where I am in the game and call any other function that is needed for when enter is pressed.

For mapping you would need to change it up some.
For mapping I imagine you can have a variable for each key and give it a value like "enter" or "shoot" or "cancel" or "menu".
In your menu you can simply ask the user to press what key they want for mapping next to the action they picked. So if they press enter for shoot then you give your enter key variable the "shoot" value.
Now, while playing the game, when you press a key you check to see if your variable for it has a value. If it does not you ignore it, but if it does you can call a function like ButtonInput above and add the value of the key as an arguement. So if enter is checked and it has a value and it is shoot you would call Buttoninput("shoot"). This is how I would go about it.

#11 ApochPiQ   Moderators   -  Reputation: 18123

Like
0Likes
Like

Posted 29 November 2011 - 02:54 PM

Have you read the article? It describes a system which accomplishes much the same concept but more efficiently than with strings and with a bit more flexibility and feature support as well.

#12 ILoveJesus   Members   -  Reputation: 166

Like
0Likes
Like

Posted 29 November 2011 - 03:33 PM

Have you read the article? It describes a system which accomplishes much the same concept but more efficiently than with strings and with a bit more flexibility and feature support as well.


My bad, my comment was meant as a reply to the OP.

#13 Cornstalks   Crossbones+   -  Reputation: 7003

Like
0Likes
Like

Posted 29 November 2011 - 03:36 PM


Have you read the article? It describes a system which accomplishes much the same concept but more efficiently than with strings and with a bit more flexibility and feature support as well.


My bad, my comment was meant as a reply to the OP.


I think ApochPiQ knows your reply was really meant for the OP, though it was kind of a response to his reply, but what I think ApochPiQ is really trying to say is that his system is more efficient, flexible, and has more feature support. You're solution works, but... his is better, to be honest. I think that's the point he was making.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS