In the first game, "state" switching of top-level "things" was handled by an  ad-hoc network of scripts (see The State Switcher, previous post). Now I hope my new "DynObj" class will control all animation, sound, and manipulation colliders from one script. Don't get me wrong, the top level "thing" will still need a one-off script because I found all the different stuff I wanted to do was just impossible to standardize, but the bespoke script will be a lot simpler for inheriting from the DynObj class. Before this year, I knew nothing of inheritance, one of the three pillars of object-oriented programming.

Inheritance allows me to have a few public methods and variables on every top-level "thing" that are consistent no matter what the "thing" is. The DynObj class has certain useful methods and all the bespoke "thing" scripts inherit those methods. Whether the thing is a retractable metal grating or a shuttered gazebo-elevator, I call SwitchState(2); to switch either of those things to their second state. They will both play their own sounds, play their own animations, and have the appropriate manipulation colliders enabled (as outlined in the bespoke script) when they are done. SetState(2) will do the same except skip to the end of the animation, play no sound... switch instantly (useful for loading a saved game, which before was a real hassle but now becomes just a long list of the right DynObjs set to the right states). Triggered(string name); is for taking in a user manipulation (like a button-press, a door-yank, or a suncube-placement) and deciding what state to switch to based on what is triggering and what state the "thing" is currently in. I used to have to SendMessage("Triggered") to the top node where I knew the bespoke script was. I heard that was inefficient and deprecated. Now since I know it's a DynObj, I can topnode.GetComponent<DynObj>().Triggered(); and even have room to pass more variables if I want.

Bottom line, inheritance allows all these Dynamic Objects, these different "things", to behave in their unique one-off ways, and yet still be one "thing" and share certain powerful functions. It allows me to find the right mix between a bespoke script for everything (which would have tons of redundancy and inconsistency) and a one-script-to-rule-them-all approach (which would be horribly bloated and probably impossible).