When creating a game do you handle all input for the player from a primary class or from multiple classes. Lets say something like angry birds, would you have a class that identifies when you click an object on the screen and then tell that object to act accordingly. i.e. the slingshot knows when a player touches it, the pause button, etc. from a central script. Or would you create a ray from the screen to the slingshot in one script, and then all other are executed from other scripts. I.e. diminishing efficiency for readability or vice versa.
This is a poll, I have done both ways and it seems input handling from a central class based on current game condition and also used separation of class via duplication of inputs.
I guess this totally depends on the game itself. Without too much of evaluation here I guess I would split the controls for the Angry Birds example probably into 2 classes, one for the general GUI, one for the control of the slingshot.
However there are different approaches as well, e.g. in my last game (kind of a PvZ clone) I split the controls up into multiple parts so I ended up with one main class to control the GUI itself, and various other smaller classes to control the different buttons on the screen (which are EZGUI UIButtons), like “What does the pause button do”, “what happens when a defender icon is used” (one class for all defenders of course) and so on. Did that to keep the functions and methods dedicated to its purposes and to keep the overview and maintain the code as there was no reason to attach a class containing logic for defender placement to the pause button.
I myself would probably prefer the “many classes” approach, as the classes can talk to each other either way but the code is easier to maintain.