Aprendiendo Rust - Kiwi Towers

#38 Cuando empece, lo hice con C pero no llegue a hacer nada raro con ello asi que la complejidad era infima. Lo mas complejo que hice en su dia fue un piano para la Nintendo DS que podia guardar canciones (16 teclas creo que eran). Asi que se podria decir que Rust es el primero que hago sin GC.

Ayer estuve un poco con el plan que tengo, no es nada del otro mundo pero cosas que tarde o temprano me gustaria implementar asi como algo de documentacion ya que no voy a ser el unico trabajando en esto!

Hoy he estado investigando un poco mas sobre el engine y todavia le faltarian muchas cosas necesarias para el editor de mapas (como un input de texto), pero he estado hablando con un colega y quiza se anime a hacer el la parte de la interfaz/editor mientras que yo estare con todo el backend + la logica del juego. De aqui a unos meses el motor estara bastante mas avanzado (y pulido), y yo sabre mucho mas sobre Rust asi que no lo veo tan mal plan ya que sabia que no iba a ser rapido para nada ademas de que sabia donde me metia al hacerlo tan "temprano".

Pues he reescrito un poco como tenia hecho lo de los components y las entidades, he aprendido bastante mas sobre ello y ademas he hecho que los mobs mueran! (aunque no dan oro para nada). He entendido un poco mejor como funcionan los bundles y la verdad es que no esta nada mal.

He invertido el como se hacen las cosas y he creado un trait para que lo implementen los bundles para spawnear la entidad con no solo el bundle si no con lo que haga falta (como por ejemplo el timer en el caso de las torres):

pub trait Spawnable {
    fn spawn(self, commands: &mut Commands) -> Entity;
}

impl Spawnable for Tower {
    fn spawn(self, commands: &mut Commands) -> Entity {
        let timer = Timer::new(Duration::from_secs_f32(self.attack.attack_speed.0), true);
        return commands
            .spawn(())
            .with_bundle(self)
            .with(timer)
            .current_entity()
            .unwrap();
    }


#[derive(Debug)]
pub struct TowerComp;

#[derive(Debug, Bundle)]
pub struct Tower {
    pub comp: TowerComp,
    pub hp: HealthPoints,
    pub attack: Attack,
    pub critical: Option<Critical>,
    pub slow: Option<Slow>,
    pub stun: Option<Stun>,
}

Con esto se ha de cambiar obviamente la signature del sistema pero bueno, algo bastante sencillo. Lo unico que no me gusta es que has de poner el .0 en muchos de los casos al ser structs con un solo parametro sin nombre.

fn attack_mobs(
    mut commands: Commands,
    mut towers: Query<(&TowerComp, &Attack, &Timer)>,
    mut mobs: Query<(Entity, &MobComp, &mut HealthPoints)>,
) {

Pero con esto quedan cosas super guays como el sistema para borrar los minion del "mapa":

fn despawn_dead_entities(mut commands: Commands, dead_mobs: Query<(Entity, &Dead)>) {
    for (entity, _) in dead_mobs.iter() {
        commands.despawn(entity);
    }
}

Son literalmente 3 lineas!

Asi que sigo cuidando mas o menos el codigo, a;adiendo mas tests y mejorando el plugin basico que simula un mapa. Lo siguiente (ya tengo las issues creadas en el repo) seria a;adir waves y que el spawn de los mobs se pueda configurar.

Y con otros poquitos cambios ya tengo funcionando lo de hacer spawn de una oleada (un mob cada X tiempo) y una torre que les dispara. En este ejemplo la torre tiene 2 targets por lo que los dos mobs que se spawnean (que parecen no hacerlo cada X tiempo), son matados al instante

2020-11-26T23:00:55.785300+01:00 INFO kiwi_towers - Initializing
2020-11-26T23:00:55.786988+01:00 INFO kiwi_towers::plugins::simple - Initializing SimpleMapPlugin
Spawning mob.
Spawning mob.
2020-11-26T23:00:56.789374+01:00 INFO kiwi_towers::attack - Now the mob 3v0 has 0 hp.
2020-11-26T23:00:56.789440+01:00 INFO kiwi_towers::attack - Killed mob 3v0
2020-11-26T23:00:56.789462+01:00 INFO kiwi_towers::attack - Now the mob 4v0 has 0 hp.
2020-11-26T23:00:56.789482+01:00 INFO kiwi_towers::attack - Killed mob 4v0

Si se cambia la torre a 1 target solo:

2020-11-29T12:01:34.770119+01:00 INFO kiwi_towers - Initializing
2020-11-29T12:01:34.771829+01:00 INFO kiwi_towers::plugins::simple - Initializing SimpleMapPlugin
Spawning mob.
Spawning mob.
2020-11-29T12:01:35.774109+01:00 INFO kiwi_towers::attack - Now the mob 3v0 has 0 hp.
2020-11-29T12:01:35.774181+01:00 INFO kiwi_towers::attack - Killed mob 3v0
2020-11-29T12:01:36.774170+01:00 INFO kiwi_towers::attack - Now the mob 4v0 has 0 hp.
2020-11-29T12:01:36.774239+01:00 INFO kiwi_towers::attack - Killed mob 4v0

Vemos que si que ataca 1 segundo despues (velocidad de ataque). Asi que la cosa va cogiendo forma, y ahora las bases si estan siendo sentadas bien (o al menos eso es lo que veo) ya que escribir mas codigo no cuesta mas, simplemente es a;adir otro sistema que haga algo extra.

Aunque una de las cosas que mas lia sobre ECS son las stages. Las stages son basicamente un conjunto de sistemas que actuan a la vez y esto tiene unas caracteristicas especiales dado que los Commands se ejecutan al final del stage asi que si en una misma tienes algo que spawnea, en ese mismo frame no lo va a ver el siguiente sistema, lo vera en el siguiente frame (y esto puede crear algunos problemas aunque no sean facilmente visibles).

La solucion a esto es usar lo que llaman thread_local_system. Ese sistema se va a ejecutar en un hilito el solo y el World se va a modificar en ese mismo momento, asi que es una buena forma para decir algo como: este sistema es muy critico y se necesita actualizar YA. Que es lo que he hecho con los spawns al ver este comportamiento en los test.

Ejemplo del SimpleMapPlugin ahora:

    fn build(&self, app: &mut AppBuilder) {
        info!("Initializing SimpleMapPlugin");
        let game = Game {
            lives: 40,
            starting_coins: HashMap::default(),
            towers: vec![],
            waves: vec![Wave::from(vec![Mob::new(100_f32), Mob::new(1000_f32)], 0.5)]
        };

        app.add_stage_before("update", "preupdate");
        app.add_stage_after("update", "postupdate");

        app.add_resource(GameState::from(&game));
        app.add_resource(game);

        app.add_startup_system(add_tower.system());
        app.add_startup_system( spawn_mobs.thread_local_system());
        app.add_system_to_stage("preupdate", spawn_wave.system());
        app.add_plugin(AttackPlugin);
        app.add_system_to_stage("update", check_multiple_timers.system());
        app.add_system_to_stage("postupdate", finish_game.system());
    }

Esto lo hice hace unos dias pero tengo demasiadas cosas que hacer y ahora a esto no le estoy dedicando el tiepo que me gustaria

Acabo de actualizar Bevy a la ultima version (que viene de git) y me estan gustando los cambios. Por ejemplo ya no hace falta el .system o .thread_local_system en cada uno de los sistemas, ahora es todo automatico. Tambien han quitado los ticks automaticos de todos los Timer asi que me he vuelto un poco loco pero nada que no se arregle leyendo el changelog.

Por lo demas todo esta chuli y funcionando, he de seguir con el "end game" y poco mas, ahora voy a echar un hots y a dormir.

Como anedota, por ahora las lineas de codigo quedan asi:

--------------------------------------------------------------------------------
 Language             Files        Lines        Blank      Comment         Code
--------------------------------------------------------------------------------
 Rust                    13          836          121            3          712
 Toml                     1           14            3            1           10
 YAML                     1            8            0            0            8
 Markdown                 1            0            0            0            0
--------------------------------------------------------------------------------
 Total                   16          858          124            4          730
--------------------------------------------------------------------------------

Entre hoy y ayer he estado aprendiendo sobre macros. La verdad es que parecen la leche en vinagre aunque me gustaria aprender un poquito mas sobre procedural macros (e incluso macros 2.0). Por ahora he creado una macro para poder testear mas facilmente el codigo sin tener que entrar a saber como funcionan los Scheduler/World/Resources y esas mierdas.

#[cfg(test)]
macro_rules! test_setup {
    ($world:ident, $($var_type:ident: $var_name:ident),*) => {
        let mut resources = Resources::default();
        let mut $world = World::default();
        let mut commands = Commands::default();
        commands.set_entity_reserver($world.get_entity_reserver());
        $(
            test_setup_spawn!($var_type, commands, $var_name);
        )*
        commands.apply(&mut $world, &mut resources);

        let mut resources = Resources::default();

        let mut schedule = Schedule::default();
        schedule.add_stage("update");
        $(
            test_setup_system!($var_type schedule, "update", $var_name);
        )*
        schedule.initialize(&mut $world, &mut resources);
        schedule.run(&mut $world, &mut resources);
    };
}

Luego tengo otras 2 macros para el system y el spawn. Y se usa de una manera super sencilla, por ahora solo he traducido uno de los tests pero cuando termine de cenar van los demas.

    #[test]
    fn do_not_attack_to_dead_mobs() {
        let tower = Tower::new(
            Damage(50_f32),
            100_f32,
            Bullet::default(),
            AttackSpeed(0.5_f32),
            Targets(2),
        );
        let mob1 = Mob::new(100_f32);
        let mob2 = Mob::new(0_f32);

        test_setup!(
            world,
            spawn: mob1,
            spawn: mob2,
            spawn: tower,
            system: advance_timers,
            system: attack_mobs
        );

        let mob1_health_points = world.get::<HealthPoints>(mob1).unwrap();
        let mob2_health_points = world.get::<HealthPoints>(mob2).unwrap();

        assert_eq!(mob1_health_points.0, 50_f32);
        assert_eq!(mob2_health_points.0, 0_f32);
    }

Me gusta el spawn: mob1, system: xxxxxx y se pueden repetir las veces que hagan falta. No ha sido nada super interesante pero al menos veo cuando rompo las cosas (que ya me ha pasado mas de una vez). No se todavia que va a ser lo siguiente, tengo una lista de issues en el repo asi que ya elegire algo, pero me mola como esta quedando

Pues he migrado del repositorio donde lo tenia a jetbrains spaces, tenia ganas de probarlo y quiza me ayuda otra persona, asi que lo he puesto para que se puedan crear cuentas con mi dominio y le he creado un correo a un amigo para probar.

No tiene mala pinta y el tier gratis ofrecen bastantes cosas aunque no se como llegue a ser luego lo que he visto, me gusta.

Esto va de probar cosas, asi que se hace a lo grande xdd

Despues de hacer la masa de pizza para ma;ana me he puesto otro rato. Me esta gustando como lo tienen organizado los de jetbrains.

Tengo ya el ejemplo prepareado igual que lo tenia en el main antes (lo tenia configurado como binario), lo he cambiado a libreria simplemente moviendo el main al ejemplo y cambiandolo por un libs.rs. Ahora puedo hacer lo mismo que antes con cargo run --example simple.

He a;adido tambien que se ejecute la build al hacer una review y estoy viendo a ver como puedo bloquear el merge si esta rota.

#59 No tengo tanto tiempo como me gustaria para dedicarle, pero en ello estoy, poco a poco. Ahora que he hecho lo de los ejemplos me gustaria ver como puedo hacer lo del scripting. Para luego asi poder ir haciendo diferentes cosas dependiendo de lo que me apetezca hacer ese dia.