Marien Fressinaud Le blog

Une histoire de pizzas : les déplacements

Cet article fait partie d’une série. Retrouvez les autres articles dans « Ergogames, une histoire de pizzas ».

Le 01 novembre 2019.

Je suis en forme alors voici le troisième article qui relate le développement du jeu que j’ai conçu pour les Ergogames. On a déjà vu comment afficher la grille et comment gérer les objets, nous allons aujourd’hui voir comment déplacer notre personnage, Meiko.

Je vous invite très fortement à lire les autres articles si ce n’est pas déjà fait, vous risquez autrement de ne rien piger à celui-ci.

Le but ici est de pouvoir viser une case avec la souris et de déplacer Meiko en cliquant. Là encore, on a tout un tas de solutions possibles. Ma première approche a été de vouloir rendre les entités « cliquables », mais comme on veut potentiellement cliquer sur des cellules sans entité, j’étais bloqué.

Ma seconde approche a été de faire en sorte de pouvoir cliquer sur les .board-cell qui représentent les cellules de notre tableau (ce sont celles du premier article). Le problème ici est que les entités survolent les cellules et risquent de récupérer l’action du « clic » sans le propager aux cases en dessous, pas cool. Alors on pourrait vouloir rendre tout ce petit monde « cliquable », mais ça deviendrait galère à gérer parce que les clics ne portent plus sur les mêmes types d’objets et il faudrait les distinguer.

Bref, j’ai choisi une solution qui me semble plutôt élégante : j’ai posé un lien unique (balise <a />) par-dessus la zone de jeu, puis j’ai déterminé en JavaScript la case sur laquelle porte le clic.

<div class="board">
    <!-- ... -->

    <!--
        On ajoute un lien qui recouvre l’ensemble de la zone de jeu et qui
        va récupérer les clics du ou de la joueuse pour ensuite modifier
        l’état du jeu.
    -->
    <a href="#" @click="onBoardClick" class="board-click-zone"></a>
</div>

<script>
    // ...

    const app = new Vue({
        // ...

        methods: {
            // ...

            onBoardClick(e) {
                // C'est ici qu'on connecte le tout : onBoardClick est appelé
                // quand on clique sur le lien .board-click-zone. On passe
                // l'évènement généré à un "système" qui va modifier le store
                // (ou non) en conséquence. Le store retourné est réassigné à
                // notre objet VueJS, ce qui va entrainer un rafraichissement
                // du HTML si besoin. Magique.
                this.store = onClickSystem(e, this.store);
            },
        },
    });

    // Notre premier "vrai" système. C'est une fonction qui prend un store
    // en entrée et en retourne un en sortie (modifié... ou non).
    // L'évènement qui est également passé en argument permet de déterminer
    // quelle zone du jeu a été "activée" par le ou la joueuse.
    function onClickSystem(e, store) {
        // On fait en sorte que le clic ne soit pas actionné (sinon l'écran va
        // remonter en haut de l'écran et ce sera pas agréable)
        e.preventDefault();

        // e.layerX et e.layerY donnent la position en pixels de là où l’on a
        // cliqué. Il suffit de diviser cette valeur par la taille d’une
        // cellule et d'arrondir le résultat pour savoir sur quelle cellule on
        // a cliqué... enfin presque, on retranche encore "1" parce que notre
        // tableau commence à l'indice "0".
        // Exemple : si la cellule à l’indice 0 fait 10px et que l’on clique
        // sur le pixel "10", le calcul 10/10 est égal à 1 ; il faut donc
        // retrancher encore 1 pour retrouver notre indice "0".
        // Et si vous avez rien compris c'est pas dramatique, en plus j'ai pas
        // fait comme ça dans le jeu de base :)
        const x = Math.ceil(e.layerX / CSS_CELL_SIZE) - 1;
        const y = Math.ceil(e.layerY / CSS_CELL_SIZE) - 1;

        // On change la position de Meiko pour correspondre à l'endroit visé
        store.meiko.position = { x, y };

        // Et on retourne le store ainsi modifié
        return store;
    }
</script>

<style type="text/css">
    /* ... */

    .board {
        position: relative;
        /*
           On limite la largeur du tableau pour ne pas pouvoir cliquer en
           dehors de la zone de jeu. Ça aurait pu être fait plus tôt mais on
           s’en fichait un peu puisque ça ne posait pas encore de problème.
        */
        width: calc(6 * var(--cell-size));
    }

    /*
       Rien de compliqué : .board-click-zone est positionné relativement à
       .board et le recouvre totalement, c'est donc bien lui qui va récupérer
       tous les clics. Oh, et on n'oublie pas le z-index pour nous assurer que
       ça passera par-dessus les entités.
    */
    .board-click-zone {
        position: absolute;
        top: 0;
        bottom: 0;
        right: 0;
        left: 0;
        z-index: 100;
    }

    /* ... */

    /* On s'assure que Meiko est toujours visible au-dessus des autres entités. */
    .board-cell-entity.meiko {
        z-index: 20;

        background-color: #fff;
        border: 2px solid green;
    }
</style>

Avec ça, on pourrait être content puisque Meiko peut désormais se déplacer, et cela avec peu de nouveau code. C’est sans compter un petit détail que les personnes connaissant VueJS ou autres bibliothèques de ce type auront peut-être remarquées : le store est un Object que l’on passe par référence à onClickSystem (enfin presque, je rentre pas dans les détails). La conséquence est que lorsqu’on modifie sa valeur, le store initial (stocké dans data) est également modifié et l’assignation dans onBoardClick n’a absolument aucun impact puisqu’on se contente de lui réassigner le même Object. Une manière de mieux comprendre est de modifier cette méthode :

onBoardClick(e) {
    const newStore = onClickSystem(e, this.store);
    console.log({
        oldPosition: this.store.meiko.position,
        newPosition: newStore.meiko.position,
    });
},

Ici j’ai logué la position de Meiko depuis le store initial ainsi que celle du nouveau store. J’ai également enlevé l’assignation à this.store. Si vous regardez le résultat dans une console, vous remarquerez toutefois que les deux valeurs sont identiques et que Meiko se déplace quand même : l’assignation n’avait donc bien aucun intérêt ! Ici il faut comprendre que VueJS ne devrait pas être capable de détecter un changement dans le store et donc d’actualiser la vue ; ce qu’il fait pourtant. La réponse à cette bizarrerie est donnée dans la documentation de VueJS qui nous explique que la valeur de l’objet data est gérée d’une manière un peu spéciale, permettant de surveiller les changements et donc de « réagir » à ceux-ci. C’est pratique, mais c’est accompagné d’avertissements importants concernant l’ajout ou la suppression de données dans cet objet qui ne sont pas, eux, détectés à moins d’utiliser des méthodes particulières. On peut illustrer cela en changeant légèrement le code de onClickSystem :

function onClickSystem(e, store) {
    e.preventDefault();

    // Ici on ne change plus la position de Meiko mais on tente de la supprimer
    delete store.meiko.position;

    return store;
}

Si vous tentez de voir ce que cela donne, vous verrez que Meiko ne bougera pas. Le résultat attendu est toutefois qu’il disparaisse car la méthode entityPosition est censée retourner un objet vide pour les entités ne possèdant pas de position (voir le deuxième article pour comprendre). Ici, VueJS n’a tout simplement pas détecté qu’il y avait eu un changement dans le store. La bonne manière de faire serait en fait de remplacer la ligne du delete par :

Vue.delete(store.meiko, 'position');

Ça marche, mais ce n’est finalement pas vraiment ce que je souhaite. En effet, ici les modifications dans le store vont être directement (ou presque) prises en compte par VueJS qui va impacter cela dans la vue. J’aimerais pour ma part pouvoir faire celles-ci par « lots » et assigner le nouveau store dans onBoardClick, comme je l’ai fait dans mon code. Mon idée est également de ne pas avoir d’effet de bord à l’intérieur de mon système. Celui-ci doit prendre un store en entrée, puis en retourner un en sortie sans toucher au premier. Cela facilite à mon sens la compréhension du code et l’écriture de tests.

Pour réaliser cela il faut dupliquer le store, mais c’est un peu pénible avec un Object JavaScript (c’était en tout cas mon avis à l’époque, mais je réalise maintenant que j’ai totalement surestimé la complexité, je reviens là-dessus en fin d’article). J’ai à ce moment-là pris la décision de revoir le format de données de mon store en le transformant en un Array, que j’aurai plus de facilité à manipuler. Cela demande toutefois quelques adaptations et il vaut mieux le faire dès maintenant alors que l’on a peu de code :

<div class="board">
    <!-- ... -->

    <!--
        Dans le template HTML, on change l'appel à `id` qui a été déplacé
        au sein des entités
    -->
    <div
      v-for="entity in store"
      :key="entity.id"
      :class="['board-cell-entity', entity.id]"
      :style="entityPosition(entity)"
    >
        <div v-if="entity.label" class="entity-label">
            {{ entity.label }}
        </div>
    </div>

    <!-- ... -->
</div>

<script>
    // On revoit la structure de données du store en le transformant en un
    // Array pour faciliter la manipulation des données.
    // Les anciennes clés qui servaient à identifier les entités sont déplacées
    // au sein des entités.
    let gameStore = [
        {
            id: 'meiko',
            label: 'Meiko',
            size: { width: 1, height: 1 },
            position: { x: 3, y: 2 },
        },

        {
            id: 'mozza',
            label: 'Mozzarella',
            size: { width: 1, height: 1 },
            position: { x: 1, y: 3 },
        },
        {
            id: 'tomato',
            label: 'Sauce tomate',
            size: { width: 1, height: 1 },
            position: { x: 2, y: 5 },
        },
        {
            id: 'dough',
            label: 'Pâte à pizza',
            size: { width: 1, height: 1 },
            position: { x: 5, y: 3 },
        },

        // etc.
    ];

    // ...
</script>

Ce changement est relativement indolore et a finalement assez peu d’impact (si ce n’est sur la rapidité d’exécution de certaines instructions). Par contre Meiko ne peut malheureusement plus bouger ! On va devoir faire une dernière adaptation au code :

function onClickSystem(e, store) {
    e.preventDefault();

    const x = Math.ceil(e.layerX / CSS_CELL_SIZE) - 1;
    const y = Math.ceil(e.layerY / CSS_CELL_SIZE) - 1;

    // On change la position de Meiko pour correspondre à l'endroit visé à
    // l'aide de la fonction écrite juste en dessous.
    const position = { x, y };
    let updatedStore = setEntityComponents(store, 'meiko', { position });

    // Et on retourne le store modifié
    return updatedStore;
}

// Cette fonction permet de modifier les composants d'une entité présente
// au sein d'un store, sans modifier ce dernier directement : un nouveau
// store est en fait retourné.
function setEntityComponents(store, id, components) {
    return store.map((entity) => {
        if (entity.id !== id) {
            return entity;
        }
        // Je ne rentre par contre pas dans le détail de la syntaxe
        // JavaScript...
        return {
            ...entity,
            ...components,
        };
    });
}

Et voilà, avec ça Meiko a désormais la possibilité de se déplacer en toute liberté dans sa cuisine. Et pour le coup il en a un peu trop puisqu’il est capable de passer d’un coin à un autre en un seul clic. Il peut également passer au-dessus des gros objets tels que le frigo, ce qui ne devrait pas être autorisé. J’avais imaginé traiter de ce sujet dans cet article, mais je me rends compte qu’il est déjà bien assez complet comme ça alors j’expliquerai comment contraindre les mouvements de notre personnage dans un prochain article !

Le code final de cet article est accessible ici (la console est toujours ton amie).

Pour terminer, je voulais revenir sur mon choix de changer de structure de données pour représenter mon store. Comme je l’ai précisé entre parenthèses, je réalise aujourd’hui que mon choix était insuffisamment justifié et j’aurais pu continuer avec un Object plutôt qu’un Array. L’impact immédiat est la complexité du code : pour accéder à mon entité meiko, je dois désormais parcourir les éléments de mon tableau un par un (complexité en O(n)), alors que je pouvais le récupérer directement avec un Object indexé par les identifiants des entités (complexité en O(1)). Ce changement est toutefois assez peu couteux dans ce jeu car nous aurons peu d’entités à manipuler (bien que nous en rajouterons plus tard).

J’ai décidé de conserver ce changement dans mon article pour trois raisons. La première est très basique : je reste proche de mon code initial. La seconde est d’illustrer que l’on ne fait pas toujours les bons choix d’implémentation du premier coup (surtout quand on tâtonne) et qu’il est pertinent de prendre du recul sur ce qu’on est en train de faire. C’est OK de revoir une structure de données, mais attention aux impacts que cela a sur le code ! Une suite de tests aurait pu être pertinente ici pour valider que nous n’avons pas de régressions dans les fonctionnalités.

Ma dernière raison est plus discutable : l’utilisation d’un Array permet de complexifier l’accès et la modification des entités, encourageant par la même occasion l’utilisation des fonctions utilitaires (ici, setEntityComponents). Je trouve cela utile car, comme on l’a vu, il faut absolument éviter d’ajouter ou supprimer un composant « à la main » dans les entités (au risque que VueJS ne détecte pas le changement). Un ou une nouvelle développeur·euse n’aura pas forcément conscience de cette particularité et perdra du temps à tenter de comprendre pourquoi son code ne marche pas. En lui empêchant certaines facilités, on l’encourage à découvrir comment ont fait les autres et on la pousse ainsi à utiliser les fonctions qui lui assure de le faire « correctement ». C’est une sorte d’ergonomie pensée à travers la complexité, je ne sais pas si ça a été théorisé mais c’est plutôt à-propos ! 😄

Cet article fait partie de la série « Ergogames, une histoire de pizzas ».

Retourner au blog