So, what I usualy do is make a keylistener that tracks all the inputs I need and have a load of booleans that get updated by the listener. Everything that needs inputs then just looks at those static booleans.
I’ve seen that in the ChaseCam code the camera uses its own analog and key listener which is pretty much seperate of everything else.
Now my question is, would it be more “correct” to give every class that needs to track inputs its own listener, or is the way I do it not completely facepalmable?
Until now I hardcoded everything in my little monkey game. It has support for keyboard, mouse, joystick and retro joystick. All using standard jME input listeners.
Unlike you I don’t have static booleans with polling - I just do whatever the input code will cause directly in the listener branches. That’s probably bad design if you start more complex things like Entity System stuff (Zay ES is still on my todo list - I didn’t understand ES yet, because crappy internet explanations).
Some years ago I tried to decouple things and have a smart design for input in general. But due to real life I had to quit this noble idea.
I know that pspeed has an “InputMapper” but I don’t know how good or bad that software is in comparison to my design - because I didn’t have time to take a look at Lemur yet.
EDIT: I’m glad that Lemur and its InputMapper are here. I would definitely check this out first before starting to design anything again on my own. It’s here, it’s free, it’s now. Most people can learn from that code … that’s pretty awesome.
That actually seems a good idea…until you need to do an action if a key isn’t pressed. Like for example autopoint camera unless mouse right click is held down.
Hahah… was going to mention InputMapper but someone did it for me.
You still end up potentially keeping booleans sometimes but 90% of the time that’s not needed because InputMapper’s version of ‘analog listener’ is a little more sane. And anyway, everything else is cleaner.
Lemur is a bunch of separate modules rolled into one package. You can use InputMapper by itself without the rest of Lemur if you want.
The jar is not big.
Almost all of the parts are separately usable, but especially InputMapper which may make it into jme core someday in some form. Also independent, mouse listening/scene picking, animation (recently added), and a few useful mesh classes. Maybe something else I’m forgetting, too.
I use my custom state system and pass every generic type of “input” to each state, which then does its own thng with it. So for instance, i pass a generic “left click” in and depending on the state it does only the checks and updates that are a relevant to it.
Its string based and allows me to pass an array of parameters too for chaining input. So if i pass left click to one state, then it mightbsay "weve clicked a ship, lets go to “move ship state” and pass the input plus the ship id. Thats just one example.
Most people can learn from that code … that’s pretty awesome.