<figure><img src="image_1.png" /></figure>

HAL
open science

Design et développement du jeu sérieux Transkey

Thibaut Coudroy

► To cite this version:

Thibaut Coudroy. Design et développement du jeu sérieux Transkey. Informatique [cs]. 2024. hal-04867680

HAL Id: hal-04867680

https://inria.hal.science/hal-04867680v1

Submitted on 6 Jan 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Master of Science in Informatics at Grenoble
Specialty "Distributed Computing"

Design et développement
du jeu sérieux Transkey

Thibaut COUDROY

22/08/2024

<figure><img src="image_3.png" /></figure>

RÉPUBLIQUE
FRANÇAISE

Liberté
Égalité
Fraternité

<figure><img src="image_4.png" /></figure>

Projet de recherche réalisé au centre INRIA de l'Université Grenoble Alpes

Sous la supervision de :

Mathilde BOISSIER

Défendu devant un jury constitué de :

Bruno RAFFIN (Président)

Martin HEUSSE

Carole ADAM (Experte externe)
<figure><img src="image_5.png" /></figure>
Abstract

In an era where environmental issues are critical, serious games have proven to be
an effective way to learn by allowing players to experiment and debate around various
situations. However, few of these games explicitly involve both resource flow management
and the impact of a territory's network of actors. The Transkey model connects these two
aspects, and this report presents the creation of a serious game based on this model.

We establish the concepts of our game, designed to be multiplayer, which presents
political and biophysical phenomena encountered in territorial management. We then focus
on developing the digital version of the game, with a server and a web client that allows
the game to be easily accessible from different devices simultaneously. This version is also
modular and can be adapted to various territories without code modification.

We highlight the differences that emerge between the digital and the physical versions,
developed in parallel. This includes the perception of information and the ability, in the
digital version, to dynamically generate diagrams accessible to players during the game.

This project resulted in a stable game version that we tested in half a dozen experiments.
It successfully presents the phenomena encountered in our territories and also serves as a
tool to learn how to read and interpret Sankey diagrams.

Résumé

À l'heure où les enjeux environnementaux sont cruciaux, une des façons de sensibiliser et de susciter l'action est l'utilisation de jeux sérieux. Ils sont une manière efficace d'apprendre en permettant aux joueurs d'expérimenter et de débattre autour des situations rencontrées. Cependant, peu de ces jeux font intervenir explicitement à la fois la gestion des flux de ressources et l'impact du réseau d'acteurs d'un territoire. Le modèle Transkey relie ces deux aspects et nous présentons dans ce rapport la création d'un jeu sérieux basé sur ce modèle.

Nous établissons les concepts de ce jeu multi-joueurs qui présente des phénomènes ren-
contrés, au niveau politique et biophysique, dans la gestion d'un territoire. Puis, nous nous
concentrons sur la réalisation de la version numérique du jeu avec un serveur et un client
web permettant au jeu d'être facilement accessible depuis différents appareils en simultané.
Cette version est aussi modulable, permettant d'adapter le jeu à différents territoires sans
modifier le code.

Nous mettons en évidence les différences qui émergent entre la version numérique et la version physique, développée en parallèle. Cela concerne notamment la perception des informations et la possibilité, pour la version numérique, de générer dynamiquement des diagrammes accessibles aux joueurs lors de la partie.

Ce projet a abouti en une version du jeu stable que nous avons pu essayer dans une
demi-douzaine d'expérimentations. Elle permet avec succès de présenter des phénomènes
que nous rencontrons dans nos territoires et est également un moyen d'apprendre à lire et
interpréter des diagrammes de Sankey.
Engagement de non-plagiat

Nous certifions que le contenu de ce rapport a été produit par les soins de Thibaut COUDROY et ne contient aucun plagiat. Les sources externes utilisées sont citées et accessibles via la bibliographie.

Thibaut COUDROY

<figure><img src="image_6.png" /></figure>

Mathilde BOISSIER

Remerciements

Je tiens à remercier tout particulièrement ma maître de stage Mathilde BOISSIER pour
son encadrement et son accompagnement dans l'ensemble du développement et des tests
du jeu. Merci également à Nicolas REVILLA-LOPEZ, mon binôme de stage avec qui j'ai
partagé ce projet, ainsi qu'à celles et ceux qui ont contribué au développement de ce jeu.

Un grand merci aux structures externes qui nous ont accueillies chaleureusement pour
effectuer nos tests (La MADRE, Alternatiba, La MaCI). Enfin, merci à tous les volontaires
qui ont participé à nos sessions de jeux avec bienveillance et qui nous ont permis d'améliorer
notre produit.
# Sommaire

## 1 Introduction 7

1.1 Contexte du stage 7

1.2 Problématique 7

1.3 Approche scientifique et résultats 8

1.4 Contenu du rapport 9

## 2 Les jeux sérieux comme support aux phénomènes biophysiques 12

2.1 Analyse de la pratique du jeu sérieux 12

2.2 Études de jeux sérieux en lien avec l'environnement 14

2.3 Exemple de création de jeux sérieux sur des phénomènes biophysiques 15

2.4 L'approche Nexus pour relier les flux 16

2.5 Bilan 16

## 3 Développement des concepts du jeu 17

3.1 Analyse de la première version du jeu 17

3.1.1 Présentation de la première version 17

3.1.2 Synthèse et perspectives d'évolution 18

3.2 Nouveaux concepts 20

3.2.1 Fonctionnement global 20

3.2.2 Unicité des territoires et objectifs individuels 20

3.2.3 Gestion du territoire 21

3.2.4 Échanges de ressources 21

3.2.5 Emplois et hébergement 22

3.2.6 Aléas 22

3.3 Mise en place d'une phase de debriefing 23

## 4 Développement de la version numérique 24

4.1 Prise en main du jeu développé 24

4.2 Refonte de la structure logicielle 24

4.3 Développement du serveur 26

4.3.1 Implémentation du modèle 26

4.3.2 Initialisation d'une partie 27

4.3.3 Implémentation du contrôleur 28

4.3.4 Évaluation et validation du serveur 29

4.4 Développement du client 31

4.4.1 Implémentation du client 31

4.4.2 Plateau de jeu central 32

4.4.3 Ergonomie et accessibilité 33

## 5 Différences entre plateau et numérique 35

5.1 Solutions face aux inconvénients du support numérique 35

5.1.1 Échanges de ressources entre les joueurs 35

5.1.2 Évolution des ressources 36

5.2 Visualisation de l'information 37
<table><tbody><tr><td>5.2.1 Documentation sur la représentation de flux</td><td>38</td></tr><tr><td>5.2.2 Représentation de l'information au sein d'un territoire</td><td>39</td></tr><tr><td>5.2.3 Représentation de l'information entre les territoires</td><td>41</td></tr><tr><td>5.2.4 Validation des visualisations</td><td>43</td></tr><tr><td><strong>6 Expérimentations</strong></td><td><strong>44</strong></td></tr><tr><td>6.1 Processus d'expérimentation</td><td>44</td></tr><tr><td>6.2 Sessions pendant le développement</td><td>45</td></tr><tr><td>6.3 Mise à l'épreuve de la version actuelle</td><td>45</td></tr><tr><td>6.3.1 Déroulement des sessions</td><td>46</td></tr><tr><td>6.3.2 Bilan de la version actuelle</td><td>46</td></tr><tr><td><strong>7 Conclusion</strong></td><td><strong>48</strong></td></tr><tr><td>7.1 Bilan du projet</td><td>48</td></tr><tr><td>7.2 Bilan personnel</td><td>49</td></tr><tr><td><strong>Références</strong></td><td><strong>50</strong></td></tr><tr><td><strong>Annexes</strong></td><td><strong>51</strong></td></tr><tr><td><strong>A Présentation visuelle du jeu de plateau</strong></td><td><strong>51</strong></td></tr><tr><td><strong>B Exemple de fichiers de configuration</strong></td><td><strong>52</strong></td></tr></tbody></table>
# 1 Introduction

## 1.1 Contexte du stage

Mon projet de fin d'études a été réalisé au sein de l'équipe STEEP (Soutenabilité, Territoires, Environnement, Économie et Politique) du centre INRIA de l'Université Grenoble Alpes. L'équipe développe des d'outils d'aide à la décision grâce à des logiciels faisant intervenir des modélisations, des simulations et des visualisations. Ces produits sont en-suite utilisés dans le cadre de décisions territoriales et de transition vers la soutenabilité. STEEP s'inscrit donc dans la prospective (ensemble de recherches sur l'évolution future de nos sociétés) et apporte des éléments de réponse concrets face aux questionnements sur l'avenir d'un territoire. L'équipe a principalement deux axes de recherche : AST (Alternatives Sociotechniques), auquel mon stage se rattache, et RSG (Risques Systémiques Globaux).

Pour réaliser ses outils, l'équipe prend en compte différents facteurs (social, environnement, économie) et effectue des modélisations systémiques, c'est-à-dire d'un système vu sous son ensemble et non pas sous le prisme d'une seule thématique. Ainsi, les influences et interactions qui existent entre ces facteurs sont mises en évidence.

## 1.2 Problématique

Face aux défis environnementaux et sociétaux de notre ère, il nous faut repenser l'organisation de nos territoires afin d'assurer leur transition vers des systèmes plus durables. Pour répondre à ces enjeux, notre rôle de scientifique dans le domaine de la prospective est de sensibiliser les citoyens aux différentes alternatives sociotechniques. Il s'agit de scénarios envisageables pour l'avenir et présentant des modes de consommation et de production différents.

D'après Sweeney et al. [1], une façon de contribuer à ces réflexions et d'engager la réalisation des changements nécessaires est l'utilisation de jeux sérieux. Ces jeux permettent à leurs participants de mener des réflexions et de se projeter sur les différents choix envisageables au sein d'un territoire et ont lieu en deux phases. La première est le déroulé d'une partie comme dans un jeu de société classique. La seconde phase consiste à effectuer un debrief de cette partie et permet alors aux joueurs de débattre et d'exprimer leur ressenti, tout en faisant le parallèle entre les situations observées dans le jeu et les phénomènes réels. Les jeux sérieux sont donc un vecteur de transmission de savoir ludique et également un processus participatif qui permet d'aborder des problématiques en groupe.

Parmi les jeux sérieux, peu proposent de discuter à la fois de la manipulation des flux de ressources et des liens avec le réseau d'acteurs. Pourtant, ces flux biophysiques sont intrinsèquement liés aux choix sociaux et aux décisions des acteurs, parfois conflictuels. Le modèle Transkey [2] développé par l'équipe permet de prendre en compte ces deux axes et de mettre en lumière des effets systémiques qui en émergent.

Le cœur de nos stages, réalisés en binôme avec Nicolas REVILLA-LOPEZ, est la conception d'un jeu sérieux multi-joueurs intégrant le modèle Transkey. Dans celui-ci, chaque
joueur est responsable d'un territoire et de ses ressources que les joueurs peuvent s'échanger. Au sein de ces territoires, des activités peuvent être placées et permettent de transformer les ressources. Plus particulièrement, mon stage a aussi permis d'explorer la pertinence d'utiliser un jeu sérieux au format numérique et comprenant l'affichage de visualisations des flux générées dynamiquement, l'autre stage se concentrant principalement sur la conception des mécaniques du jeu.

## 1.3 Approche scientifique et résultats

Pour la réalisation de ces travaux, l'approche a d'abord consisté à accumuler des connaissances sur plusieurs disciplines afin de comprendre les concepts clés exposés dans le jeu. Ces renseignements ont permis d'assimiler les mécanismes liés aux flux biophysiques ainsi que leur lien avec le réseau d'acteurs.

Cette phase préliminaire a également permis d'analyser d'autres réalisations de jeux sérieux dans des contextes de gestion de territoires face à des enjeux environnementaux. En particulier, un jeu développé par l'équipe l'année précédente a été étudié. Il s'agit d'une première implémentation numérique du modèle Transkey, mais limitée à une utilisation mono-joueur.

Suite à cette appropriation du sujet, nous avons développé les mécaniques du jeu pour répondre aux attentes de notre sujet et, en parallèle, j'ai eu pour mission de réaliser la version numérique. Pour celle-ci, la solution développée est un jeu web multi-joueurs. Le serveur est conçu sur Python et les pages web, interactives avec JavaScript, permettent aux joueurs de se connecter et jouer directement depuis leur navigateur. Une attention particulière est apportée à l'étude des différences entre un jeu de plateau et son équivalent numérique et plus précisément à la visualisation de l'information possible grâce au support informatique. Concrètement, des diagrammes de Sankey et autres visuels sont réalisés dynamiquement et affichés aux joueurs. Le jeu permet alors de s'approprier la lecture de ces diagrammes qui mettent en évidence des phénomènes sur les ressources et les acteurs, comme la dépendance entre les territoires ou la concurrence d'usage de ressource, c'est-à-dire les choix sur l'utilisation d'une ressource en quantité limitée. Ces diagrammes peuvent être utilisés par les joueurs pendant la partie pour affiner leurs stratégies ou lors de la phase de debriefing où ces visuels peuvent témoigner des choix sociaux et leurs impacts sur les flux de matières.

Cette solution numérique est évaluée à la fois par des tests automatisés pour valider le fonctionnement des mécaniques du jeu et aussi lors d'expérimentations du jeu. Dans celles-ci, nous observons la compréhension de la part des joueurs et nous prenons en compte leurs retours afin de proposer une expérience de jeu plus agréable et qui met en avant les phénomènes systémiques que nous souhaitons représenter. Ces expérimentations ont été effectuées avec des groupes de volontaires sur les versions physique et numérique du jeu.

Les travaux de mon stage ont permis la réalisation d'une version numérique stable et permettant très simplement l'édition et la création d'une configuration de jeu. Il est ainsi très facile de l'adapter à certains territoires sans nécessité de modifier le code. Dans les deux versions du jeu, des phénomènes biophysiques transposables à des situations réelles
apparaissent. Les mécaniques du jeu permettent aux joueurs de faire des choix sociaux et d'évaluer différentes alternatives sociotechniques qui peuvent faire face aux problématiques qui découlent du réseau d'acteurs et de la gestion des ressources. La présence des visualisations et diagrammes de Sankey accompagnent l'apprentissage sur la version numérique, et le jeu peut permettre d'apprendre la lecture de ceux-ci pour comprendre les limites biophysiques d'un système.

Le développement du jeu peut être poursuivi suite à ces travaux, en prenant appui notamment sur les observations que nous avons faites lors des expérimentations. En effet, le jeu présente des limites dues aux choix de conception et d'abstraction que nous avons faits pour modéliser des situations. Il en résulte des stratégies de jeu qui semblent trop avantageuses ainsi que des faux messages perçus par les joueurs que nous ne souhaitons pas transmettre.

## 1.4 Contenu du rapport

### 2 Les jeux sérieux comme support aux phénomènes biophysiques

Dans ce rapport, nous commençons par une analyse des jeux sérieux en tant que support à l'apprentissage des phénomènes biophysiques pour identifier les pistes explorées lors du stage. Cette partie présente des concepts issus de différents champs académiques sur lequel le jeu développé s'appuie. D'abord, nous mettons en contexte les rôles et utilisations des jeux sérieux ainsi que leurs caractéristiques. Cette forme d'apprentissage présente des particularités, notamment dans son côté interactif avec les utilisateurs et de processus participatif. Puis nous observons plus précisément des exemples de jeux basés sur les enjeux environnementaux et le développement des territoires. Ensuite, nous regardons des exemples de jeux sérieux développés pour montrer des phénomènes biophysiques. Ils font intervenir les flux de matières pour observer les transformations des ressources avec les activités humaines et la façon dont ces flux évoluent selon les choix sociaux de consommation et production. Enfin, nous développons l'approche Nexus qui vise à considérer l'ensemble des secteurs (agricole, énergie, ...) lors de l'analyse. Ils sont en effet souvent analysés séparément, ce qui omet par conséquent leurs interactions, cruciales pour la compréhension du système.

### 3 Développement des concepts du jeu

Ce chapitre explicite les règles et mécaniques du jeu. En premier, nous voyons une version du jeu développée précédemment et ses limites, identifiées lors d'expérimentations en amont du stage. Elle sert de base concernant la transformation des ressources et les alternatives présentées aux joueurs mais présente des lacunes notamment sur les dépendances territoriales et le réseau d'acteurs car le jeu n'est pas adapté au multi-joueurs.

Puis, en prenant appui sur l'état de l'art et les observations précédentes, nous regardons comment le design de notre version doit répondre aux attentes du sujet de stage. Nous présentons les objectifs que nous nous sommes fixés dans la conception du jeu. Ils concernent notamment les phénomènes biophysiques que nous souhaitons représenter et la façon dont se déroule la partie en multi-joueurs, avec une notion temporelle pour que les
territoires évoluent au cours de la partie. Par la suite, ces concepts sont traduits dans les règles et mécaniques du jeu qui permettent aux joueurs d'acquérir des connaissances sur la gestion des territoires et les compromis nécessaires entre différents critères. Pour chaque mécanique, nous précisons sa plus-value pour les joueurs et les situations biophysiques et sociales que nous souhaitons représenter. Dans le contexte de jeu sérieux, nous présentons ensuite la phase de debriefing de la partie. Les joueurs sont alors invités à revenir sur des évènements de la partie pour les comparer à la réalité. C'est à ce moment que les situations vécues dans le jeu se transforment en apprentissage et permettent une meilleure compréhension de nos systèmes.

# 4 Développement de la version numérique

Ce chapitre développe la réalisation de l'implémentation numérique du jeu. Afin de fonctionner correctement en multi-joueurs, l'architecture logicielle privilégiée est le MVC (Modèle-Vue-Contrôleur). Elle permet ainsi de séparer le modèle, qui correspond à l'exécution des règles du jeu et stockage des données, et le client développé pour navigateur web (dit la vue dans cette architecture). L'intermédiaire de communication entre ces deux éléments est le contrôleur dont l'API (Interface de Programmation d'Application) permet d'établir le format des requêtes et réponses entre le client web et le serveur.

La structuration du serveur est d'abord détaillée avec les différentes classes et leurs interactions. Puis, une section traite de la modularité du jeu et la possibilité d'adapter la configuration d'une partie, stockée dans des fichiers au format YAML, sans besoin d'apporter des modifications au code. La création de ces configurations de jeu permet de tester simplement différents équilibrages et mécaniques. De plus, elles peuvent s'adapter au contexte dans lequel le jeu est utilisé en modifiant les ressources et les activités présentes et ainsi faciliter la mise en parallèle entre les phénomènes dans le jeu et les situations réelles pour un territoire donné.

Le chapitre se concentre ensuite sur l'implémentation du client web et notamment son affichage. Celui-ci répond au besoin de créer une expérience de jeu agréable et proche de la version plateau en étant au maximum ergonomique et simple d'utilisation.

# 5 Différences entre plateau et numérique

En plus de son implémentation numérique, le jeu se présente aussi sous une forme de jeu sur plateau. Les différences entre ces deux formats sont traitées dans cette section.

D'abord, des solutions sont apportées aux inconvénients de la version numérique. Une interface est développée pour permettre aux joueurs d'échanger des ressources, et des ajouts visuels atténuent le manque de perception des données qui survient car celles-ci sont seulement représentées par des chiffres, là où les pions sur un plateau prennent du volume.

Ensuite, nous étudions la génération de visualisations grâce à l'informatique. En accumulant les données lors du jeu, des diagrammes de Sankey et de réseau permettent de représenter les informations des flux. Ces visuels sont générés à l'échelle d'un territoire pour observer ses transformations de matière mais également entre les territoires pour voir les dépendances aux ressources des autres joueurs. Nous discutons aussi de l'accueil de ces
diagrammes par les joueurs et de leur pertinence à la fois en les utilisant pendant la partie et aussi en tant que support pour le debrief.

# 6 Expérimentations

Dans le développement d'un jeu sérieux, les expérimentations avec les utilisateurs sont au cœur du processus de création. Dans notre stage, elles ont été réalisées avec des volontaires, majoritairement du monde académique et / ou sensibilisés aux enjeux environnementaux. Ces sessions ont d'abord permis de tester régulièrement des mécaniques et des règles pour vérifier quels messages étaient transmis aux joueurs et si le jeu était engageant. Elles ont aussi pointé les limites du jeu et de l'interface numérique qui a pu être améliorée en conséquence pour faciliter la prise en main du jeu.

Par la suite, nous avons réalisé une série d'expérimentations sur une version stable du jeu afin de dresser un bilan de son état actuel. Nous notons les éléments qui ont fonctionné et accompagné les joueurs dans la compréhension des phénomènes biophysiques que nous souhaitions mettre en avant mais aussi les éléments qui ont moins fonctionné dans ces sessions.

# 7 Conclusion

En conclusion de ce rapport, nous faisons le bilan du travail réalisé dans ce stage et de l'état actuel du jeu. Nous repassons en revue le processus de création et les travaux qui l'ont alimenté et portons un point d'attention particulier à la réalisation de la version numérique et comment sa structure actuelle peut lui permettre d'évoluer. Enfin, nous regardons les pistes d'amélioration que nous avons identifiées grâce aux expérimentations et qui pourront servir d'axe de développement pour les prochaines versions du jeu.
# 2 Les jeux sérieux comme support aux phénomènes biophysiques

Les jeux sérieux sont développés pour permettre aux joueurs de mieux comprendre des phénomènes du monde réel. Dans cet état de l'art, nous regardons d'abord comment cette forme particulière d'apprentissage se profile et pourquoi elle est pertinente dans plusieurs domaines. Puis nous nous focalisons sur des exemples en lien avec l'environnement ainsi que sur le processus de création d'un jeu sérieux sur cette thématique. Enfin, nous abordons l'approche Nexus, qui illustre l'importance de considérer les connexions entre les différentes ressources et qui permet ainsi de vulgariser des phénomènes biophysiques identifiés grâce à cette vision.

Cette phase d'apprentissage a été riche et diverse, sollicitant la compréhension de concepts dans différentes disciplines afin de saisir les enjeux du stage et des jeux sérieux. Ainsi, en plus de l'étude d'exemples de jeux sérieux numériques, le design de jeu sérieux et les phénomènes sociaux et environnementaux qui peuvent être représentés à travers un tel jeu ont été étudiés.

## 2.1 Analyse de la pratique du jeu sérieux

Premièrement, il est essentiel de comprendre dans quel cadre les jeux sérieux sont développés et utilisés. Un document de Nicolas BECU, spécialiste de ce domaine, aborde la pratique des jeux sérieux et de la simulation participative [3]. Dedans, il y retrace leur émergence et leur démocratisation et établit les fondements de leur conception et utilisation.

Ces outils sont une façon d'apprendre et de transmettre du savoir, au même titre que des graphiques, des simulations ou des articles par exemple. Tous ces moyens permettent une diffusion des connaissances, mais le jeu présente une particularité. Il est un moyen engageant d'apprendre car les participants ne sont pas spectateurs d'une information présentée mais au contraire peuvent agir sur le déroulé des évènements. L'apprentissage est alors ludique et stimulant, d'autant plus dans le cadre multi-joueurs où il peut entraîner des discussions et critiques. Le terme de "jeu" est interprété dans le sens où les actions n'ont aucune conséquence sur la réalité, c'est-à-dire qu'on se place dans un imaginaire où il est possible d'explorer différentes pistes.

Au sein de la littérature, on retrouve régulièrement des indicateurs et outils utilisés dans l'analyse et le design de jeux. Plusieurs se basent sur le pentagone ludique [4] (Figure 1) de Gilles BROUGÈRE, où le jeu est analysé sur cinq dimensions :

* **Second degré** : On fait semblant en se plaçant dans un cadre distinct de la réalité.

* **Frivolité** : Impliqué par le second degré, les actions dans le jeu n'ont pas de conséquences sur la vraie vie, ainsi le jeu est permissif et donne des libertés aux joueurs qui peuvent explorer différentes pistes.

* **Décision** : Les joueurs prennent part aux décisions et ne sont pas spectateurs.
* **Mécanismes de décision** : Ce sont les règles du jeu et / ou accords entre les joueurs qui établissent les décisions possibles.

* **Incertitude** : On joue sans connaître à l'avance le résultat du jeu.

<figure><img src="image_7.png" /><figcaption>Figure 1: Le pentagone ludique de Gilles BROUGÈRE</figcaption></figure>

Avec ces différents critères, le pentagone met en évidence la façon dont un jeu peut être efficace pour transmettre des connaissances. Il permet aux joueurs de s'engager dans une partie et de "faire semblant" avec une liberté d'exploration des possibilités sans quelconque incidence réelle.

Le déroulé de l'expérience du jeu sérieux ne se repose pas uniquement sur le fait de jouer une partie. La phase de debriefing, qui a lieu après la partie et où les joueurs sont amenés à discuter, fait partie de l'enseignement. Animé par la personne qui encadre l'atelier, ce temps d'échange est d'une durée inférieure ou similaire au temps de jeu et sert à transformer le vécu en apprentissage. En observant ce qu'il s'est passé lors de la partie et en transposant cela à la réalité, les joueurs peuvent exprimer leurs émotions et voir les actions qui peuvent être concrètement menées dans des situations réelles, en ayant une meilleure connaissance des éléments qui constituent la problématique exposée. Ce debrief peut prendre plusieurs formes (papier ou oral, dirigé ou non par l'encadrant de l'atelier, ...).

Dans un des chapitres du document de BECU qui se concentre sur le processus de création et calibration des jeux sérieux, il est mention d'un choix de modélisation concernant la fidélité aux vraies données. Il est possible de chercher à s'approcher le plus des données biophysiques, mais il est également envisageable de s'en éloigner afin de simplifier le système tout en conservant les messages. Face à cet enjeu important du réalisme, nous avons fait le choix de simplifier les données afin qu'elles représentent des phénomènes réels sans pour autant être exactes. Par exemple, une alimentation exclusivement végétarienne dans le jeu demande une surface de production de nourriture inférieure à une alimentation omnivore. Cette différence n'est pas nécessairement fidèle aux données réelles mais elle aide le retour à la réalité où on constate effectivement un grand écart entre ces deux modes de consommation. En s'affranchissant de cette contrainte de réalisme, les joueurs sont moins focalisés sur la justesse des données et nous avons également plus de liberté dans l'équilibrage des alternatives afin que plusieurs soient explorées par les joueurs. Cet
enjeu d'équilibrage est important afin d'avoir une expérience de jeu à la fois agréable et permissive sur les choix, comme le montrent Wang et al. [5] dans leur analyse de jeux vidéo et où le facteur "Diversité des situations" est parmi les cinq les plus importants dans l'expérience.

Enfin, des directives sur l'efficacité d'un jeu sérieux sont évoquées. Il doit convenir aux attentes des joueurs et évoluer au besoin pour se transposer aux situations étudiées, c'est-à-dire que le design doit avoir une certaine souplesse pour que le jeu soit adapté à une situation voire qu'il puisse offrir des libertés aux joueurs s'ils s'accordent sur des fonctionnements. Pour cette dernière étape, un jeu de plateau est bien plus propice à cette liberté qu'une implémentation numérique qui est de fait contrainte par les possibilités envisagées. Aussi, la phase de debriefing ne doit pas être uniquement réservée à la comparaison avec la réalité, mais elle doit aussi permettre de comprendre les limites du jeu sérieux et permette l'évolution futur qu'il doit suivre pour mieux répondre aux objectifs.

## 2.2 Études de jeux sérieux en lien avec l'environnement

De nombreux jeux sérieux ont déjà été développés par le passé, notamment sur les thématiques environnementales et de gestion de territoire. Ils ont pu être utilisés dans le cadre de décisions politiques en permettant aux participants d'aborder le problème sous différents points de vue, en comprenant les intérêts des différents acteurs et en prenant en considération l'environnement. Une part majeure de ces jeux sont créés sur mesure pour répondre à un besoin particulier tout en modélisant les contraintes du territoire ainsi que sa politique actuelle.

Des projets qui illustrent les notions de gestion de territoire sont les suivants. Pour certains, ils sont accessibles depuis les plate-formes ComMod [6] et Gamae [7] qui répertorient des jeux sérieux développés en lien avec l'environnement à différentes échelles.

* **La Grange [8] (Gamae):** Dans ce jeu, les joueurs collaborent pour développer un élevage. Chacun d'eux s'occupe d'une dimension différente (parcelles, animaux, emploi, ...). Le jeu possède beaucoup de pions de nature différentes (forêts, animaux, infrastructures, environnement, ...).

* **MigrationS [9] (Gamae):** Le but est de protéger une population de poisson. Les joueurs ont des actions individuelles, mais la gestion est commune et la victoire est collective. La collaboration est nécessaire pour gagner.

* **Kung Krabaen Bay [10] (ComMod):** Jeu développé pour faire face à une crise d'un écosystème en Thaïlande où le rendement de la pêche a fortement diminué. Des tensions existaient entre les différents acteurs et le jeu, accompagné d'une simulation informatique, avait pour vocation de créer de la confiance entre eux.

* **My River Kit [11] (UMR G-EAU):** Jeu de ressources basé sur la gestion de l'eau d'une rivière. Celle-ci a une certaine quantité d'eau qui peut être redirigée vers différentes activités qui transforme les ressources. Un aspect géographique est représenté : l'eau parcourt le plateau et les activités sont placées tout au long de la rive.
Des points communs entre ces jeux sont l'avantage pour les joueurs de communiquer et jouer de manière coopérative. Les différentes forces de chacun et les compromis sont bénéfiques au développement du territoire. De plus, l'asymétrie des rôles entre les joueurs et les déséquilibres qu'elle implique les encourage à interagir. Ces situations-là, où les objectifs et intérêts de chacun diffèrent, sont souvent transposables à la réalité où les personnes amenées à jouer aux jeux sérieux peuvent provenir d'horizon divers et n'ont pas nécessairement les mêmes valeurs.

Un autre point présent dans certains de ces jeux est l'explicitation des règles et des mécanismes. Dans certains cas, il est pertinent de cacher ces informations afin de créer l'effet de surprise et observer comment les acteurs s'adaptent à une situation inédite et non anticipée ou encore constater leur compréhension de ces règles. Cependant, garder ces éléments flous peut aussi être frustrant pour les joueurs quand les résultats sont contraires à leurs attentes ou qu'ils n'arrivent pas à trouver une logique. Il est donc nécessaire de prendre en compte cet aspect dans le processus de création d'un jeu et de veiller aux informations qui sont communiquées aux joueurs. La calibration peut également faire intervenir l'accès aux informations.

## 2.3 Exemple de création de jeux sérieux sur des phénomènes biophysiques

Dans le travail de conception de ce jeu sérieux, nous cherchons en particulier à jouer avec les flux de matières, d'énergie et les contraintes qui leurs sont associées. C'est aussi l'objectif du travail de Léa VIENOT qui a développé des jeux pour mettre en évidence des effets systémiques mis en avant par la comptabilité biophysique et a documenté son processus de création [12].

Au sein de ce document, la stagiaire parle également de l'intégration d'AFM (Analyse Flux Matières) dans les jeux. Ce sont des représentations visuelles, sous forme de diagrammes et graphiques, pour faire le bilan biophysique des flux de matières et peuvent aider à observer les interactions entre les secteurs et les transformations de ressources. Les jeux peuvent alors permettre d'apprendre à lire ces diagrammes et comprendre comment les choix de production et consommation les font évoluer. Dans notre cas, des visualisations sont générés lors de la partie pour observer ces flux et sont utiles à la fois pendant la partie et lors de la phase de debriefing.

Dans ce rapport, il est également présenté comment les mises à l'épreuve des versions préliminaires du jeu font partie intégrante de leur développement. Cela m'a fait prendre conscience de l'aspect primordial des retours intermédiaires afin d'évaluer si le jeu réalise ses missions. Dans le processus de création, il est nécessaire de mettre régulièrement le jeu à l'épreuve pour le faire évoluer et le calibrer. Avec ces tests intermédiaires et une observation méthodique, les points d'amélioration sont identifiés pour que le jeu réponde plus facilement aux objectifs.
## 2.4 L'approche Nexus pour relier les flux

L'idée de l'approche dite Nexus est d'intégrer et montrer l'interconnexion de différents indicateurs et ressources (par exemple l'eau, la nourriture et l'énergie) tout en mettant aussi en évidence les dimensions sociales et économiques [13]. Dans une analyse secteur par secteur, certains phénomènes ne sont pas mis en évidence. Il est alors possible d'analyser la problématique avec une vue d'ensemble et qui permet d'identifier l'influence des flux sur d'autres. Par exemple, un changement des moyens de production de nourriture peut influencer la consommation d'eau et le secteur de l'énergie ainsi que les coûts à différents niveaux.

Plusieurs jeux numériques utilisent déjà le concept de Nexus au sein de leur mécaniques et certains sont centrés autour de cette question d'équilibre entre différentes ressources. Deux de ces exemples sont les jeux sérieux Sim4Nexus [13] et MAGIC Nexus [14] qui intègrent plusieurs ressources (eau, énergie, nourriture et terrains). Dans Sim4Nexus, les actions du joueurs sont la mise en place de mesures politiques et il est ensuite possible d'observer leurs conséquences sur les années suivantes. Dans MAGIC Nexus, il est davantage question de faire des choix sur la répartition des moyens de production mais aussi sur les habitudes de consommation d'énergie et de nourriture des habitants au sein de différent territoires en Europe. Celle-ci est séparée en 4 régions qui présentent des propriétés différentes (densité de population, consommation de viande et poissons). Des échanges entre les territoires, parfois bénéfiques pour pallier aux désavantages géographiques, sont possibles. Le jeu est ainsi plus proche de la simulation (un document répertorie le processus d'agrégation des données utilisées [15]) et il présente un bilan plus complet avec une multitude d'étapes dans les processus de transformation de ressources (exemple avec la nourriture : perte à la production, gâchis alimentaire, ...).

## 2.5 Bilan

Grâce à ces lectures, j'ai pu avoir des clés de compréhension pour analyser les retours actuels faits au jeu développé avant mon stage et dont j'ai poursuivi le développement. À l'aide de l'état de l'art, des documents synthétisant ces retours et aussi de discussions avec l'équipe et des intervenants, mon binôme et moi avons pu identifier les finalités souhaitées par l'équipe et comprendre les axes à prioriser pour mes missions, qui sont les suivants :

* Créer et adapter des mécaniques pour le multi-joueurs, afin d'avoir des dynamiques sur les ressources comme des dépendances entre les territoires.

* Implémenter un aspect temporel avec un jeu se déroulant en plusieurs tours et en plusieurs phases, pour permettre la mise en place d'un système biophysique équilibré. Des visualisations et diagrammes doivent mettre en évidence la nécessité d'une approche Nexus quand on souhaite interpréter les flux de ressources.

* Développer des mécaniques de jeu pour perturber le système biophysique dès lors qu'il est stable afin de mettre en évidence d'autres phénomènes dont la résistance aux chocs et l'adaptation des flux pour répondre aux nouveaux besoins.
# 3 Développement des concepts du jeu

Le jeu, sous ses versions plateau et numérique, possède une multitude de mécaniques et règles qui ont chacune pour objectif d'aider à la compréhension de différents situations qui peuvent arriver dans nos sociétés. Dans cette section, nous regardons d'abord le fonctionnement du jeu précédent ainsi que ses limites. Puis, nous listons les nouveaux concepts que nous avons mis en place et leurs buts. Nous reviendrons sur leur efficacité dans la section concernant les expérimentations, où nous avons pu obtenir des retours utilisateurs.

## 3.1 Analyse de la première version du jeu

Le jeu que nous avons développé se base sur un précédent jeu de l'équipe réalisé l'an passé. Avant de développer de nouveaux concepts, il est nécessaire de prendre en main l'outil déjà existant et analyser ses limites afin de le faire évoluer pour répondre à ce que nous souhaitons modéliser. Dans cette section, nous présentons les mécaniques du jeu puis nous apportons un regard critique pour déterminer ce que nous souhaitons ajouter.

### 3.1.1 Présentation de la première version

La version du jeu développée par l'équipe est disponible au format numérique et est adaptée à une utilisation mono-joueur (Figure 2). Le joueur est incité à placer des activités sur son territoire qui consomment et produisent des ressources, modifiant ainsi les flux de matières et les indicateurs de pollution.

<figure><img src="image_8.png" /><figcaption>Figure 2: Capture d'écran d'une partie mono-joueur du jeu développé en 2023 [16]</figcaption></figure>
Le joueur est amené implicitement à faire des choix, comme le développement d'activités agricoles intensive ou extensive, la manière de produire de l'énergie, ... Ces choix sont dirigés par ses convictions personnelles, car le jeu ne présente pas d'objectifs, et sont calibrés pour avoir des avantages et inconvénients. Le jeu montre comment les choix sociaux et politiques influent sur le contexte biophysique. Il présente des phénomènes systémiques comme la concurrence des ressources, puisque le joueur ne reçoit que de l'eau et des terrains au début du tour. Des compromis entre les activités sont alors nécessaires car il n'est pas possible d'obtenir un territoire répondant à toutes les problématiques présentées.

Le jeu est limité à un seul tour où le joueur place des activités sur un territoire vierge, les notions de stockage ou d'amortissement des activités ne sont donc pas présentes. Les flux de ressources sont les productions de territoires, ainsi que les importations et exportations visibles à la fin du tour. Le joueur est invité à effectuer plusieurs parties où il peut librement effectuer des choix différents et mesurer leurs impacts. Ainsi, la méthode d'apprentissage privilégiée est la comparaison de plusieurs scénarios distincts avec une base commune (même quantité d'eau et de surface de terrains disponible).

Les ressources sont assez nombreuses (au nombre de huit, en plus des employés et des terrains) et correspondent à différents secteurs de production. Une douzaine d'activités peuvent être placées sur le territoire, dont certaines sont déclinées en plusieurs possibilités. Par exemple, les légumes peuvent être produits de deux manières : le maraîchage intensif, plus productif mais consommateur en eau et en énergie, et le maraîchage extensif, moins polluant et sans consommation d'énergie. Le jeu fait le choix de ne présenter aucun système monétaire dans les systèmes de production et d'importation / exportation de ressources.

Cette version du jeu est aussi pensée pour un mode multi-joueurs où chaque participant peut jouer à tour de rôle jusqu'à ce que tous les joueurs valident la fin du tour en cours. Une ébauche de l'échange de ressources entre joueurs est présente dans le code du jeu. Ce mode de fonctionnement du jeu n'a pas été testé lors des expérimentations qui se sont concentrées sur le mode décrit précédemment.

### 3.1.2 Synthèse et perspectives d'évolution

Des expérimentations utilisateurs sur cette première version ont eu lieu en amont du stage, avec plus d'une vingtaine d'essais et un document récapitulatif évoquant des pistes d'amélioration. Nous avons aussi expérimenté nous-même le jeu pour s'approprier les mécanismes déjà présents.

Le jeu présente déjà certains concepts essentiels à propos de la gestion de territoire et où les joueurs peuvent manipuler les ressources et les activités présentes. Les utilisateurs doivent réaliser des choix et des compromis face aux contraintes externes, le tout sur un espace aux ressources limitées.

D'autres points doivent évoluer pour apporter de nouvelles dimensions au jeu, notamment avec la présence de différents acteurs et territoires ce qui va pouvoir influencer les chaînes de production et la possibilité de transformer le territoire au fur et à mesure du temps. Les perspectives d'évolution que nous avons identifiées sont présentées dans la liste suivante :
* **Multi-joueurs** : Cela permet au jeu d'avoir de nouvelles dynamiques avec la présence de différents territoires et d'échanges de ressources. Chaque joueur manipule un territoire et est libre d'y faire ses choix de production.

L'accès à l'information concernant les activités, les ressources et les échanges des autres territoires peut être partielle, voire cachée, pour observer si cela influe sur le comportement du réseau d'acteurs (confiance, bluff, ...).

* **Présence de temporalité et situation initiale** : Le territoire peut évoluer pendant l'avancée du jeu pour s'adapter aux différentes situations dues à des facteurs externes ou aux autres joueurs. Actuellement, l'utilisateur est invité à ajouter des activités sur un territoire vierge et qui ne possède aucune ressource. Il serait alors possible de débuter le jeu avec des activités et / ou ressources déjà présentes sur les territoires et dont les joueurs héritent, ce qui se transpose mieux à la réalité où des infrastructures sont déjà existantes et peuvent être utilisées. De plus, cela pourrait accentuer la mise en place de gouvernance des flux où des joueurs ont le monopole ou l'exclusivité de certaines ressources et de leur distribution.

* **Mise en place de dépendances** : L'idée est de rendre des secteurs, ou des joueurs, inter-dépendants pour forcer une communication entre les acteurs. Les dynamiques de flux de ressources peuvent alors intégrer le réseau d'acteurs et différents rapports de force.

Les territoires peuvent présenter des caractéristiques uniques. Ainsi, une collaboration entre les joueurs leur serait bénéfique pour palier aux désavantages que leurs territoires présentent.

* **Ajout d'objectifs** : Le jeu actuel présente une liberté totale des actions à effectuer et certains joueurs ont trouvé cet aspect limitant en ne sachant pas vraiment quels choix faire. Avec la présence d'objectifs, le jeu peut forcer l'aspect collectif mais aussi l'aspect individuel, selon les bénéfices que les acteurs peuvent avoir en les remplissant.

* **Perturbations du système** : Une fois qu'un système biophysique est mis en place, des facteurs externes pourraient l'influencer pour en forcer son évolution. Des modifications sur les territoires, sur les productions des activités et sur les liens entre les joueurs peuvent contraindre à faire évoluer les flux de ressources.

* **Visualisations des flux** : Des schémas, diagrammes et graphiques peuvent accompagner l'apprentissage et la compréhension de l'évolution des ressources. Ces représentations visuelles permettent de faire des bilans sur les flux de matières et servent à la fois pendant la partie mais aussi lors de la phase de debriefing quand le facilitateur revient sur des situations vécue lors du jeu. L'approche Nexus peut être perçue à travers des visualisations si plusieurs matières, et leurs interactions, apparaissent.
## 3.2 Nouveaux concepts

De nouveaux fonctionnements, répondant aux points énoncés dans les pistes d'évolutions citées précédemment, ont pu être implémenté dans le jeu. Ces ajouts et leur calibration ont pu être testés lors d'expérimentations réalisées tout au long du stage. Cela nous a permis de les adapter pour mieux faire ressortir les messages et phénomènes que nous souhaitions diffuser. La section du rapport concernant les expérimentations développe précisément comment nous avons pu valider et faire évoluer ces mécaniques.

Développons maintenant les mécaniques existantes dans la nouvelle version du jeu, en explicitant pour chacune l'intérêt qu'elle apporte aux enseignements et messages que le jeu expose aux joueurs. Des visuels sont présents en annexe A pour voir comment ces mécaniques sont présentées dans le jeu plateau.

### 3.2.1 Fonctionnement global

Le jeu est désormais calibré pour quatre ou cinq joueurs. La partie a une durée prévue de 1h40, puis une phase de debriefing de 50 minutes permet de revenir sur le déroulé des évènements et comprendre les enseignements transmis.

Chacun des joueurs gère un territoire différent et ils peuvent effectuer en parallèle leurs actions. Ainsi, le jeu avance à un rythme plus soutenu que si chaque joueur effectuait ses actions à tour de rôle. Cependant les joueurs ne peuvent alors pas regarder l'ensemble des actions qui se déroulent sur les autres territoires, mais ce point n'est pas néfaste pour le jeu puisqu'il engage des discussions entre joueurs ou, a minima, l'observation des autres territoires.

Le jeu se divise en quatre tours chacun séparés en plusieurs phases. Après la répartition de l'eau (seule ressource qui ne peut pas être produite dans les activités), les joueurs peuvent faire évoluer leur territoire avec les différentes mécaniques que nous voyons dans les sous-sections suivantes. Puis, à la fin du tour, les indicateurs de pollution sont mis à jour et, en conséquence, des aléas peuvent survenir. Au cours de ces quatre tours, les joueurs doivent remplir un objectif collectif : Un hôpital doit être placé et maintenu sur un des territoires. La présence de cet objectif permet de forcer un aspect coopératif entre les joueurs, tout en mettant en place des tensions et rapports de force entre les joueurs, car celui-ci pollue et prend une place conséquente sur le territoire où il est installé.

### 3.2.2 Unicité des territoires et objectifs individuels

Les territoires ne sont pas vierges au début et possèdent des activités déjà présentes et distribuées aléatoirement. De plus, chaque lieu a des caractéristiques uniques, qu'il s'agisse de la surface sur laquelle les activités peuvent être placée, d'une impossibilité de placer un type d'activité ou d'une meilleure productivité pour certaines activités. Grâce à cette asymétrie entre les territoires, les joueurs s'engagent plus facilement dans des échanges et certaines chaînes de production ne sont plus uniquement calculées à l'échelle de leur territoire mais plutôt en prenant en considération les autres territoires et leurs avantages. Des dynamiques se créent alors, comme la sectorisation de certaines activités, la dépendance
entre territoires permettant une meilleure gestion des ressources.

Un aspect coopératif peut donc émerger, mais des tensions et des intérêts individuels peuvent perturber cette dynamique. Un territoire peut avoir l'exclusivité d'exploitation d'une activité entraînant un monopole totale sur une ressource. Il gouverne alors son exploitation et sa distribution et un rapport de force peut se créer. De plus, chaque joueur obtient en début de partie un objectif individuel et caché aux autres, qui peut l'amener à adapter ses comportements et ses choix pour son bénéfice individuel. Il doit aussi établir un équilibre entre ses intérêts personnels et les intérêts collectifs (notamment avec le maintien de l'hôpital).

### 3.2.3 Gestion du territoire

Comme dans la version précédente du jeu, chaque joueur peut placer des activités sur son territoire et les utiliser afin de transformer les ressources. Son nombre de terrains est limité (et différent selon le territoire), ce qui amène ainsi un phénomène de concurrence des sols où le joueur est contraint de choisir quelles activités doivent être placées en priorité. Il est également contraint sur le nombre de modifications qu'il peut apporter à son territoire à chaque tour, car les activités ne sont pas éphémères et les réflexions sur l'ajout ou la suppression d'une activité doivent prendre en compte le long terme.

Les ressources et les activités sont similaires à la version précédente. Leur nombre a été réduit pour faciliter la jouabilité et permettre de se concentrer également sur les autres aspects du jeu tout en veillant à conserver des enjeux déjà présents dans la version du jeu déjà développée. Par exemple, l'eau est limitée et ne peut pas être produite, entraînant ainsi de la concurrence sur son utilisation car elle peut être utilisée à la fois dans le secteur primaire mais aussi celui de l'énergie. Elle peut aussi provoquer indirectement un phénomène de transfert de pression. Si le joueur décide par exemple de privilégier l'utilisation de panneaux photovoltaïques pour produire de l'énergie, alors aucune eau ne sera consommée mais la surface occupée pour la production d'énergie sera accrue, amenant ainsi une pression sur l'utilisation des terrains.

### 3.2.4 Échanges de ressources

Au début de la partie, les territoires sont tous liés à un espace central avec une route chacun. Tant que celle-ci n'est pas endommagée, le joueur peut effectuer librement des échanges de ressources avec les autres. Ces échanges sont illimités et n'ont aucun effet secondaire pour ne pas complexifier les mécaniques du jeu. Une dépendance aux autres territoires et la présence d'importations et exportations peut donc se mettre en place. Aussi, un phénomène de transfert géographique de pression peut émerger, en privilégiant la mise en place d'une activité dans un autre territoire que le sien et en profitant de ses produits, sans subir sur son territoire les conséquences néfastes de pollution de cette activité.

Au cours du jeu, les routes de certains joueurs peuvent se retrouver endommagées. Dans cette situation, il leur est alors impossible d'échanger les ressources. Il est possible de réparer la route si les joueurs y contribuent collectivement, mais cela entraîne un certain coût et a un impact sur la pollution. Les joueurs peuvent alors débattre du choix
de la réparer ou non. Si celle-ci n'est pas réparée, il est alors nécessaire que le joueur isolé devienne autonome et les autres doivent réorganiser leurs productions pour ne plus dépendre du territoire inaccessible. À travers cette perturbation, nous mettons en évidence la résilience des systèmes biophysiques établis par les joueurs, en les contraignant à faire évoluer leurs territoires pour s'adapter.

### 3.2.5 Emplois et hébergement

En plus des ressources, la force humaine est également représentée dans chaque activité. L'utilisation d'une activité sur un territoire amène des employés, qui s'accumulent au fur et à mesure des activités utilisées. Les joueurs peuvent ensuite les héberger au sein de leur territoire ou des territoires voisins. Les employés qui ne sont pas hébergés en fin de tour émettent alors des gaz à effet de serre, car ils doivent habiter sur un autre territoire et cela nécessite des déplacements.

En plus d'apporter une dimension humaine au jeu et de ne pas se limiter au bilan biophysique, les employés sont une façon d'amener des décisions sur les territoires et de justifier l'utilisation de certaines activités pour obtenir des ressources. Notamment, la nourriture qu'ils consomment lorsqu'ils sont hébergés peut être de nature végétarienne, omnivore ou carnivore, laissant le choix au joueur sur la production de celle-ci.

### 3.2.6 Aléas

L'ensemble des activités utilisées par les joueurs peuvent augmenter ou diminuer la pollution. Celle-ci se distingue en deux indicateurs. Le premier est à l'échelle locale et est individuel à chaque territoire. Le second est commun à tous les joueurs et il s'agit des gaz à effet de serre.

L'évolution de ces indicateurs peut entraîner des aléas sur les territoires, à l'échelle locale ou globale. Ceux-ci sont établis en partie par l'administrateur du jeu, mais également par une dimension aléatoire grâce à des lancers de dés. Cela nous permet de modéliser les aléas comme étant des phénomènes dont l'intensité est difficile à anticiper, mais est influencée par le montant des indicateurs. L'ensemble des règles et des aléas ne sont pas communiquées aux joueurs en amont de la partie pour renforcer la découverte de ceux-ci et l'adaptation au cours de la partie face à ces contraintes. Ainsi, les joueurs sont confrontés à la possibilité d'augmenter le niveau de pollution mais avec l'incertitude des évènements qui peuvent survenir et leur intensité. Ils prennent aussi conscience du fait que leurs actions peut avoir des conséquences sur les autres territoires, si la pollution entraîne des aléas chez les autres.

Les aléas à l'échelle locale perturbent le rendement et les activités présentes, par exemple avec un incendie qui retire les forêts d'un territoire. A l'échelle globale, les aléas entraînent des modifications complètes du système biophysique, avec par exemple un glissement de terrain qui endommage la route d'un joueur et l'isole ou avec la sécheresse qui diminue la quantité d'eau perçue, alors qu'elle est à la base de la plupart des transformations de ressources du jeu.
## 3.3 Mise en place d'une phase de debriefing

Le jeu s'accompagne d'une phase de debriefing sous la forme d'une discussion entre les joueurs et le facilitateur de la partie. Elle se déroule avec les quatre phases suivantes :

* **Retour émotionnel** : Chaque joueur est invité à tour de rôle à s'exprimer sur la façon dont il a vécu la partie.

* **Messages perçus** : Les joueurs partagent les messages que le jeu semble transmettre. Cela permet notamment de désamorcer des faux messages résultants des simplifications faites dans notre modélisation. Par exemple, il est courant que les joueurs perçoivent l'hôpital comme un fardeau qui sert uniquement à polluer. Cela est dû au manque d'impact positif qu'il a dans le jeu, car il entraîne seulement de la pollution lors de son fonctionnement. Ce message perçu est mauvais et le jeu ne souhaite pas apporter une connotation négative au système de santé.

* **Liens avec la réalité** : Dans cette phase, le facilitateur revient sur des situations vécues lors de la partie et fait discuter les joueurs sur les choix qu'ils ont fait et auraient pu faire. Il compare aussi ces situations à la réalité et transpose les évènements du jeu à des phénomènes présents dans nos sociétés.

* **Recul sur le jeu** : Le facilitateur termine le debrief en explicitant ce que le jeu souhaite mettre en lumière et aussi ses limites. Il invite aussi les joueurs à mentionner ce qu'ils pensent être mal représenté dans le jeu.
# 4 Développement de la version numérique

Après une prise en main du jeu développé l'an passé, nous regardons ici comment les nouveaux besoins ont motivé les choix des technologies utilisées pour la nouvelle version numérique. Cette version est pensée pour être jouable depuis un navigateur web et est construite sous une architecture MVC (Modèle-Vue-Contrôleur). Ainsi nous nous concentrons d'abord sur la mise en place du serveur (Modèle et Contrôleur) puis du client web (Vue).

## 4.1 Prise en main du jeu développé

Comme nous l'avons vu, le jeu développé l'an passé est une première approche de la gestion des flux de ressources. Cependant ses limitations sur l'aspect multi-joueurs et le manque de présence d'une notion de temps (évolution des activités sur plusieurs tours, stocks des ressources) demandent de le faire énormément évoluer face aux nouvelles attentes. Ces besoins ont entraîné une réflexion sur les technologies à privilégier afin de développer la nouvelle version du jeu depuis la base avec deux objectifs principaux :

* **Version multi-joueurs** : Il s'agit de permettre de jouer sur différents appareils en parallèle. La communication orale entre les joueurs est privilégiée (en étant physique-ment dans la même pièce ou en appel à distance) et un facilitateur est présent pour administrer la partie.

* **Modularité du jeu** : Le jeu peut facilement être adapté à différentes situations (autres activités et/ou ressources par exemple). Il peut également être modifié pour identifier le rôle de certaines mécaniques (visibilité des informations, asymétrie entre les rôles des joueurs, ...).

## 4.2 Refonte de la structure logicielle

Pour permettre le multi-joueurs, une refonte logicielle a été faite. Le choix d'utiliser un serveur pour la totalité des communications a été fait pour les raisons suivantes :

* Il permet de centraliser les données et assure ainsi la cohérence de celles-ci en vérifiant que les souhaits du joueur sont réalisables (placer une activité, effectuer un échange, ...). Il évite ainsi qu'une désynchronisation des clients puisse aboutir à une situation impossible d'après les règles du jeu, ce qui pourrait survenir si chaque client possédait une partie des informations de la partie en cours.

* Il intervient dans la totalité des communications, même lorsque deux joueurs souhaitent faire un échange par exemple, ce qui permet d'enregistrer l'ensemble des actions, et ce dans l'ordre où elles ont eu lieu. Cela permet de simplifier grandement l'analyse des actions effectuées pour générer des graphiques ou ré-observer la progression de la partie après qu'elle ait eu lieu.

* Cela limite le nombre de connexions à gérer (seulement une par joueur), ce qui est ainsi moins coûteux en ressources et diminue les chances que des erreurs réseaux soient problématiques (désynchronisation, perte de données en cas de déconnexion, ...).
* Il serait davantage contraignant de jouer en mono-joueur car il est nécessaire de lancer un serveur, mais le jeu n'est plus conçu pour ce type d'utilisation.

Ainsi, le système s'apparente au patron de conception MVC (Modèle-Vue-Contrôleur). Le modèle possède les données et les fonctions correspondant aux mécaniques du jeu. La vue, qui est ici un client web, affiche aux joueurs les informations de la partie auxquelles il a accès. Le contrôleur permet au modèle et à la vue de communiquer via l'utilisation d'une API (Interface de Programmation d'Application) qui détermine le cahier des charges des appels et réponses entre le client et le serveur. Le rôle du contrôleur est de vérifier l'intégrité des données reçues par la vue puis d'appeler les fonctions correspondantes dans le modèle. Celui-ci essaye d'appliquer l'action demandée en vérifiant que cela correspond aux règles et renvoie au contrôleur les informations permettant de mettre à jour correctement le client (mise à jour visuelle des informations ou affichage d'un message d'erreur). Dans l'ensemble du développement, il a été considéré que le client n'est pas altéré ni utilisé malicieusement (affichage des données confidentielles des autres joueurs, exécution d'une action à sa place), ainsi aucune mesure n'a été mise en place pour contrer ces méthodes de triche. L'API a toutefois une certaine robustesse afin de vérifier que les commandes sont cohérentes avec la partie en cours afin de ne pas aboutir dans des situations incohérentes.

Le développement du modèle et du contrôleur ont été effectués en Python, à l'aide des librairies Flask et Flask_Socketio. Flask est une solution pour le développement d'un serveur en backend très populaire pour son faible poids et sa simplicité de fonctionnement. Flask_Socketio est une sur-couche de Flask permettant d'intégrer le système de sockets Socket.io. Les sockets sont des interfaces de communication qui permettent aisément de transmettre des messages entre différents points de connexion. Un de leur avantages réside dans l'aspect asynchrone de la transmission et de la réception des messages et la possibilité de mettre en place des fonctions à exécuter lors des réceptions. Ainsi, cela permet d'avoir un client qui est mis à jour de manière instantanée dès que le serveur souhaite transmettre une information, ce qui n'aurait pas été possible avec des requêtes web REST, où seul le client effectue des requêtes et attend la réponse du serveur. Un second avantage de l'utilisation de Socket.io est la présence de protocoles intégrés pour la reconnexion en cas d'erreur réseau, ce qui simplifie l'utilisation des sockets.

Pour compléter la décision d'un serveur qui centralise l'ensemble du fonctionnement du jeu, un client web a été développé. Les fonctionnalités web (HTLM/CSS/Javascript) permettent de mettre en place des clients très simplement accessibles pour les joueurs et sur différents appareils via l'utilisation d'un navigateur et en se rendant sur le site, là où un client a télécharger (comme celui sur Python sur la première version du jeu) est beaucoup plus contraignant (installations, compatibilité d'appareils, ...). Grâce à cette méthode, il suffit de charger sur le serveur les éléments du jeu (images, configuration de jeu utilisée) et les clients peuvent par la suite les obtenir avec les fonctionnements classiques des pages web et des sockets. Le standard Socket.io est disponible pour Javascript et est une des raisons de son utilisation pour la version multi-joueurs de Transkey, puisqu'il est aisé de mettre en place ce système à la fois pour le backend et le frontend et les pages web sont hébergées sur le même serveur que pour l'exécution du jeu.
## 4.3 Développement du serveur

Le rôle du serveur, comme nous l'avons vu, est d'assurer une cohérence au niveau des données du jeu et de stocker l'avancée de la partie. Nous voyons dans cette section comment celui-ci a été développé à la fois pour retranscrire fidèlement les mécaniques du jeu plateau et aussi permettre une communication avec le client via une API et un système de socket. Cela correspond donc aux implémentations des parties modèle et contrôleur du patron de conception MVC. Le tout prend également en compte la modularité des configurations de jeu possibles, permettant de modifier des éléments du jeu sans besoin d'éditer le code et rendant ainsi l'édition du jeu beaucoup plus accessible. Ceci est visible dans la sous-partie concernent l'initialisation d'une partie. Enfin, une section est dédiée à l'évaluation et validation de ce système.

### 4.3.1 Implémentation du modèle

Le modèle représente l'ensemble des mécaniques et des données utilisées pour le déroulé correct d'une partie. Il est développé en Python et utilise son système de classes afin d'instancier des objets qui sont ensuite manipulés par les différents fichiers du code. La structure obtenue est la suivante (Figure 3) et nous allons voir comment elle réussit à retranscrire tous les mécanismes présents dans le jeu.

<figure><img src="image_9.png" /><figcaption>Figure 3: Diagramme de classes du modèle</figcaption></figure>

La structure se repose sur la création d'un objet de la classe *GameStateSetup*, qui contient l'ensemble des données d'une partie. Nous revenons ensuite dans une autre sous-partie sur la manière dont les autres objets sont instanciés par celui-ci lorsqu'une partie
est chargée. Ils possèdent les informations et les fonctions correspondant à différentes mécaniques du jeu (échanges, visualisations, caractéristiques des ressources et des activités, ...). La classe **GameState** possède l'ensemble des fonctions qui peuvent être appelées depuis le contrôleur (ou depuis les tests du modèle, dont le fonctionnement est explicité dans une section ci-après). Elle servent généralement d'intermédiaire, car elles appellent à leur tour les fonctions correspondantes au sein des autres objets selon l'action. La raison de l'utilisation de cet unique point d'entrée est que la plupart des fonctions modifient aussi des variables internes à **GameStateSetup**, il est donc impossible d'appeler directement les autres objets. Un autre point clé est que chaque fonction garantit de renvoyer un booléen indiquant le succès de l'action ainsi qu'un second élément (texte d'erreur, format json, ...) qui sont interprétés par le contrôleur pour envoyer de l'information au client.

Illustrons ce fonctionnement avec l'exemple où un joueur souhaite ajouter une activité sur son territoire. Voici les étapes dans le code pour réaliser cette action :

* La fonction correspondante dans **GameState** est appelée en précisant le pseudo du joueur et l'activité souhaitée. L'objet **GameState** vérifie que l'état du jeu est cohérent avec cette action (une partie a démarré et le joueur existe).

* Si la première vérification est réussie, on récupère l'instance de **Player** qui correspond au joueur et on appelle la fonction d'ajout d'activité. Elle vérifie que le joueur remplit les conditions pour essayer d'ajouter l'activité (le joueur a le droit de placer ce type d'activité, en se basant sur les activités disponibles dans ses objets **ActivityRecipe**, et n'a pas déjà atteint son quota d'ajout de nouvelles activités ce tour-ci).

* Si cette deuxième vérification est réussie, c'est alors la fonction d'ajout d'activité de l'objet **Terrains** du joueur qui est appelée. Celle-ci, à l'aide des activités déjà présentes sur le territoire et stockées dans les objets **Terrain**, permet de confirmer ou non s'il reste assez de place sur le territoire pour ajouter l'activité. Si c'est le cas, alors l'objet **Terrains** instancie un nouvel objet **Terrain** qui contient l'activité souhaitée par le joueur, créée à l'aide d'une instance d'**Activity** dont les caractéristiques sont celles récupérées dans l'objet **ActivityRecipe** du joueur.

Nous voyons donc que les fichiers sont fortement liés entre eux et que le code est réparti pour garantir une clarté au niveau de la structure. Ce code est ainsi facilement modifiable selon l'évolution des besoins.

### 4.3.2 Initialisation d'une partie

La version numérique du jeu a été développée dans l'optique de pouvoir modifier la configuration de la partie très simplement. L'objectif est de permettre à quiconque d'adapter une configuration existante voire d'en créer une nouvelle sans même avoir besoin de modifier le code. Cela peut toucher plusieurs aspects du jeu, certains liés à son déroulé (nombre de tours, liste des informations visibles pour les joueurs, nombre de joueurs, ...) et d'autres liés aux mécaniques (ressources et activités disponibles, objectifs distribués aux joueurs, ...). Ainsi, si le jeu est utilisé dans un atelier, il est possible de s'adapter facilement pour rendre la partie plus pertinente vis à vis des situations que nous souhaitons mettre en évidence pour le territoire. Lors du développement, il est aussi bien plus simple de tester différents
équilibrages et configuration de jeu pour observer ce que nous jugeons être le plus efficace. De plus, cet aspect modulable facilite la création de configurations concises pour générer des tests qui vérifient indépendamment les mécaniques de manière automatique.

Pour réaliser cet objectif, la configuration d'une partie est gérée via des fichiers au format YAML, très courant pour rédiger ce type d'informations sous forme structurée. Il est aussi possible d'ajouter les images qui sont utilisées dans le jeu pour représenter les ressources et activités. Lors du chargement d'une partie, le dossier est lu par l'objet **GameStateSetup** qui instancie en conséquence les différents objets des autres classes pour s'adapter à ces configurations. La plupart des informations que l'utilisateur peut fournir sont facultatives (des valeurs de base sont considérées à défaut), il est ainsi simple d'écrire un fichier de configuration tout en gardant une grande lisibilité. Une documentation accompagnée également les utilisateurs pour créer leur configuration correctement et le système possède une certaine robustesse pour indiquer une incohérence dans celle-ci.

Cette configuration est répartie sur six fichiers différents pour faciliter leur lecture, et leurs rôles sont les suivants (La liste ne contient pas tous les détails pour rester dans la généralité) :

* **Jeu** : Contient des informations générales sur le jeu (Catégories des ressources et activités, quelles informations sont affichées aux joueurs, nombre de tours, ...)

* **Territoires** : Définit chaque territoire et ses particularités (nombres d'aménagements effectués par tour, nombre de terrains, description textuelle des caractéristiques)

* **Ressources** : Liste chaque ressource du jeu ainsi que leurs caractéristiques (image, catégorie, possibilité d'échange entre les joueurs, stockable, ...)

* **Activités** : Liste toutes les activités disponibles en indiquant les informations communes à tous les joueurs (image, catégorie, coûts de transformation par défaut) et, le cas échéant, les coûts de transformation des joueurs pour qui ils sont différents.

* **Objectifs** : Contient sous forme de texte les objectifs distribués aux joueurs aléatoirement au début de partie. Chaque objectif est accompagné de la liste des joueurs qui peuvent l'obtenir (car certains sont incompatibles avec certains territoires).

* **État initial** : Des activités sont distribuées aléatoirement aux joueurs en début de partie et sont déjà placées sur leurs territoires. Le fonctionnement est identique aux objectifs pour ne pas avoir d'incompatibilités.

Un exemple des fichiers d'une configuration est présenté en Annexe B.

### 4.3.3 Implémentation du contrôleur

Dans la conception MVC, le contrôleur est un intermédiaire entre le modèle et la vue (qui est ici le client web). Il réceptionne les commandes transmises par le client et vérifie leur intégrité avant de les transmettre au modèle. Ici, il est implémenté via Flask et Socketio, qui permettent d'exécuter le serveur et de créer un socket, donc un tunnel de communication asynchrone, entre chaque client et le serveur.
Dans notre situation, le contrôleur communique avec le modèle uniquement via l'instan-
tiation de **GameState** qui contient l'ensemble des données du jeu et des commandes
disponibles. Chaque action qu'un joueur ou qu'un administrateur peut effectuer est définie
dans une documentation du projet et correspond a une fonction présente dans le contrôleur
.et in fine présente dans le modèle). Ce système d'API qui explicite tous les appels pos-
sibles au contrôleur est utilisé lors de la conception du client du jeu et constitue le cahier
des charges à respecter lors de l'implémentation de celui-ci.

Lorsqu’un client transmet un message via le socket, le contrôleur s’assure de la cohérence des données et appelle la fonction correspondante dans le modèle. Il lui renvoie des valeurs que le contrôleur interprète afin de les transmettre aux clients. Si une erreur est survenue, le message d’erreur est diffusé au joueur qui a voulu effectuer l’action. Si l’opération est un succès, le contrôleur envoie les informations nécessaires afin que tous les clients se mettent à jour. Ces informations sont réparties dans un ensemble de catégories différentes (ressources, activités, routes, échanges, ...) afin d’optimiser les informations transmises aux joueurs en se limitant au nécessaire selon l’action qui vient d’être effectuée et éviter la redondance d’informations qui sont inchangées.

Dans le cadre du jeu et selon les configurations, il peut être pertinent que des joueurs n'aient pas accès à l'ensemble des informations (historique des échanges entre tous les joueurs, accès aux inventaires des autres, ...). Pour simplifier la mise en place du code, et puisque nous nous reposons sur le côté fair-play des joueurs, ces informations sont tout de même envoyées au client, qui a le rôle d'afficher uniquement les informations autorisées. Le fonctionnement du contrôleur est donc toujours identique quelle que soit la configuration.

4.3.4 Évaluation et validation du serveur

Puisque l'architecture du logiciel repose sur le patron de conception MVC, il est possible
de tester individuellement des parties du logiciel, notamment en validant le fonctionnement
des mécaniques et ce indépendamment de leur implémentation sur le client car l'API définie
assure la façon dont il communique avec le contrôleur.

La réalisation de tests unitaires pour valider le modèle du jeu et ses différentes méca-
niques a été privilégiée. La priorité était de s'assurer de l'intégration correcte de celles-ci
et de leur correspondance aux attentes en les comparant aux actions sur la version plateau.
Ces tests sont des scénarios réalistes qui peuvent arriver lors d'une partie, retraçant une
suite d'actions que les joueurs peuvent entreprendre et les tests permettent de s'assurer
de l'évolution correcte des données au cours de ces actions. Ils n'ont ainsi pas pour vo-
cation première de tester l'ensemble de la robustesse du logiciel (au niveau du typage des
arguments par exemple), même s'il est vérifié que des actions incohérentes ne peuvent pas
avoir lieu lors de ces scénarios. Ces tests font directement appel au modèle et mettent
en évidence les fonctions à utiliser par le contrôleur pour correspondre aux opérations que
peuvent faire les joueurs depuis le client.

La plateforme de tests a été développée en Python et importe directement les autres
fichiers sources pour accéder aux commandes du jeu. Elle permet d'ajouter simplement de
nouveaux tests avec leur propre configuration de partie afin d'avoir le strict minimum pour
tester la fonctionnalité ou le mécanisme en question. Des fonctionnalités sont intégrées à la plateforme pour simplifier la création et vérification de ces tests (génération de fichiers de sortie, option pour ne pas s'arrêter à la première erreur, print de debug). Pendant le développement logiciel, cet ensemble de tests est à exécuter régulièrement. Ainsi, grâce à la répartition en nombreux tests unitaires, nous pouvons facilement identifier les fonctionnalités qui ne sont plus confirmes aux attentes, c'est-à-dire les fonctions dont les valeurs renvoyées sont différentes. En plus de servir de tests de non-régression, ces scénarios ont parfois été préparés en amont de la réalisation des fonctions. Cela a permis d'établir les actions que peuvent entreprendre les joueurs et ainsi aider à la conception de l'API et des actions possibles au sein du modèle.

À titre d'exemple, voici en Figure 4 le scénario de test lorsqu'un joueur souhaite interrompre un échange démarré avec un autre joueur. Nous pouvons observer que suite au chargement de la configuration utilisée pour ce test, des commandes simulent des actions que les joueurs peuvent faire (les fonctions utilisées sont identiques à celles utilisées par le contrôleur). Les sorties de ces fonctions sont comparées aux fichiers de référence pour le test afin de s'assurer qu'elles sont correctes et n'ont pas évolué suite à des modifications dans le code du modèle. Si une erreur intervient dans un des tests, la sortie attendue et celle obtenue sont affichées pour pouvoir les comparer.

<figure><img src="image_10.png" /><figcaption>Figure 4: Exemple de scénario de test, ici un joueur interrompt un échange</figcaption></figure>

Avec le développement de ces scénarios, plus d'une dizaine de fonctions ont pu être validées (chargement correct des données de la partie, mise en place d'activités sur le territoire, échanges de ressources entre les joueurs, passage au tour suivant, ...). Ainsi, les mécaniques de la version numérique sont identiques à celles de la version plateau.

L'intégrité des données transmises lors des appels aux fonctions du modèle pourrait être vérifiée par des tests pour le contrôleur, mais aucune automatisation de tests n'a été développée pour celui-ci ainsi que pour le client web. Il a quand même été vérifié que l'ensemble des mécaniques étaient fonctionnelles via le client web et en passant par le contrôleur, en recopiant les actions effectuées par les scénarios fictifs développés pour tester les mécaniques. L'automatisation de ces tests pour le client et le contrôleur n'ont pas été développés car une fois le modèle validé, il était assez trivial de construire le contrôleur par dessus puis le client. Au sein du projet, il était davantage privilégié de consacrer du temps à l'implémentation de nouvelles mécaniques et d'avoir rapidement un retour d'expérience pour conclure sur leur efficacité.
## 4.4 Développement du client

En complément du serveur fonctionnant en continu sur un appareil et contenant les données du jeu, un client web est développé pour que le jeu soit accessible depuis un navigateur internet et correspond à la vue dans l'architecture MVC. Chaque joueur peut alors se connecter depuis son appareil et jouer via l'interface de jeu. Nous voyons dans cette partie comment ce client web a été implémenté pour répondre aux attentes du serveur et créer une expérience de jeu agréable.

### 4.4.1 Implémentation du client

Pour réaliser le client, la partie statique des pages a été conçue en HTML et CSS. JavaScript est utilisé dans l'ensemble des interactions avec le serveur et pour modifier l'affichage de la page. Nous regardons dans cette sous-section la structure des pages et du code, puis la communication avec le serveur basée sur l'API.

Les pages web sont hébergées par le serveur et réceptionnées par les utilisateurs avec les URL correspondantes (grâce à la librairie Python Flask). La figure suivante (5) présente la navigation entre les pages :

<figure><img src="image_11.png" /><figcaption>Figure 5: Navigation entre les pages web du client</figcaption></figure>

En entrant l'URL du serveur, les joueurs accèdent au menu dans lequel ils peuvent renommer leur territoire et accéder à la page de jeu. L'administrateur peut aller sur une page dans laquelle il peut effectuer les actions qui lui sont réservées. Il peut notamment charger la partie, appliquer les aléas qui surviennent dans le jeu et, si nécessaire, modifier les territoires et les ressources des joueurs s'ils effectuent des actions par erreur. En plus de ce panneau sur lequel il peut manipuler le déroulé de la partie, l'administrateur peut également ouvrir dans un autre onglet la page de jeu en tant que spectateur. Il n'a alors accès à aucune action, exceptée écrire dans le chat, et peut simplement visualiser le déroulé de la partie.

Après l'initialisation de la partie, seule la page web du jeu est utilisée par les joueurs. Visible en Figure 6, elle présente l'ensemble des informations de la partie et contient un plateau central équivalent à ce qui est visible sur la version physique du jeu.
<figure><img src="image_12.png" /><figcaption>Figure 6: Capture d'écran de la page de jeu avec le point de vue d'un joueur</figcaption></figure>

Les fonctionnalités de la page (affichages des ressources, navigation sur le plateau central, fenêtres popup pour afficher des informations, ...) sont réparties dans plusieurs fichiers JavaScript pour assurer la lisibilité du code et faciliter son évolution. Le rendu visuel est fait grâce aux fonctions natives en HTML et CSS, à l'exception du plateau central (développé dans la sous-section suivante).

Pour communiquer avec le serveur, le code JavaScript initie un socket. Les différents boutons et éléments cliquables peuvent alors transmettre de manière asynchrone des informations au contrôleur en accord avec l'API définie. Pour chaque action initiée, le contrôleur envoie en retour un ou plusieurs messages au client (ou à tous les clients avec l'utilisation du broadcast). À la réception de ces informations, le client appelle les fonctions des différents fichiers pour mettre à jour correctement l'affichage des données du jeu, et peut parfois transmettre à son tour des messages au serveur pour demander d'autres informations pertinentes. Le système asynchrone et les tunnels de connexion permettent d'optimiser l'utilisation de la bande passante et pour chaque interaction le serveur n'envie que les données utiles à la mise de la page et non pas l'ensemble des données du jeu à chaque fois.

### 4.4.2 Plateau de jeu central

Au centre de la page web, un élément HTML canvas est utilisé pour afficher le plateau de jeu. Grâce à la librairie Konva, cet espace est dynamique et permet de recréer une expérience proche de ce qui est visible lors d'une partie sur la version physique du jeu.

Cette librairie JavaScript permet de manipuler des objets dans un espace 2D et de manière interactive avec l'utilisateur. Elle possède de nombreuses fonctionnalités qui permettent une mise en place efficace des éléments graphiques, notamment avec le rendu de formes géométriques, de texte et d'affichage d'images avec différents formats.
Les joueurs sont répartis en étoile autour d'un rond-point placé au centre. L'utilisateur, à l'aide des boutons de l'interface et de la souris, peut se déplacer et zoomer sur la carte pour observer les différents territoires et ressources de tous les participants. Chacun peut aussi interagir avec les activités en cliquant dessus. Une fenêtre popup s'affiche alors avec la transformation de ressources et la possibilité d'utiliser l'activité si elle est sur le territoire du joueur. De la même façon, le joueur peut aussi démarrer un échange ou réparer une route endommagée en cliquant sur les éléments permettant ces actions et qui affichent des fenêtres popup.

### 4.4.3 Ergonomie et accessibilité

L'interface de jeu doit accompagner les utilisateurs et ne pas se présenter comme une contrainte ou un frein à l'immersion des joueurs. Pendant le développement du jeu, les retours des expériences utilisateurs ont contribué à l'amélioration de l'interface. Ces expérimentations ont permis d'identifier ce qui semblait le moins intuitif pour les joueurs, qu'il s'agisse de l'accès efficace aux informations ou la manière d'effectuer les mécaniques du jeu. Ainsi, l'interface de jeu développée est ergonomique et nous développons dans cette sous-partie plusieurs éléments qui y ont participé.

L'interface présente un accès à l'information de manière constante. Celle-ci se répartie au sein de trois colonnes :

* **Gauche** : Informations sur le déroulé de la partie. Elle contient des informations sur les objectifs, les caractéristiques du territoire et aussi sur le tour en cours.

* **Centre** : Informations pour l'évolution du territoire. En haut et en bas de cette colonne, l'utilisateur peut voir son inventaire de ressources, l'état des indicateurs et la liste des activités qu'il peut placer sur son territoire. En plaçant son curseur sur une activité dans la liste présente en bas, le joueur peut voir ses informations. Cela permet de comparer simplement plusieurs cartes d'activités efficacement, sans avoir besoin de cliquer et en naviguant simplement avec son curseur.

* **Droite** : Informations sur les échanges en cours dans lesquels le joueur est impliqué. L'interface d'un échange est développée dans la section suivante du rapport.

Les joueurs peuvent réduire les colonnes aux extrémités pour diminuer le nombre d'informations à l'écran. Un simple clic sur les boutons placés entre les colonnes permet de les cacher. Ainsi, un joueur qui n'a pas besoin de ces informations à un instant donné peut agrandir la fenêtre centrale et mieux observer le plateau, tout en ayant toujours accès aux informations critiques pour l'évolution du territoire et présentées en haut et en bas de la page. Pour assurer que le joueur ne manque pas les autres informations de la partie (une offre d'échange avec un autre joueur vient d'être modifiée, un nouveau message a été envoyé dans le chat, ...), un système de notification a été mis en place. Les boutons séparant les colonnes deviennent orange quand une information n'a pas encore été vue par le joueur. À gauche, la notification disparaît dès que le joueur a vu les nouveaux messages dans le chat (donc dès que la colonne est ouverte) et à droite, elle disparaît une fois que toutes les offres d'échange ont été vues (que la colonne soit ouverte ou non).
D'autres ajouts à la page permettent de s'approprier l'interface et ses fonctionnements plus rapidement. Par exemple, des pictogrammes sous les ressources indiquent des cas particuliers (figure 7) et des raccourcis claviers facilitent la navigation. En plaçant son curseur sur les images ou certains textes, des textes d'aide apparaissent pour expliciter l'information représentée. Enfin, les pages sont disponibles à la fois en français et en anglais. Pour cela, chaque texte est associé à un ID unique et, à l'affichage, le texte correspondant est récupéré dans le fichier de la langue souhaitée. Un dossier contient le fichier pour chaque langue et il est facile de modifier ces fichiers et d'ajouter de nouvelles langues si nécessaire.

<figure><img src="image_13.png" /><figcaption>Figure 7: Exemple de pictogrammes visibles dans l'affichage des ressources et d'un texte d'aide apparaissant quand le curseur se place sur un pictogramme</figcaption></figure>

Ces éléments de l'interface ont considérablement amélioré l'expérience utilisateur en rendant son utilisation plus intuitive. En plus d'avoir des informations présentées clairement, cela permet de réduire au maximum la perte de temps liée à la prise en main de l'interface et par conséquent d'accélérer la partie.
# 5 Différences entre plateau et numérique

La version numérique ne se limite pas à transposer les concepts du jeu plateau mais présente plusieurs différences. Nous étudions ici ses avantages et ses inconvénients par rapport au jeu physique. D'abord, nous essayons d'atténuer les difficultés qui émergent dans le client de la version numérique d'un jeu, comme c'est le cas par exemple avec l'absence de manipulation des pions et où il est plus dur de se rendre compte des déplacements des ressources. Puis nous voyons aussi comment l'informatique nous permet d'effectuer des actions qui ne sont pas réalisables avec un jeu plateau avec la génération dynamique de visualisations.

## 5.1 Solutions face aux inconvénients du support numérique

Certains mécanismes du jeu plateau ne peuvent pas être retranscrits fidèlement dans la version numérique à cause de la nature du support. Premièrement, il est nécessaire d'avoir une interface pour certaines actions comme les échanges, là où dans la version plateau les joueurs peuvent simplement s'échanger les pions à l'amiable. Deuxièmement, la perception de l'évolution des ressources est moindre. Nous voyons ici comment l'interface atténue ces inconvénients pour se rapprocher de l'expérience de jeu plateau.

### 5.1.1 Échanges de ressources entre les joueurs

Dans la version physique du jeu, les joueurs peuvent librement s'échanger leurs ressources si leurs routes les relient. Les seules contraintes pour un échange sont que les joueurs doivent posséder les ressources en question et qu'ils doivent tous les deux être d'accord pour que l'échange ait lieu. L'interface numérique tente de recréer l'expérience du plateau afin que les joueurs puissent librement effectuer des échanges en se mettant d'accord avec les autres. Elle doit ainsi les accompagner à mettre en place les offres et les demandes et assurer que les deux joueurs ont donné leur accord quand un échange est validé.

Sur l'interface de jeu, les échanges sont listés dans une colonne dédiée. Pour chacun d'eux, un bouton permet d'ouvrir la fenêtre d'échange. La couleur de ce bouton indique si le joueur a déjà accepté l'offre en cours, si la demande est en attente ou alors si une modification a eu lieu de la part de l'autre joueur.

Dans la fenêtre d'échange (Figure 8), les joueurs peuvent éditer les ressources envoyées et demandées. Pour cela, ils peuvent cliquer sur les boutons pour modifier les valeurs ou les rentrer directement avec le clavier (les valeurs sont bornées aux ressources réellement possédées et l'échange n'est effectif que si les joueurs ont les ressources nécessaires). Ils peuvent ensuite accepter l'offre en cours, la modifier ou annuler la proposition d'échange. Si les deux joueurs acceptent, l'échange a lieu et une notification affiche les ressources qui ont transité. Des aides visuelles permettent de voir quelles ressources sont possédées (les autres sont grisées) et l'état de l'échange (savoir si les joueurs impliqués ont accepté ou non l'offre en cours).
<figure><img src="image_14.png" /><figcaption>Figure 8: Interface d'échange. Le joueur souhaite échanger avec le joueur 2 deux unités de légume contre une unité d'énergie et souhaite également transférer deux employés.</figcaption></figure>

Cette interface d'échange a évolué au cours des expérimentations pour répondre aux attentes des utilisateurs sur son fonctionnement, car elle était d'abord peu intuitive. Avec l'utilisation des couleurs, de pictogrammes et en modifiant son affichage, la compréhension de cette interface est désormais davantage naturelle et, lors des dernières expérimentations, n'a suscité aucune interrogation sur son fonctionnement. Nous pouvons toutefois noter que des améliorations peuvent être ajoutées à son fonctionnement. Par exemple, il est actuellement nécessaire d'avoir un consensus de la part des deux joueurs même lorsqu'il s'agit d'un don de ressources et il pourrait être souhaitable que le joueur qui reçoit les ressources n'ait pas besoin de valider l'offre pour cette situation.

## 5.1.2 Évolution des ressources

Dans la version numérique du jeu, il est plus difficile pour les joueurs de se rendre compte de l'évolution de leurs ressources et celles des autres territoires. En effet, le jeu plateau permet de mieux se représenter les quantités car les pions prennent du volume, là où l'interface numérique affiche uniquement les valeurs. On parle de perception haptique quand le toucher accompagne cette représentation de l'information à travers la manipulation des pions [12] mais elle n'est possible que pour un jeu physique. Pour les indicateurs, qui sont représentés sur des échelles dans la version plateau et où les joueurs déplacent un pion, la conclusion est identique. Toutefois, le format numérique assure que les quantités des ressources et indicateurs sont corrects là où des erreurs de compte peuvent survenir sur la version plateau.

Afin d'atténuer ce manque de perception, le texte utilisé pour afficher des valeurs sur le plateau change selon la quantité comme visible sur la figure 9. Pour les ressources, leur taille augmente linéairement. Pour l'indicateur de gaz à effet de serre, la couleur est également modifiée de manière graduelle. Ces ajouts permettent de capturer visuellement en un instant les ressources que le joueur possède dans de grandes quantités et également l'état des gaz à effet de serre. Sans cet effet visuel, cet indicateur était souvent délaissé pendant le tour car ses modifications entraînaient trop peu de changement visuel et n'alertait pas les joueurs sur son montant.
<figure><img src="image_15.png" /><figcaption>Figure 9: Évolution de la couleur et de la taille du texte en fonction de la quantité</figcaption></figure>

D'autres problématiques sur l'évolution des ressources peuvent émerger en l'absence de pion. C'est notamment le cas des échanges de ressources et aussi de l'utilisation des activités qui transforment les ressources. Dans le jeu plateau, ces transformations sont perçues, mais dans la version numérique un simple clic fait évoluer instantanément les ressources possédées. Une des façons de renforcer le ressenti de ces évolutions est au travers des visualisations, que nous abordons dans la section suivante. D'autres pistes n'ont pas été développées mais pourraient être des perspectives d'amélioration, comme l'affichage dans le chat du joueur des ressources consommées et obtenues pour retracer chronologiquement les changements de l'inventaire.

## 5.2 Visualisation de l'information

Un des objectifs du jeu Transkey est de s'approprier et visualiser l'information sur les flux et de la rendre accessible aux joueurs sous forme d'analyses de flux de matières. Le jeu peut aussi être utilisé pour évaluer l'intérêt de ces représentations pour jouer. L'idée est de pouvoir suivre l'évolution des différentes ressources ainsi que leurs transformations. Pour la version plateau, l'accès à cette information est limité car elle n'est vu qu'au travers des ressources que le joueur possède à un instant donné, mais évolue au sein du tour. Elle est donc ressentie à chaque évolution de l'inventaire du joueur, mais il n'est pas possible de retracer les changements dans le tour. Le support numérique, lui, nous permet de générer des graphiques à la volée pendant les parties et adaptées aux informations du jeu.

Les représentations des informations et des flux doivent servir des objectifs précis selon les phénomènes que nous souhaitons mettre en avant, tout en veillant aux biais qu'elles apportent, afin d'être une plus-value pour la compréhension. Ces graphiques doivent aussi être lisibles et accessibles même pour des personnes qui n'ont pas de bagages mathématiques, en accompagnant la lecture de ces représentations visuelles. Un des usages du jeu peut d'ailleurs être l'initiation à la lecture de certains types de diagrammes pour faciliter la compréhension des représentations qui ont des vraies données.
### 5.2.1 Documentation sur la représentation de flux

Différentes représentations sont communes pour permettre la visualisation des flux de matières et d'énergie.

Une première représentation est celle du diagramme de Sankey. Son objectif est de représenter les flux entre des nœuds, à l'aide de flèches dont les tailles sont proportionnelles à la valeur. Ainsi, plusieurs phénomènes peuvent être représentés avec ce type de diagramme grâce à ses caractéristiques :

* La somme des entrées du diagramme est égale à la somme des sorties. Rien ne peut subitement apparaître ou disparaître à l'intérieur. De plus, on peut identifier très rapidement les flux importants grâce à l'épaisseur des traits.

* Une chronologie peut émerger si le diagramme a plusieurs étapes intermédiaires.

* Le bilan peut être fait pour un seul type de flux ou plusieurs (mais cela complexifie le schéma). Cela permet donc d'analyser avec l'approche Nexus pour obtenir une vue d'ensemble sur tous les flux.

Ce type de diagramme peut donc représenter les flux d'une ressource. Il est déjà utilisé pour représenter visuellement les bilans de matière de certaines filières [17]. Un exemple d'un tel diagramme est visible ci-dessous 10. Dans celui-ci, on peut suivre l'évolution des pommes et des poires, représentées en parallèle sur le même schéma avec des couleurs distinctes, ainsi que constater leur parcours (transformation, consommation).

<figure><img src="image_16.png" /><figcaption>Figure 10: Exemple d'un diagramme de Sankey pour l'analyser de fruits en tant que flux de matière (OpenSankey)</figcaption></figure>

Une seconde représentation envisageable est celle d'un diagramme de réseau comme sur la figure 11. Avec la mise en avant de la spatialisation, il est possible de suivre le chemin d'une ressource sur la carte pour comprendre ses sources de production et ses utilisations. Tout comme les diagrammes de Sankey, il est possible d'imaginer une épaisseur en relation avec l'intensité du flux. Cependant, une part de l'information peut être perdue si l'ensemble
des relations possibles ne sont pas représentées (sinon, cela implique l'affichage des flux entre chaque couple de joueur).

<figure><img src="image_17.png" /><figcaption>Figure 11: Exemple d'un diagramme de réseau (Illustration du schéma de principe d'un réseau de chaleur, Cerema)</figcaption></figure>

Dans le jeu, nous souhaitons à la fois mettre en avant des phénomènes au sein d'un territoire (concurrence d'usage des ressources, transfert de pression, ...) mais aussi entre les territoires (dépendances entre joueurs, transfert géographique de pression, ...). Ainsi, deux visualisations distinctes et complémentaires ont été mises en place, chacune adaptée à une échelle différente.

### 5.2.2 Représentation de l'information au sein d'un territoire

Le premier type de visualisation disponible est un diagramme de Sankey permettant de visualiser les transformations internes des ressources. Pour un territoire donné, il est ainsi possible d'observer comment les ressources acquises (via leur transformation avec des activités ou des échanges) ont été utilisées au fur et à mesure du tour. Un aspect chronologique est aussi mis en place pour observer les chaînes de transformation qui émergent généralement au sein des territoires des joueurs. Nous pouvons voir sur la figure 12 un exemple de diagramme de Sankey pour un territoire. Il retrace dans l'ordre chronologique les actions effectuées par le joueur et qui ont apporté une modification aux ressources en sa possession. Puisque des ressources sont consommées et produites au sein du tour, les entrées et sorties du diagrammes peuvent être distinctes. Cependant, aucune ressource n'apparaît ni disparaît, leur quantité n'est modifiée que dans les transformations.
<figure><img src="image_18.png" /><figcaption>Figure 12: Extrait d'un diagramme de Sankey retraçant les actions d'un joueur.</figcaption></figure>

Au premier abord, cette visualisation peut rendre confus car elle est très fournie en informations. C'est pourquoi il faut accompagner le joueur avec plusieurs lectures qui découlent de ce graphique :

* Se concentrer sur une seule ressource. L'idée est de suivre l'évolution d'une ressource au fur et à mesure du tour, comme l'énergie par exemple. On constate qu'elle est produite et consommée par différentes activités au fur et à mesure du tour (ici, produite par l'hydro-électricité et consommée par les activités agricoles et d'élevage).

* Observer la dépendance entre secteurs. En ce concentrant sur une activité donnée (généralement celles proches de la fin du tour), on peut voir comment celle-ci a pu être activée grâce aux activités précédentes qui ont permis d'obtenir les ressources nécessaires. Autrement dit, la réflexion ici est de partir d'un postulat (le souhait qu'une activité soit utilisée) et de retracer ce qui a pu permettre sa mise en place. Par exemple, la production de viande dans la figure ci-dessus est possible grâce à la production de fourrage dont l'activité dépend elle-même de la production d'électricité qui est possible grâce à l'eau. Cette chaîne de dépendance est pertinente dans les transferts de pression, où un choix a des répercussions sur toutes les productions futures.

* La présence des échanges avec les autres joueurs. Même si ce n'est pas l'objectif principal de ce graphique, il est possible d'observer la fréquence d'échanges avec les
autres ainsi que le détail de ces échanges.

Pour rendre possible cette visualisation, chaque donnée utile à cette représentation est accumulée progressivement et stockée dans chaque objet **Joueur**. Une transformation de ressources (échange, réparation de route, activité) est représentée par un nœud qui va prendre en entrée les ressources consommées et va donner en sortie les ressources produites. Lors du passage au tour suivant, les rendus visuels sont calculés puis stockés dans un dossier du serveur web. Ainsi, via l'interface, chaque joueur peut aller observer l'ensemble des diagrammes de Sankey directement avec le bon URL (en pratique, les boutons ouvrent les images dans de nouveaux onglets pour pouvoir se déplacer et zoomer à l'intérieur, car ceux-ci sont assez grands si le joueur effectue beaucoup d'actions).

Ces rendus visuels sont générés à l'aide de la librairie Python *sankeyflow*, à laquelle beaucoup de modifications ont été apportées pour qu'elle corresponde à nos besoins. Elle a été utilisée car son code est peu volumineux et permet facilement de faire un rendu au formatsvg enregistré ensuite dans un fichier. Pour notre cas d'utilisation, des fonctionnalités ont été ajoutées comme l'affichage d'images, de textes indiquant les valeurs des flux, de couleurs uniques pour chaque ressource ainsi que des différences visuelles selon la nature de l'action (activité ou échange). Ces rendus graphiques sont générés par le serveur afin que, suite à la partie, il puisse être possible pour le facilitateur de revisionner ces images. Puisqu'ils sont générés une seule fois par tour, il n'est pas problématique que les rendus soit effectués du côté du serveur car le temps de la procédure n'est pas critique. Ces visualisations, en plus de permettre d'accompagner la phase de debriefing, peuvent aussi être analysées pour des réflexions à propos de l'équilibrage du jeu.

### 5.2.3 Représentation de l'information entre les territoires

En complément de cette première visualisation, nous souhaitons mettre en avant les dépendances territoriales. Chaque territoire ayant des caractéristiques différentes, l'idée est que chacun puisse identifier si les avantages de chaque lieu ont été mis à profit pour l'ensemble des joueurs ou si au contraire un territoire a davantage été autonome en limitant ses importations et exportations. La visualisation en réseau a donc été adoptée pour représenter les interactions entre les territoires, c'est-à-dire les échanges de ressources entre les joueurs et la contribution aux gaz à effet de serre, qui est commune à tous et non représentée à l'échelle individuelle. La réparation d'une route est également visible sur cette représentation, car il s'agit d'une action où les ressources sont utilisées à l'extérieur du territoire d'un individu et généralement au profit de tous. Cette visualisation apparaît directement sur le plateau de jeu à l'aide de flèches parallèles aux routes reliant les joueurs aux autres, comme présenté sur la figure 13. La partie peut être configurée pour que ces informations soient toujours visible ou alors qu'elles ne s'affichent qu'entre les tours pour faire des bilans intermédiaires.

Un défaut émergeant de cette façon de représenter les interactions entre les territoires est l'abstraction, pour chaque ressource, à un seul flux entrant ou sortant selon le bilan numérique du tour. Si le joueur échange le même type de ressources avec plusieurs autres joueurs, cela est représenté de la même façon que s'il n'échangeait cette ressource qu'avec une seule personne. Pour remédier à cela et obtenir la précision sans complexifier l'affichage,
chaque joueur peut cliquer sur une flèche pour obtenir l'image contenant le détail des importations et des exportations entre un territoire et les autres. L'image affichée est un diagramme de Sankey et il est généré au moment de la requête de celle-ci, assurant que ce diagramme est à jour avec l'état actuel du tour et permettant de ne pas générer inutilement les autres diagrammes. Sur l'exemple suivant, Figure 14, un joueur a cliqué sur la flèche orange, correspondant à l'énergie, du joueur 2.

<figure><img src="image_19.png" /><figcaption>Figure 13: Capture d'écran du jeu, où des flux entre les territoires sont visibles (échanges et contribution aux gaz à effet de serre)</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>Figure 14: Capture d'écran d'un diagramme de Sankey affiché quand le joueur clique sur une flèche correspondant au flux d'énergie d'un des joueurs</figcaption></figure>
### 5.2.4 Validation des visualisations

Ces visualisations ont pu être testées lors de nos expérimentations. Les joueurs étaient invités à explorer les différentes visualisations et à s'exprimer, entre chaque tour, sur le graphique de leur territoire ainsi que sur les flux affichés entre les territoires. De plus, le facilitateur accompagnait la lecture de ces graphiques, notamment en exposant des clés de lecture citées précédemment. Nous regardons ici des retours sur chaque type de visualisation, puis nous concluons sur leur usage et leurs limites.

Les retours concernant les diagrammes de Sankey ont été très variables selon les joueurs, et ce indépendamment de leur appartenance au milieu académique. Certains se sont ap-propriés ces outils au cours de la partie. Ils contiennent beaucoup d'éléments, mais les joueurs apprennent rapidement à lire ces visualisations en étant confrontés à plusieurs d'entre elles et avec les différentes lectures suggérées. Ces visuels les ont ainsi aidé à faire des choix sur leurs territoires, remarquer leurs dépendances à certaines ressources et observer les phénomènes que le jeu expose. Pour d'autres joueurs, ces visuels n'ont pas apporté d'éléments de compréhension supplémentaires.

Concernant les flux entre les territoires, nous avons pu essayer deux méthodes. La première est l'affichage en direct de ces flux et qui évolue donc au sein du tour. La seconde méthode est de n'afficher ces flux qu'entre les tours, en même temps que les diagrammes de Sankey qui représentent les transformations au sein d'un territoire. Ces flux ont généralement mis en évidence les dépendances et monopoles de certaines ressources. Dans le cas des flux modifiés en direct avec les actions des joueurs, la contribution aux gaz à effet de serre a mieux était mise en évidence. Cet indicateur ayant une valeur partagée entre tous, cette visualisation a permis à certains de réagir sur le montant qu'ils émettaient, là où la contribution individuelle est invisibilisée quand on ne prend en compte que la valeur totale.

D'après nos observations, la présence des flux n'a jamais été un frein au jeu et à la compréhension des situations présentées. Les visualisations ont paru à certains comme un ajout esthétique et sans plus-value, mais elles ont aussi permis d'accompagner des joueurs dans l'assimilation des phénomènes sur les flux de ressources.

Comme nous le verrons dans les perspectives d'amélioration du jeu, le côté compétitif a été assez limité et les joueurs ont beaucoup collaboré lors des sessions de jeu. Cela a pu impacter la pertinence d'afficher certains flux car les joueurs avaient généralement une vision très globale du jeu et ne se comparaient pas avec les autres territoires, ce qui aurait davantage émergé dans un jeu plus compétitif.
# 6 Expérimentations

Dans la réalisation d'un jeu, les phases d'expérimentations sont très importantes et au cœur du processus de développement. On en distingue deux types :

* Expérimentations de test du jeu, pour observer si les mécaniques et l'équilibrage correspondent à nos attentes.

* Expérimentations une fois que le jeu se stabilise, afin de mettre à l'épreuve ce que nous souhaitons enseigner à travers le jeu.

Ces expérimentations permettent de valider le travail réalisé et de mettre en évidence les points à retravailler. C'est à ces moments que nous pouvons avoir une première prise de recul sur l'efficacité du jeu, avant son utilisation sur le terrain.

Nous regardons d'abord les caractéristiques de ces sessions et leur processus. Dans une deuxième sous-partie de cette section, nous voyons comment des sessions nous ont permis d'adapter le développement. Puis, nous observons le déroulement de multiples sessions que nous avons organisées sur la version la plus récente et qui a permis d'évaluer quels objectifs du jeu ont été atteints.

## 6.1 Processus d'expérimentation

Afin d'évaluer les versions intermédiaires et la version la plus aboutie du jeu, une dizaine d'expérimentations ont été réalisées tout au long de la période de développement. Pour chacune d'entre elle, nous avons animé des parties avec quatre ou cinq joueurs, ce pour quoi le jeu a été pensé, sur une durée de deux à trois heures.

Les joueurs étaient des volontaires pour tester le jeu et faisaient partie d'au moins une des trois catégories suivantes :

* Chercheur ou personnel à l'INRIA

* Connaissance personnelle des personnes impliquées dans le développement du jeu

* Personne déjà sensibilisée à des enjeux exposés dans le jeu (limites biophysiques d'un système, pénurie, conséquences du dérèglement climatique, ...)

Ainsi ce public n'est pas entièrement représentatif du public visé par le jeu car la plupart des joueurs avaient déjà des connaissances mathématiques et scientifiques ou des sensibilités aux sujets abordés par le jeu.

Lors de ces tests, nous avons noté en amont ce que nous souhaitions observer. De plus, nous avons parfois testé plusieurs alternatives en parallèle pour explorer un maximum de pistes (différents aléas, différents objectifs ou encore accès ou non à certaines informations sur la version numérique). Suite à chaque session, nous avons pu conclure sur les observations que nous avons faites et établir les modifications à effectuer pour la session suivante si les objectifs n'étaient pas atteints (ou en tant que piste d'amélioration pour les tests réalisés près de la fin du stage).
## 6.2 Sessions pendant le développement

Des expérimentations effectuées progressivement dans la période de développement du jeu nous ont permis d'avoir rapidement des retours sur la jouabilité ainsi que sur l'apparition de situations intéressantes que le jeu souhaite exposer :

* 10/04 à l'INRIA : six joueurs, quasi-exclusivement tous de l'équipe STEEP, sur une session plateau.

* 22/05 à l'INRIA : six joueurs, tous de l'équipe STEEP, sur une session plateau.

* 29/05 dans un bar : six volontaires (connaissances personnelles) sur une session plateau.

* 12/06 à l'INRIA : cinq chercheurs de l'INRIA sur une session numérique.

* 4/07 à l'INRIA : huit chercheurs et personnels de l'INRIA répartis sur deux sessions, une sur chaque support.

Ces séances ont eu lieu environ une fois par mois et généralement au sein des locaux du laboratoire avec des joueurs provenant de notre équipe de recherche ou des autres équipes du centre. L'efficacité du jeu était difficilement mesurable puisque ce public était très averti sur les problématiques exposées et sur les outils utilisés (jeu sérieux, diagrammes de Sankey). Une session supplémentaire, organisée dans un bar et en invitant nos connaissances, a permis de mieux juger la compréhension du jeu et de la manipulation des flux.

Dans les premières sessions, puisque le jeu était encore incomplet, la phase de debriefing n'était pas encore notre principal point d'attention et nous nous sommes focalisés sur les mécaniques du jeu et sur les retours d'expériences des utilisateurs. Puis, après avoir stabilisé le fonctionnement global du jeu, ces sessions nous ont permis de nous former sur l'explication des règles claire et concise ainsi que sur l'animation de la partie de debriefing.

Grâce à ces expérimentations, les joueurs et nos observations ont mis en évidence les points d'amélioration prioritaires pour notre développement. Nous avons pu corriger le déséquilibre de certaines stratégies qui limitait l'exploration de différentes alternatives, comme la situation de l'énergie où les joueurs utilisaient quasi-exclusivement le photovoltaique en délaissant les autres possibilités. Nous avons aussi vu les limites de l'interface numérique qui était beaucoup moins permissive et intuitive. Les joueurs ont exprimé leur confusion sur certains affichages comme l'interface d'échange, qui a été modifiée à plusieurs reprises avant d'aboutir à une fenêtre intuitive. Ces tests ont également confirmé le fonctionnement du jeu numérique en multijoueur et au sein du même réseau wifi.

## 6.3 Mise à l'épreuve de la version actuelle

Vers mi-juillet, nous avons pu organiser six parties pour analyser et conclure sur la version du jeu la plus récente. Nous revenons ici sur leur déroulement puis nous faisons le bilan sur les éléments qui ont fonctionné et ceux qui ont moins fonctionné dans ces cessions.
### 6.3.1 Déroulement des sessions

Ces séances ont été organisées avec l'aide de plusieurs organismes et ont accueilli des volontaires pour la plupart déjà sensibilisés à ces enjeux :

* 15/07 à La MADRE : huit joueurs déjà sensibilisés aux enjeux répartis sur deux sessions de la version plateau.

* 16/07 à Alternatiba : dix joueurs, déjà sensibilisés aux enjeux et / ou connaissances personnelles, répartis sur deux sessions de la version plateau.

* 18/07 à La MaCI : huit joueurs du monde académique répartis sur deux sessions de la version numérique.

Pour ces sessions de jeu, nous avons pu effectuer la totalité du jeu sérieux dont la phase de debriefing en suivant un document que nous avions préparé au préalable. Bien sûr, puisqu'il s'agit toutefois d'une phase préliminaire et que le jeu n'est pas abouti, les joueurs ont aussi pu suggérer des améliorations au jeu et nous avons constaté certaines limites lors de ces parties. Ces retours ont été pris en compte dans les pistes d'amélioration du projet, développées dans la section suivante du rapport.

### 6.3.2 Bilan de la version actuelle

Le jeu a très bien été accueilli par les joueurs et les retours ont été positifs dans l'ensemble. À l'issue de ces séances, nous avons pu dresser un bilan des mécaniques et outils qui ont fonctionné, ainsi que ceux qui ont moins bien fonctionné et nécessitent des améliorations.

Premièrement, nous constatons que la plupart des mécanismes et situations que nous souhaitions montrer ont eu l'impact souhaité :

* Le multi-joueurs créé des dynamiques de discussions, de débats et de stratégies. Les joueurs prennent en considération les territoires voisins en échangeant leurs ressources et en collaborant. Des dépendances s'installent entre les territoires et le système est considéré dans son ensemble. Dans certaines parties, les joueurs se spécialisent même dans certains types de production selon les territoires.

* Les aléas, notamment celui où une route est endommagée, forcent la réorganisation biophysique pour faire fonctionner les activités. Ils démontrent également des conséquences des activités humaines sur les évènements météorologiques et leurs pollutions ainsi que l'aspect aléatoire / difficile à évaluer de leurs fréquences et conséquences.

* Les éléments visuels du jeu (plateaux, pions, routes, ...) accompagnent les joueurs et leur permettent de s'engager facilement dans la partie. Placer les activités sur le territoire et les pions sur les activités est amusant et rend ludique la compréhension des flux et des tensions sur l'utilisation des ressources. On remarque tout de même que le jeu n'est pas simple à prendre en main et nécessite un certain temps d'apprentissage, notamment dans le premier tour. Cependant il permet d'appréhender les chaînes de production avec la transformation des ressources et les dépendances entre les activités.
* La présence d'un état initial pour faire évoluer un territoire déjà établi et non pas développer une ville sur un territoire vierge, permet de se l'approprier véritablement dès le début. Couplé aux caractéristiques uniques de chaque zone, les joueurs établisSENT rapidement des stratégies de jeu pertinentes.

* Les visualisations des flux dans la version numérique du jeu ont permis d'accompagner la plupart des joueurs pendant la partie. Certains n'ont pas compris leur intérêt au premier abord mais ont progressivement réussi à s'approprier l'outil pour optimiser leurs productions et observer les transformations de ressources sur l'ensemble des territoires. Dans une des sessions, ils ont par exemple pu pointer la surproduction et donc le gaspillage d'énergie, car elle ne peut pas être stockée.

Ces visualisations ont ensuite pu être utilisées dans le debrief par le facilitateur pour exposer concrètement les situations survenues aux joueurs avant de faire le parallèle avec des situations réelles.

* La phase de debriefing permet aisément de faire un retour à la réalité. Les joueurs perçoivent en quoi les situations vécues dans le jeu peuvent survenir pour de vrai, notamment au niveau des limites physiques des ressources et de la présence d'aléas.

Deuxièmement, des éléments qui ont moins fonctionné ou n'ont pas contribué à la compréhension du jeu sont les suivants :

* L'aspect compétitif n'est pas assez représenté. Actuellement, les joueurs collaborent dans le cadre de l'objectif collectif mais aussi pour optimiser l'utilisation des ressources de tous les territoires. Cette vue d'ensemble a ainsi limité la compréhension sur les tensions possibles entre les acteurs (qui pourraient apparaître si quelqu'un décide de ne plus exporter une ressource par exemple). Les joueurs ont exprimé à juste titre lors des debriefs que cette confiance et collaboration entre les acteurs manque de réalismes.

La phase de distribution d'eau, où les joueurs se répartissent un montant fixe d'eau, amène également peu de débat due à cette coopération entre les joueurs.

* Les aléas ciblent actuellement le secteur primaire et la pollution n'a pour l'instant aucun impact sur les autres secteurs comme la production d'énergie. De plus, la dépollution du territoire pour atténuer les probabilités d'aléas n'est possible que via la mise en place de réserves naturelles qui sont actuellement limitées sur le territoire.

* Puisque le jeu repose sur les bilans de matières et les indicateurs de pollution, les activités tertiaires et les employés sont perçus comme un fardeau pour les joueurs. Leur présence nécessite beaucoup de ressources et entraîne de la pollution aux échelles locales et globales.

* Le jeu devrait être calibré pour être réalisable en 2h30, mais les sessions actuelles suggèrent un temps idéal de 3h pour réaliser l'entièreté du processus.
# 7 Conclusion

## 7.1 Bilan du projet

À l'issue de plusieurs mois de création, nous avons réussi à produire une première version stable du jeu sérieux Transkey dans un mode multi-joueurs. Il est jouable pour quatre ou cinq joueurs pour une durée idéale de 3h et existe à la fois en format plateau et numérique. Les joueurs, qui gèrent chacun un territoire, ont une grande permissivité sur l'exploitation des activités qui y sont présentes ainsi que sur les relations avec les territoires voisins. Cela leur permet d'explorer librement des alternatives sociotechniques et d'assimiler les problématiques sociales et environnementales qui existent dans nos systèmes actuels. Le jeu permet ainsi de comprendre les chaînes de productions, les flux de ressources et en quoi le réseau d'acteurs peut influencer ces flux. De plus, d'autres facteurs externes sont représentés avec les aléas qui peuvent survenir dûs aux pollutions des territoires.

La version numérique n'est pas une simple transposition de son équivalent plateau mais est un support pertinent pour accompagner l'expérience. Grâce à l'utilisation de l'informatique, des visualisations sont générées pendant et après la partie. Elles viennent compléter la compréhension qu'ont les joueurs lors de la partie, notamment à travers des diagrammes de Sankey qui explicitent l'évolution des flux de ressources et les liens entre les territoires. Ces lectures permettent de mettre en lumière les limites biophysiques de nos systèmes, comme la pénurie d'une ressource ou le monopole de celle-ci. Le jeu peut aussi être utilisé dans l'objectif d'apprendre à interpréter ces diagrammes.

Même si notre produit n'a pas encore été joué par un public lambda, nos expérimentations semblent montrer que le jeu est propice à expliciter les phénomènes souhaités. Les joueurs se sont engagés dans la partie et se sont appropriés leurs territoires en tentant de résoudre les conflits de ressources et d'interaction avec les autres territoires. Ils ont identifié les limites de leurs systèmes lorsqu'ils doivent faire des choix sur les productions et consommations des ressources. Grâce à l'approche Nexus et les diagrammes générés, l'analyse a été faite sur le système dans son ensemble pour comprendre les phénomènes systémiques, qui ne peuvent pas être visibles si l'analyse est limitée à un seul secteur.

Toutefois, le jeu présente actuellement des limites au niveau de son design et de son implémentation numérique. Nous avons identifié des points clés pour un développement futur, ceux qui nous semblent être les plus prioritaires sont les suivants :

* Le jeu ne présente pas assez de compétitivité entre les joueurs. Pour remédier à cela, les objectifs individuels devraient rentrer en conflit avec l'objectif commun pour ainsi créer des tensions.

* Les aléas actuels visent quasi-exclusivement le secteur primaire. D'autres aléas pourraient être ajoutés pour empêcher certaines stratégies où un territoire non-agricole peut être très pollué sans conséquences négatives. Un protocole pourrait aussi être développé pour que l'administrateur de la partie sache quels aléas provoquer et quand.

* La dépollution doit être reconsidérée et l'impact des indicateurs doit être plus facilement identifiable par les joueurs dans l'aspect visuel et dans la narration.
* Les activités tertiaires sont mal perçues à cause de notre analyse de matières qui fait abstraction du rôle de ces activités. Elles sont consommatrices de ressources et polluent, et sont donc connotées négativement alors qu'elles contribuent en réalité au fonctionnement de notre société. D'autres mauvais messages similaires sont à corriger.

* Des choix sont déjà présents (production de nourriture ou d'énergie), mais davantage de choix sur les productions et consommations pourraient être introduits. Par exemple, une production agricole intensive ou extensive, dont les mécanismes de transformation sont différents.

* Les pages du client web pourraient bénéficier de l'utilisation de React. Cette bibliothèque JavaScript serait adaptée pour la mise à jour des éléments graphiques et de l'interface avec une structure de code plus lisible et des optimisations d'affichage.

* Le modèle du jeu, bien que déjà réparti sur plusieurs fichiers, pourrait évoluer avec la création de nouvelles structures. Par exemple, la gestion des ressources du joueur est contenue directement dans les fonctions du joueur alors qu'une nouvelle classe pourrait être créée et contenir l'ensemble des mécanismes liées aux ressources.

* Les visualisations actuelles permettent déjà de représenter une partie de l'information à travers des diagrammes, mais des visualisations complémentaires pourraient accompagner la compréhension des joueurs. Cela concerne notamment l'évolution des gaz à effet de serre tout au long de la partie, ainsi que la précision des activités qui y ont contribué ou l'ont absorbé.

## 7.2 Bilan personnel

De mon point de vue, ce stage a été un succès autant sur le plan humain que dans mon épanouissement dans ce projet. Très intéressé par l'utilisation de mes compétences en informatique au profit des enjeux environnementaux, le stage et mon intégration dans l'équipe STEEP m'ont permis d'avoir un aperçu des liens possibles entre l'informatique et les domaines de la prospective et de la soutenabilité.

Le développement du jeu a été très enrichissant. D'abord, par le besoin de maîtriser plusieurs sujets en lien direct avec mes études en informatique et en mathématiques. J'ai pu mettre en application et perfectionner mes connaissances pour structurer l'ensemble du jeu, qu'il s'agisse du client web et de son ergonomie, du serveur comprenant les mécanismes du jeu ou encore de la génération de visualisations. Ce travail de développement a aussi demandé la maîtrise d'autres domaines pour lesquels je n'ai pas eu de formation scolaire comme le design de jeux sérieux et la compréhension des phénomènes biophysiques. J'ai apprécié me former dans ces sujets afin de mieux saisir les enjeux environnementaux et sociétaux ainsi que les approches pour vulgariser et faire débattre ces enjeux.

Enfin, ce stage était ambitieux dans sa séparation en deux sujets complémentaires. Cette approche a été très intéressante, car nous avons réussi avec mon binôme à nous approprier le sujet et développer le jeu à deux en gardant des missions distinctes. J'ai ainsi pu exprimer mon savoir-faire informatique en implémentant la version numérique tout en contribuant directement à la conception des mécaniques du jeu.
Références

[1] Linda Booth Sweeney, Dennis Meadows, et Gillian Martin Mehers. *The Systems Thinking Playbook for Climate Change*. URL: https://klimamediathek.de/wp-content/uploads/giz2011-0588en-playbook-climate-change.pdf (p 7).

[2] Mathilde BOISSIER, Nils FERRAND, Emmanuel KRIEGER, Jean-Yves COURTONNE, et Peter STURM. *Playing with flows in transition territories*. URL: https://hal.science/hal-04231486v2 (p 7).

[3] Nicolas BECU. *Les courants d'influence et la pratique de la simulation participative : contours, design et contributions aux changements sociétaux et organisationnels dans les territoires*. URL: https://hal.science/tel-02515352 (p 12).

[4] Gilles BROUGÈRE. *Jouer et apprendre*. URL: https://hal.science/hal-03585076 (p 12).

[5] Hua WANG, Cuihua SHEN, et Ute RITTERFELD. *Serious Games: Mechanisms and Effects*. URL: https://doi.org/10.4324/9780203891650 (p 14).

[6] *ComMod : Companion Modelling*. URL: https://www.commod.org/ (p 14).

[7] *Gamae - Games for agriculture, alimentation & environnement*. URL: https://gamae.fr/ (p 14).

[8] *Gamae. La Grange*. URL: https://la-grange.hub.inrae.fr/ (p 14).

[9] *Gamae. MigrationS*. URL: https://ludotheque.gamae.fr/game/76 (p 14).

[10] *Commod. Kung Krabaen Bay*. URL: https://www.commod.org/etudes-de-cas/kung-krabaen-bay (p 14).

[11] UMR G-EAU. *My River Kit*. URL: https://www.gesteau.fr/vie-des-territoires/my-river-kit-un-jeu-de-role-pour-sensibiliser-la-gestion-integree-des (p 14).

[12] Léa VIENOT. *Démonstrateurs pour l'analyse d'alternatives socio-techniques*. URL: https://inria.hal.science/hal-03867864v1 (p 15, 36).

[13] *Sim4nexus: Serious Game*. URL: https://sim4nexus.eu/page.php?wert=Projectoverview (p 16).

[14] *MAGIC Nexus*. URL: https://magic-nexus.eu/magic-nexus-game (p 16).

[15] *MAGIC Nexus (Document de référence)*. URL: https://magic-nexus.eu/sites/default/files/files_documents_repository/magic_deliverable_7.5_-_main_report_PLUS_annexes.pdf (p 16).

[16] Mathilde BOISSIER, Nils FERRAND, Laurence BOISSIEUX, Roger PISSARD-GIBOLLET, et Achraf KERZAZI. *Transkey, version 2023* (p 17).

[17] Jean-Yves Courtonne. *Evaluation environnementale de territoires à travers l'analyse de filières*. URL: https://theses.hal.science/tel-01421664 (p 38).
# Annexes

## A Présentation visuelle du jeu de plateau

Plateau et exemple d'activités à placer sur les terrains :

<figure><img src="image_21.png" /></figure>

Routes pour lier les territoires et rond-point central avec indicateur de GES :

<figure><img src="image_22.png" /></figure>
# B Exemple de fichiers de configuration

Exemple d'une configuration complète (six fichiers au format YAML) pour une partie :

## Fichier de jeu

```yaml
2 activities categories:
3   secteur primaire: "#aaffaa"
4   énergie: "#85caff"
5
6 resources categories: ["Indicateurs", "Ressources"]
7
8 visible info: # Informations visibles sur le plateau
9   other resources: True
10
11 fix road cost: # Coût de réparation d'une route
12   énergie: 8
13
14 turns: 4
```

## Fichier des territoires

```yaml
2 territoire 1:
3   max actions: 2
4   terrains: 15
5   color: "#0000ff"
6
7 territoire 2:
8   max actions: 3
9   terrains: 20
10   description: "Description du territoire 2"
```

## Fichier des ressources et indicateurs

```yaml
2 eau:
3   image: "chemin/image/eau"
4   visible: True
5   color: "#0000ff"
6   traded:
7     normal: True
8     broken: False
9   reset: True
10   category: "Ressources"
11
12 énergie:
13   image: "chemin/image/energie"
14   visible: True
15   color: "#d46820"
16   # Précise si la ressource peut
17   # être échangée selon les situations
18   traded:
19     normal: True
20     broken: True
21   reset: True
22   category: "Ressources"
23
```
## Fichier des activités

<figure><img src="image_23.png" /></figure>

## Fichier des objectifs

<figure><img src="image_24.png" /></figure>

## Fichier des états initiaux

<figure><img src="image_25.png" /></figure>