[Unity] ¿Cómo organizar los scripts de manera modular y desacoplada?

#2 La cosa es que para mi no tiene sentido que el script principal se encargue de llamar al resto de funciones, si añado un script de salto automáticamente debería de funcionar lo añada al personaje al que lo añada, debería de venir con todo lo necesario como:

• Comprobar que se pulsa la tecla correspondiente para ejecutar el salto
• Las variables de salto relacionadas con el impulso o la gravedad
• Los efectos de sonido
• Partículas que pueda llegar a generar

Si es el script principal el que se encarga de llamarlo, estaría acoplado y no podría quitar ese script de salto sin tener que retocar código, ¿no?

Querría poder añadir o quitar funcionalidades de esa forma, añadiendo o quitando un script simplemente.

#3 No me has entendido.

Tienes PlayerController que gracias a un GetComponent, va a buscar el script encargado del salto acoplado al GameObject Player. Tú en tu PlayerController pones

jumpStyle = GetComponent<Jump>();
jumpStyle.jump();

Y luego el GameObject Player va a tener un script añadido que sea el Jump, ya sea Jump, DoubleJump, TripleJump o NoJump. Todos heredan funcionalidades del Padre Jump.
Puedes agregarlos al Objet Player. Cuando el jugador haga la interacción de Saltar, ya sea pulsando Espacio o X o el botón que sea. Todo el entresijo de código llegará a la parte que es jumpStyle.jump().
Y esta mirará el componente que tenga añadido que será la que mire de hacer el salto normal, el salto doble o lo que quieras. Esto viene bien cuando tienes diferentes funcionalidades para el personaje, ya sean buffs, debuffs o características que cambien a lo largo del juego.

Ejemplo: Jugador puede hacer Salto normal. Tienes Objeto Player con script de Jump añadido.
Jugador se acerca a objeto que le permite ganar la habilidad de Doble Salto. La recoge y en este momento, remueves el Script Jump.cs y lo sustituyes por DoubleJump.cs. Player Object y PlayerController van a buscar un Jump, le da igual cual sea y le van a pedir que ejecute el código que esté en el método Jump. Y es el DoubleJump.cs el que te permitirá hacer 2 saltos en vez de uno.

El problema es que tienes muchas clases separadas y que posiblemente cambien unos números o unas lineas entre ellas. Pero te permite cambiar funcionalidades, testeo y ganar escalabilidad.
Ya entra en juego luego crear Interfaces, que a una misma clase añadirle funcionalidades extras sin que afecte a la herencia.

En el caso de Celeste lo explica bien. Tienen un montón de Estados y tener referencia a todos ellos de cara a controlarlos y referenciarlos puede ser un quebradero de cabeza. Por eso el controlador tan inmenso que tienen. Pero dentro de ello, está limitado a lo que hay.
Si Celeste tuviera estados alterables, temporales o buffs/debuffs, no le funcionaría todo eso.

Para FSM es correcto tenerlos separados, pero para movimientos de personajes en escena, hay demasiadas combinaciones realizables.

Al final, es el juego y la experiencia la que te dictamine que hacer en cada ocasión.

No intentes hacerlo perfecto desde el inicio (aparte de que no existe la manera perfecta, siempre vas a tener que traicionar de una manera u otra tus patrones). Prueba de una forma, expandela y aprende cuales son sus debilidades y fortalezas. Luego intentalo con otro tipo de implementación y lo mismo (o cmabiando de feature para no aburrirte con la misma siempre), y vas viendo qué funciona en cada caso y qué no. Ademas es divertido aprender de esa manera (al menos para mi).

Luego mola cuando tienes que enfrentarte a una situación similar a otra que hayas resuelto, y si tienes mas experiencia, seguro que se te ocurren mejores maneras de hacerlo esa vez. Disfruta el proceso del aprendizane, que cuando da sus frutos mola mucho