The default unity input manager is firmly closed up and tucked away behind several brick walls. We want to have more control over the input and give the user the option to remap the key’s while playing. A new sub quest was born: The Input Manager.
In the first prototype this quest was completed, we had a flexible key-binding system called Input Manager. The Input Manager was a simple wrapper around the UnityEngine.Input class. It worked and life was sweet in the realm of Pis. But then some people started to ask questions, ‘can we have double tab on one key’, ‘can we have combo key’s’, ‘I need unity’s build in axis system’, ‘How about input from other devices ?’ … No, our wrapper could not do that, it was just a small and simple class.
We needed a more flexible system to deal with all the different way’s a user can interact with the game (user actions). Beside flexible it had to be fast and expendable to other input methods.
At first glance this looks like a simple task and to be honest it is. But there are several different ways to go about this and they all have there pros and cons. So lets look over them and way I made certain choices.
First option would be to simply extend our wrapper and put every thing in there; not a option really, it would make it very hard to add other devices later on and the file would just be a cluster fuck (as I like to call a huge amount of if/else statements nested in to one function/file). So we have to start splitting it up in to different classes and preferably create some degree of polymorphism to prevent the same ‘cluster fuck’ of showing up again.
The second decision to make is ‘how to store and identify these actions’, we could use array index, numbers, strings, enumeration, … as id’s.
=> First off lets strike the array index, it isn’t reliable (same as some other options I left out) as a result we would need extra checks and we don’t want that. Way is that ? Well what happens to a array of 6 elements if you delete the 4the element ? (indexes change)
=> Numbers, endless amount of id’s and fast but annoying, a number doesn’t really say what it does or stands for, you would need to check inside every time. Deleting and adding actions would become a drag as well, grab the next number in line, create a hole in the number list … numbers are a sequence right, It’s not fun and in this case very impractical.
=> Strings these are fun, they would create a endless amount of id’s and can tell us what it does before we even look inside. On the other hand they are very slow and open up the door to typo’s, two reasons way I avoid using strings as id’s when ever I can. (I know there are some tricks to speed up string compare and look-ups but still … it’s the slowest of them all)
=> Enumeration, it’s not as flexible as any of the above methods but is fast, descriptive and typo safe (errors show up before you can even compile the game). The biggest disadvantage is that they have to be hard coded so we lose some flexibility. (yes I know there are tricks to make em flexible)
My choice here is the enum, this is probably one of the few spots where I will trade in flexibility for usability.And lets be honest 128-256 user actions with the option to remap on the fly (depending on game state) should make it it as flexible as we need it to be.
As last, we look for a way to store it, array or one of the many containers in System.Collections, keep in mind we want to store a key and a value. Lets quickly go over some of the main tools that come to mind.
Array’s would waist allot of memory sins we would have to reserve it for all possible user actions even those we don’t actively use.(again yes I know, you could redo the array on change, but I don’t like garbage and I definitely don’t like the collector). A Hash-table could do the trick but it isn’t type safe and you end up casting allot. Fast forward, Dictionary is the collection we want, it’s optimised for key/value pairs with fixed types.
So lets recap, we need different action types to bind to different action key’s and we will be storing these in a dictionary managed by a manager.
So after some playing around this is what I came up with:
‘Action Base’ or ‘Act as base’ is used as base class for all other actions, this creates the polymorphism to simplify our manager. Our enumeration for all action key’s, we know what thy are for and a enumeration for the action types. Using a enum for the action types provides us with some fast check, at least faster then using typeoff(), to differentiate action types. Last but not least the manager and all the different actions.
Single Key: just a single key press, vb. a, b, up arrow
Combo Key: a combination of key's, ctrl+a, ctrl+shift+a
Single Axes: negative and positive key, holding them down will increase decrease a float value representing rotation around a axis.
Combo Axes: same as above but with a key combination.
Key Sequence: A timed key sequence, double dash a key or even a longer series to create special combo (attacks).
Key Macro: For now this allows us to bind multiple ActionKeys (if there set as one of the above) to a single key on the keyboard, triggering all those actions with one key as result.
With that done we wrap all the public functions in to playMaker actions and we are done. Byby 'Input Manager', Hello 'User Actions'.
Clean, fast, easy to use and easy to extend. Send it off for review …
For most programmers all this will be very basic but I hope some people new to the craft or a hobby coder got some new insights. Next up will be character attributes and/or maybe a gui to test the key binding a bit more.
andulkaphoto
jacobvanloon
stormborns
germansingergirl
discoholicmusic
baratheonpilled