por Gäelith ahora puede moverse hacia adelante y hacia atrás, girar sobre sí mismo y desplazar piedras. Cuando consigue alinear las tres piedras especiales una brillante llave dorada cae del cielo. Con esta llave puede abrir el portal y avanzar al siguiente nivel.
En el siguiente vídeo puedes ver lo bien que queda esta secuencia de acciones. Las cosas están yendo bien.
Podría seguir avanzando con esta iteración, pero antes de continuar es momento de revisar cuidadosamente el trabajo realizado hasta ahora. El código actual funciona correctamente, pero si quiero que este proyecto escale adecuadamente, necesito establecer bases sólidas desde el principio.
Refactorización de la Clase Player
La clase Player, responsable de todas las acciones que realiza Gäelith, está comenzando a sobrecargarse. En este momento maneja los inputs del usuario, y el movimiento y las acciones del personaje—y apenas estoy en la primera iteración del proyecto. A medida que el juego crezca esta complejidad solo aumentará, así que debo aplicar buenas prácticas de desarrollo de software desde ya mismo para garantizar que el proyecto siga siendo manejable.
Para mejorar la estructura actual voy a refactorizar la clase Player siguiendo el Principio de Responsabilidad Única (SRP)—la «S» de los principios SOLID. Este principio establece que «cada módulo, clase o función debe tener solo una responsabilidad». En lugar de tener una clase monolítica crearé varias clases más pequeñas y especializadas, haciendo que el código sea más fácil de entender y extender en el futuro.
División de responsabilidades
Siguiendo el SRP, he extraído tres nuevas clases, cada una de ellas resposable de una única funcionalidad clara y específica:
- PlayerInput: Gestiona todas las entradas del jugador, transformándolas en vectores y permitiendo su acceso como propiedades públicas.
- PlayerMovement: Proporciona los métodos Move() y Rotate(), que reciben vectores de entrada y resuelven el movimiento. Cuando integre animaciones del personaje esta clase interactuará estrechamente con la máquina de estados del componente Animator.
- PlayerAction: Actualmente es la clase más sencilla, ya que de momento Gäelith solo realiza una acción. En el futuro refactorizaré las acciones usando clases abstractas o interfaces, permitiendo que los propios objetos respondan a las interacciones, mientras que PlayerAction actuará únicamente como iniciador de dichas acciones.
Esta reestructuración hará que las mejoras futuras sean mucho más fáciles de implementar. Por ejemplo, cuando introduzca controles mediante ratón o gamepad, la clase PlayerInput permitirá hacerlo sin demasiada complejidad. De manera similar PlayerMovement y PlayerAction facilitarán la gestión de nuevos movimientos e interacciones sin afectar al resto del código.
Aprende más sobre los Principios SOLID
Para quienes estén interesados en aplicar las mejores prácticas en el desarrollo de videojuegos, Unity ofrece un excelente e-book gratuito que describe los principios SOLID y otros patrones esenciales de diseño para videojuegos. Es un recurso fantástico para escribir código limpio y mantenible en proyectos con Unity.
Juega, aprende, aprende a jugar, juega a aprender… ¡con Unity puedes hacer todo eso!
