Quote:Original post by Tenac
I always thought input systems should be made so they can support whatever you want to do without much, if any modification.
I agree. But that is NOT to say that you must design the most uber input system so that nothing new ever needs to be added. It means that you should start by designing the most light weight and most unassuming input abstraction layer.
This layer just manages devices and their state and state transitions. It is not in any way responsible for notifying anyone or game specific logic. It's a system to facilitate polling.
On top of this abstraction layer you can add all the cool notification, chain of responsibility, hierarchial, focusing, ui and gameplay specific input interpretation. But none of that should be in the "input manager" imo, maybe the input interpreter. But it really just comes down to defintions. But the behaviors you guys have been discussing are specific to particular applications.
To reach the goal of Tenac's, there should be very few app specific features in the true input system. It should be portable to any application without bringing over unneeded features, dependencies, or other stripping/workarounds to use it for new functionality.