untune
Member
Hi all,
I've just been pondering something and I'm curious what the approach would be for other people.
I've been coding an input system that takes care of input devices and bindings, and has lots of little features to make things easier to deal with. I did a bit of research with Messhof's InputDog library a while ago just to get a few ideas for structure etc.
That one uses a single "manager" parent object containing practically all of the creation and step code, but is then instantiated by use of separate child objects (InputForPlayer1, InputForPlayer2, InputForPlayer3, InputForPlayer4... etc) which inherit everything from the manager, but have a single user event triggered in the manager create event that just adds the actions (i.e the controls) for that player. It seems a little strange to me to have a completely unique child object per player - I'm wondering what the benefit of doing this might be? I'm thinking of managing players, devices and controls mappings using lists or grids stored in the manager, or at the very least have a single child object which is instantiated multiple times for each possible player.
Can anybody offer any ideas to the benefits of each implementation?
Cheers
I've just been pondering something and I'm curious what the approach would be for other people.
I've been coding an input system that takes care of input devices and bindings, and has lots of little features to make things easier to deal with. I did a bit of research with Messhof's InputDog library a while ago just to get a few ideas for structure etc.
That one uses a single "manager" parent object containing practically all of the creation and step code, but is then instantiated by use of separate child objects (InputForPlayer1, InputForPlayer2, InputForPlayer3, InputForPlayer4... etc) which inherit everything from the manager, but have a single user event triggered in the manager create event that just adds the actions (i.e the controls) for that player. It seems a little strange to me to have a completely unique child object per player - I'm wondering what the benefit of doing this might be? I'm thinking of managing players, devices and controls mappings using lists or grids stored in the manager, or at the very least have a single child object which is instantiated multiple times for each possible player.
Can anybody offer any ideas to the benefits of each implementation?
Cheers
Last edited: