Nota: 6 minutos de concentración. Lee despacio y con atención. Aprovecha el tiempo .
Hola a todxs,
Como ya sabéis, nuestras tareas inmediatas son:
- Tener un Game Engine básico.
- La 1ª versión del modelo del juego.
Apoyaos en los materiales disponibles (que acabamos de ampliar):
- Libro: Cómo desarrollar un Game Engine ECS en C++20 / Laureano Cantó Berna.
- Compañero vuestro de hace 2 años cuyo TFG fue hacer este libro para ayudaros a crear un ECS.
- GameEngine ECS básico: Room of Doom en C++20.
- Muy recomendable para que lo veáis todos y aprendáis muchas cosas de C++ y de cómo van los motores.
- Serie de 3 vídeos (unas 9 horas) con las bases de un motor ES sencillo. Este es muy parecido a lo que estamos haciendo en clase, pero en vez de ser Componentes con método update(), son componentes que sólo tienen datos y usamos sistemas para actualizar. Por tanto, esto contaría como un motor Por Componentes, pero con sistemas. Es lo que os comenté en la última clase de que hay 2 opciones básicas para este motor. Esta es la otra opción.
- Para quienes queréis crear la versión más propia y avanzada del GameEngine ECS, es recomendable ambas listas. En la primera se parte de conceptos más sencillos que habéis manejado en cursos anteriores y se aprenden muchos detalles de C++ y cómo pasar de herencia a templates. En la segunda lista se tratan temas más avanzados, se implementa la estructura de datos para hacer eficientes los componentes y se aprenden técnicas muy avanzadas de C++. Quienes queráis seguir el camino de programación en la industria, esta es vuestra línea.
Cuestiones MUY IMPORTANTES del desarrollo del motor (y el proyecto):
- Decidid definitivamente que tipo de motor queréis hacer (ECS, ES / Componentes u Objetos).
- No esperéis a próximas clases: tenéis que trabajar y avanzar todos los días.
- Al principio de cada iteración:
- Plantead que cosas queréis que haga el motor de juego al terminar la iteración.
- Estimad que os dé tiempo (¡ojo! estimad los costes de aprendizaje!)
- Dividid en tareas y subtareas y poneos a trabajar.
- Importante: siempre debéis dejar el motor usable al final de cada iteración. No puede estar a "medio hacer". Si está a "medio hacer" es que habéis estimado o diseñado las tareas mal. Más vale menos cosas, pero usables, que más cosas a medio hacer.
- Dividid vuestro trabajo en 3 ramas principales:
- main: donde debéis mergear los resultados estables finales de vuestro progreso.
- development: donde debéis estar elaborando cada próximo hito.
- experimental: donde debéis trabajar por iteraciones, creando código sucio que NO debe ser reutilizado.
- Las ideas son las siguientes:
- experimental es para aprender. Los primeros desarrollos de cualquier cosa deben ser experimentales. El código saldrá sucio, de prueba. Nunca debe mergearse con development ni con main. Es para hacer cosas rápidas, de una iteración a la siguiente y aprender. Sobre todo, aprender 2 cosas: técnica (cómo se implementa algo) y diseño del juego (ver cosas del juego funcionando pronto, para tener cosas visuales y tomar decisiones rápidas al verlas funcionando). Todo lo que se haga en experimental debe desecharse tras cada iteración.
- development es para ir avanzando tecnología y juego. Aquí es donde debéis implementar las cosas tras haber aprendido y haber decidido (gracias a la rama experimental). Deben implementarse de nuevo, haciéndolas bien hechas. Aquí las cosas ya deben estar pensadas para que las use el equipo. Cuando se llegue a cada iteración, development debe tener un "cierre"; es decir, debe ser algo utilizable por sí sólo, sin necesidad de seguir implementando cosas. El diseño iterativo es eso: cada iteración termina con un resultado cerrado y usable. Con menos o con pocas características, pero usable. Con eso, lo que deberéis hacer es mergear de development hacia experimental ¿Para qué? Para empezar de nuevo en experimental la siguiente iteración, pero partiendo de la última versión de la tecnología del grupo, que es lo que os permitirá rehacer cosas en experimental más rápidamente y aprender de vuestra propia tecnología.
- main debe contener los resultados finales, estables. Cada vez que en development cerréis una iteración y tengáis una nueva versión estable de vuestro producto, podéis mergearla en main, para que esté disponible como nueva versión. Lo único que se acepta en main, aparte de esto, son fixes. Es decir, si la versión que hay en main, que es estable requiere un retoque por algo que no va como debería, se le aplica el fix correspondiente y nada más.
- El desarrollo debe ser por features. Cada vez que vayáis a desarrollar algo nuevo en cualquier rama, sea development o experimental, lo que debéis hacer es abrir una nueva rama para la tarea concreta que vais a hacer. Se abre la rama, se desarrolla y, cuando está lista, se mergea de nuevo en la rama original (sea development o experimental). ¡Mucho ojo con esto! Estas ramas de tarea o característica (feature) deberían estar limitadas a 48 o 72 horas máximo. Si vais a hacer una tarea y lleva más de esa cantidad de tiempo, es que la tarea está mal diseñada y hay que dividirla en subtareas. Nunca tengáis ramas sin mergear más tiempo. Eso os dará muchísimos problemas.
- Por supuesto, no uséis ramas con nombre de persona, ni para cosas vuestras. Esa no es la finalidad de las ramas.
Hablaremos de todo esto en próximas clases, pero os lo dejo por escrito para que os sea de utilidad .
Cualquier duda que tengáis, preguntadla cuanto antes y la vemos .
Un saludo,
Fran.