Brevet FR3014700A1 — publié le 20150619

Architecture informatique pour la production de jeux sérieux Depuis une dizaine d'années, on constate que les propriétés d'apprentissage inhérentes aux jeux-vidéo incitent 5 de nombreux développeurs à explorer leur potentiel en tant que moyen d'expression pour des buts divers et innovateurs (sérieux). L'apprentissage est au coeur de l'expérience de jeu, mais il prend normalement place dans les domaines affectifs et psychomoteurs. Quand l'apprentissage cible un contenu sérieux, 10 des designers cognitifs/pédagogiques doivent veiller à son effectivité dans le domaine cognitif. Dans des équipes éminemment multidisciplinaires (jeu, technologie, cognition et art), la compréhension et la communication sont indispensables pour une collaboration efficace dès la première étape de 15 conception. Dans une approche génie logiciel, on s'intéresse aux activités (multidisciplinaires) du processus de développement plutôt qu'aux disciplines elles-mêmes, dans le but d'uniformiser et clarifier le domaine. Puis, nous proposons une fondation logicielle qui renforce ce modèle 20 multidisciplinaire grâce à une approche d'underdesign qui favorise la création des espaces de design collaboratifs. Ainsi, Genome Engine peut être vu comme une infrastructure sociotechnique dirigée-donnée qui permet à des développeurs non-programmeurs, comme le gaine designer et éventuellement le 25 designer cognitif, de participer activement dans la construction du design du produit, plutôt que de l'évaluer déjà en temps d'utilisation. Son architecture est fondée sur un style de système de systèmes d'entités, ce qui contribue à sa modularité, sa réutilisabilité et adaptabilité, ainsi qu'à 30 fournir des abstractions qui favorisent la communication. Plusieurs projets réels nous ont permis de tester notre approche. Le développement de jeux-vidéo est éminemment multidisciplinaire. Le design d'un jeu-vidéo peut se décortiquer en plusieurs axes fondamentaux : jeu, technologie et art. Les jeux-sérieux profitent des propriétés d'apprentissage inhérentes aux jeux-vidéo pour des buts autres que le simple ludisme. Dans ce cas, un nouvel axe de design cognitif/pédagogique doit veiller à assurer que l'apprentissage du contenu sérieux a lieu dans le domaine cognitif (Gunter, Kenny, and Vick 2006), en plus des domaines affectif et psychomoteur d'apprentissage plus habituels dans les jeux-vidéo conventionnels. Description détaillée des figures : - La figure 1 illustre la multidisciplinarité des équipes de design de jeux-sérieux, et il est basé sur un diagramme extrait des travaux de recherche de Mackay (2003), La figure 2, illustre les buts et contenus sérieux 15 qui doivent être incorporés dès la première phase de conception, - La figure 3 illustre le processus d'ingénierie des exigences pour le jeu-sérieux doit être lu d'une manière itérative (la spécification ne doit forcément être complète 20 avant de commencer le design, mais plutôt construite d'une manière incrémentale), - La figure 4 illustre les principales activités et processus le long des phases de développement. Ce diagramme doit être lu d'une manière itérative, ce qui signifie que 25 chaque activité a, en effet, lieu dans chaque itération, mais avec différents rapports d'effort selon la phase. - La figure 5 illustre un stockage intelligent d'entités centralise l'accès aux données. Plusieurs systèmes accèdent à des ensembles d'entités homogènes (mêmes 30 propriétés) pour y appliquer des comportements d'une manière abstraite, - La figure 6 est une vue logique de l'architecture basée sur une séparation des données et logique (comportement) - La figure 7 est une vue détaillée du framework coeur du moteur. Ce diagramme présente des détails qui ne sont pas nécessaires dans la pratique. Grâce à des techniques d'inversion de contrôle, tous ces détails d'assemblage pourront être omis des diagrammes de blocs de nos systèmes. - La figure 8 présente une architecture d'exemple d'un monde de jeu. Un système de management de ressources flexible rend l'approche dirigée-donnée beaucoup plus puissant, permettant d'architecturer nos données afin de les adapter aux besoins de production. - La figure 9 présente une architecture dure standard d'un développement de jeu-sérieux. Ce diagramme omet des détails non nécessaires grâce à l'inversion de contrôle, et montre comment utiliser les diagrammes des composants d'une manière agile. - La figure 10 présente une architecture souple du jeu-sérieux selon l'invention. Comme on peut le constater, le game design n'est pas suffisant pour assurer une métaphore intrinsèque d'un jeu- sérieux (Fabricatore 2000). Pendant le développement, le game designer agit en tant qu'avocat du joueur (Schell 2008), et veille donc à ce que l'expérience de jeu soit optimale pour atteindre le but ludique du jeu. Dans le cas, d'un jeu-sérieux le game designer doit aussi créer un concept de jeu capable d'inclure le but et contenu sérieux. D'une manière analogue, le designer cognitif doit veiller à ce que le but et contenu sérieux soient bien compris par le reste de l'équipe, mais aussi à définir une méthode d'apprentissage en _accord avec le concept de jeu. En fin de comptes, le développement d'un jeu- sérieux doit intégrer les buts et contenus pédagogiques dès les premières phases de conception, afin de permettre la création d'une métaphore intrinsèque (fondamentalement un concept de jeu) qui intègre d'une manière naturelle le but et contenu sérieux sans interférer dans sa jouabilité. Dans la première phase de conception d'un logiciel conventionnel, une des tâches les plus complexes est d'en définir l'essence (Robertson 2006). Dans le cas d'un jeu-sérieux, sa métaphore intrinsèque constitue l'essence du système, et doit être incorporée en tant qu'objectif de haut niveau pour guider son développement. Cette inclusion, que l'on apprécie dans la figure 2, répond au fait que la dimension pédagogique doit être subordonnée à la dimension ludique (Zyda 2005). 10 Dans notre approche, comme on peut le constater, le processus de design est éminemment multidisciplinaire dès les premières étapes de conception. Dans un but d'uniformisation et clarification du processus de développement, on présente le modèle suivant basé sur des principes de génie logiciel 15 adaptés au cas particulier des jeux-sérieux. Modèle multidisciplinaire de développement Les notions fondamentales du génie logiciel (ingénierie des exigences, modélisation du système, procédés, méthodologies, réutilisation) sont universellement applicables 20 au développement de tous types de système (Sommerville 2011). On propose un modèle de développement basé principalement sur deux aspects : l'ingénierie des exigences et le développement incrémentai et itératif. Ingénierie des exigences 25 Le recueil des besoins et la définition des exigences sont la base du développement de tout système, certes avec des degrés variables de formalisme en dépendant de la taille et de l'agilité du projet. On ne peut pas construire quelque chose tant que l'on ne sait pas ce qu'il faut 30 construire. Des spécifications pauvres ou incomplètes sont une des grandes causes d'échec de nombreux développements logiciels, parmi lesquels les jeux-vidéo présentent un plus grand défi de par leur nature interactive et expérimentale. Une approche d'ingénierie des exigences ne vise pas à imposer des formalismes et procédures, qui pourraient étouffer la créativité indispensable à la conception des jeux ; elle vise plutôt à établir et rafraichir ses principes fondamentaux, laissant chacun décider du degré de formalisme approprié à l'agilité du projet. De fait, la créativité n'est pas du tout incompatible avec l'ingénierie des exigences, mais fait partie des compétences d'un bon analyste logiciel. Spécifier un produit qui rend plus facile la tâche des utilisateurs et parties concernées requiert souvent des manières innovantes et créatives d'accomplir le travail. Ainsi, les exigences insoupçonnées sont celles dont l'utilisateur n'est pas conscient d'avoir besoin. De cette manière, les exigences définies par un gaine analyst sont principalement de type insoupçonné, ce qui les rend généralement plus difficiles à évaluer. La figure 3 présente un processus d'ingénierie des exigences pour les jeux-sérieux d'après le modèle de Robertson (2006). Dans la figure 3 on peut retenir plusieurs procédés et pratiques intéressantes. Premièrement, le gaine blastoff (ou kickoff, démarrage, etc.) est une activité qui regroupe toutes les informations nécessaires pour entamer le développement du projet : définir la portée du projet, les parties concernées, les utilisateurs, les objectifs de haut niveau, les risques majeurs, etc. Le projet ne devrait pas commencer tant que le blastoff n'est pas fait, afin d'éviter un travail de recherche et d'exploration sans une direction concrète. Deuxièmement, les procédures comme le Ouality Gateway et le Review of the Specification veillent à ce que les exigences ne soient pas incomplètes ou ambiguës, la première d'une manière individuelle et la deuxième d'une manière collective. Ensemble, elles visent à aider les équipes de développement à éviter des problèmes typiques comme le feature-creep (Adams 2009), gold-plating, ou des exigences non identifiées, etc. En d'autres mots, elles veillent à ce que l'introduction d'exigences soit justifiée selon les contraintes et l'avancée du projet. Développement incrémental, itératif et multidisciplinaire Dans ces modèles de développement, le système 10 logiciel grandit d'une manière incrémentale par le biais d'itérations consécutives. La principale mesure visible de progrès est le logiciel fonctionnel, un sous-ensemble du produit final. En fait, le feedback récolté à la fin de chaque itération sert à -planifier la suivante. Ceci contribue à 15 minimiser l'effet de paralysie par analyse, et amène les équipes à tester et évaluer le projet et les risques majeurs des premières étapes de développement. Parmi les modèles itératifs, le Processus Unifié (UP) semble être celui qui convient plus à nos besoins de 20 développement. Ce framework de développement divise la durée de vie du projet en quatre phases distinctes, qui se rapprochent de celles présentées par la plupart des développeurs de jeux-vidéo : La phase de création (inception) correspond à 25 l'activité de blastoff, dont le but principal est d'en établir la faisabilité et la portée. L'équipe doit identifier les risques majeurs et définir le « development case » qui corresponde à la taille et à l'ambition du projet. Dans un jeu-sérieux, cette phase doit établir la portée du contenu et 30 but sérieux, et permettre d'imaginer un premier game concept non détaillé qui en garantit la métaphore intrinsèque. La phase d'élaboration se concentre sur le design et la construction des fondations logicielles du système. à la fin de cette phase, le coeur de l'architecture doit être stabilisé et la faisabilité des parties plus pertinentes, complexes et risquées, évaluée. Cette phase correspond à la phase de pré-production du jeu-vidéo, où un premier prototype jouable permet d'en évaluer la faisabilité développementale, 5 commerciale et jouable. Dans le cas d'un jeu-sérieux, on doit veiller à ce que la métaphore intrinsèque marche une fois en mouvement. À la fin de cette phase, le manager du projet se trouve en état de créer un plan de production détaillé pour attaquer la prochaine phase de développement. Cette transition 10 est complexe et entraîne souvent des risques (Kanode and Haddad 2009). La phase de construction est la plus longue du développement : l'équipe grandit et atteint sa capacité productive maximale. Durant cette phase, on doit éviter des 15 changements architecturaux, très coûteux à ce stade. Toutes les fonctionnalités sont développées d'une manière incrémentale à mesure que les itérations se succèdent. Elle correspond à la phase de production dans le domaine du développement des jeux-vidéo. L'équipe se concentre sur la 20 création de game assets (niveaux de jeu, modèles graphiques, sons, scénarios de jeu, code, etc.). La production d'assets est coûteuse, et sa planification doit tenir compte de la technologie sous-jacente, puisqu'elle va fortement influencer la manière d'interagir et collaborer entre les divers 25 développeurs (game designer, programmer, level designer, etc.). La phase de transition correspond à la phase de polishing du jeu-vidéo. Son but principal est de tester et évaluer le produit dans son ensemble. C'est une phase plutôt 30 soustractive qu'additive, puisqu'une équipe plus réduite travaille afin d'améliorer l'expérience de jeu dans son ensemble à travers des modifications minimes. Cette phase est très importante puisqu'elle peut faire la différence entre un jeu prometteur et un jeu abouti. Comme on peut le constater, les phases de développement du jeu-vidéo correspondent à celles de UP. Etant donné qu'il s'agit d'un framework personnalisable, on peut considérer le développement du jeu-vidéo comme un cas 5 particulier et agile de ce modèle. La figure 4 tente d'unifier ces modèles de développement dans un unique diagramme. On apprécie comme les phases de développement cherchent à réduire l'espace de design dans la direction qui mène au produit désiré. Elles cadrent la 10 proportion d'effort à consacrer à chaque activité de développement selon de l'avancement du projet. Ainsi, on constate comme les activités de modélisation et design sont prédominantes dans les premières phases, et comme les activités de construction prennent de plus en plus de place à 15 mesure que le design se concrétise. Les activités de développement (en turquoise) héritent du même symbolisme que la figure 1. Les points autour de chaque activité représentent les disciplines intervenantes, dans le but de remarquer sa nature multidisciplinaire : 20 Le recueil d'exigences (requirements gathering) est le processus qui étudie le problème et en spécifie la solution. Cette activité est indispensable pour guider le développement et intégrer de nouveaux besoins qui peuvent survenir durant le projet. Elle est fondamentale dans les 25 premières étapes de développement, et un processus continu durant tout le projet. o Recueil d'exigences jouables (Game requirements gathering): les game analysts se concentrent sur l'identification des besoins éminemment 30 jouables, issues du joueur. o Recueil d'exigences logicielles (Software requirements gathering) : les software analysts se concentrent sur le recueil des besoins des parties concernées du système et le recueil des besoins architecturaux. o Recueil d'exigences cognitives (Cognitive requirements gathering) : les ingénieurs cognitifs ou pédagogiques se concentrent sur le recueil des besoins d'apprentissage (objectifs pédagogiques, méthodes d'apprentissage, etc.) ® La modélisation du système (system modeling) est le processus qui produit les modèles abstraits du système sous différents angles : structure, organisation, comportement, interaction, etc. (Sommerville 2011). Ces modèles visent à étudier, l'un et l'autre, le système existant et le système à développer, et aident à la concrétisation des exigences du système : o La modélisation jouable du système (game system modeling) : les modélisateurs du jeu se focalisent principalement sur les dynamiques et mécaniques de jeu de haut niveau : structure de jeu, boucle de jeu, les dynamiques non- détaillées du système de jeu. o La modélisation logicielle du système (software system modeling) : les modélisateurs du système logiciel produisent des modèles qui décrivent la vue technologique du jeu, et son principalement des diagrammes d'architecture du système (diagrammes des composants logiciels de jeu, vue de procès, diagrammes de contexte, etc.). Son intervention peut être plus importante quand il s'agit d'un jeu-sérieux fortement basé sur une simulation du domaine. o La modélisation cognitive du système (cognitive system modeling) : les ingénieurs cognitifs visent principalement à étudier la connaissance du contenu sérieux. Ils peuvent produire des modèles cognitifs (Paquette, Lundgren-Cayrol, and Léonard 2008), des ontologies ou des bases des connaissances catégorisées (Capdevila, Boudier, and Labat 2009). d Le design du produit (Product Design) est le processus qui traduit les modèles et exigences abstraites en un design du monde réel. Ceci signifie que le design concrétise un système abstract en un produit conscient de la technologie, une vue technique du produit à partir de laquelle on peut créer un plan de production. La collaboration entre l'axe jeu et cognition est indispensable pour créer une expérience ludique-pédagogique satisfaisante : o Le design jouable du produit (Game Product Design) concrétise les dynamiques de jeu d'haut niveau en mécaniques coeur (Adams 2009) qui détaillent les attributs des différentes entités du jeu et les règles qui les gouvernent, ainsi que la succession et structure des différents niveaux de jeu. o Le design logiciel du produit (Software Product Design) rentre dans le design concret de chacun des composants et son rapport avec la technologie existante. o Le design cognitif du produit (Cognitive Product Design) détaille l'échafaudage d'objectifs pédagogiques, la progression appropriée de l'apprentissage des compétences et connaissances. La construction du produit (Product Build) est le processus qui matérialise le design du produit. Dans le développement d'un système logiciel conventionnel, cette phase consiste principalement à implémenter le design, le programmer. Il est donc dans cette activité de développement où l'approche underdesign prend tout son sens pour permettre les game designers et les designers cognitifs de participer à la construction du produit (level designers, content designers, etc.). Comme on verra, une approche dirigée-donnée (datadriven), est une des techniques les plus répandues dans le milieu du jeu-vidéo à ce propos. ^ L'utilisation du produit (Product Usage) est le processus d'utiliser et évaluer le produit pour en tirer des conclusions qui nous aident à raffiner le produit et à ne pas nous dévier du but. Cette activité est spécialement importante dans le cas des jeux et jeux-sérieux à cause de sa nature expérimentale. La plupart des fois on ne sait pas si on construit le bon produit jusqu'à ce que l'on l'utilise. Ce processus doit veiller à ce que l'efficacité ludique/pédagogique du système de jeu soit satisfaisante. Ce modèle propose un cadre de développement adapté aux jeux-sérieux. Il hérite et unifie des procédures et bonnes pratiques du génie logiciel, mais montrent aussi comme les bonnes pratiques issues du milieu du jeu-vidéo sont aussi fondées sur leurs principes. Nos développements normalement ne dépassent pas les six mois de développement. Ce modèle de développement peut sembler rigide ou trop formel. Mais, on doit se concentrer sur ses principes et raisons d'être, et l'utiliser de la manière qui mieux convient à nous besoins de production. Dans une approche de développement agile, nous devons mettre l'accent sur les membres de l'équipe et leurs interactions, plutôt que sur les procédures. C'est à nous de choisir le dégrée 'd`t formalité et la quantité de documentation nécessaire. Dans la prochaine partie, nous présentons les principales caractéristiques de Genome, un moteur de jeu qui dont le but est de supporter ce modèle de développement agile. Premièrement, une architecture modulaire basée sur les composants logiciels vise à rendre plus agile la modélisation du système dans un cadre de développement UP qui est centré sur l'architecture. Deuxièmement, l'architecture de son modèle d'objets de jeu est basé sur un système d'entités, un style qui s'adapte très bien à une architecture des données centralisées, très appropriée pour l'implantation d'une approche dirigée-donnée. Le moteur Genome Les besoins architecturaux de ce système sont principalement la réutilisabilité, la modularité et une bonne qualité d'intégrabilité des données. Nous soulignons que cette dernière caractéristique est fondamentale pour réussir un moteur avec une approche dirigée-donnée. Cette qualité détermine la capacité d'un système à transformer des données statiques et persistantes (fichiers, bases des données, etc.) dans un système dynamique fonctionnel. Ainsi, on vise à ce que les assets créés par des non-programmeurs soit facilement intégrables dans un jeu en mouvement. Les choix architecturaux pour atteindre ces exigences architecturales sont principalement : ^ Un style architectural des données centralisées, essentiellement basé sur un stockage central qui donne accès aux données à divers clients indépendants. Basé sur notre expérience antérieure et sur les recherches de Plumer (2004), ce style est très adapté à des approches dirigée-donnée, et promet une bonne offre d'extensibilité, par la simple addition des nouveaux clients indépendants sur le stockage central. Un modèle d'objet de jeu centrée-propriété (ou Runtime Object Model en anglais) (Gregory 2009). Cette vision des objets de jeu conçoit les entités primairement par rapport aux propriétés qu'elles possèdent, en opposition à l'approche centrée-objet, qui conçoit les objets selon les attributs et les comportements qui le définissent, et qui s'approche plus de la programmation classique orientée-objet. Une vue centrée-propriété est plus adaptée aussi à des approches dirigées- donnée (Gregory 2009). Aussi, ceci se rapproche plus de la manière dont les game designers conçoivent les entités de jeu (entités et ses attributs) (Adams 2009). Ces deux principes architecturaux ont démontré qu'ils se mariaient très bien par le biais d'une architecture de systèmes d'entités. Dans cette approche récente, les entités sont conçues comme des simples identifiants qui assemblent des propriétés (containeurs des données passifs) dans des unités logiques d'existence. Un manager central se charge de maintenir le modèle d'entités et d'en donner accès aux clients d'une manière intelligente. Ainsi, les entités sont essentiellement des données accessibles à travers des modèles d'entités : ensembles d'entités avec des propriétés communes. Les systèmes sont des clients qui requièrent des modèles d'entités et appliquent des comportements en temps réel. Ils sont donc le mécanisme fondamental pour implémenter des comportements de jeu (de bas et haut niveau). La figure 5 est une vue d'ensemble de cette architecture. Dans la figure 5, nous pouvons apprécier comme plusieurs systèmes appliquent des comportements et des règles sur l'ensemble d'entités. Par exemple, le système Physics traite toute entité ayant la propriété Position et la propriété Physic. La première donne à l'entité une position, une rotation et une taille dans l'espace de jeu. La deuxième fournit les propriétés physiques à l'entité, comme son accélération, force, torsion, etc. Le système applique les règles de la physique à toutes ces entités d'une manière abstraite. Cette représentation est très puissante puisqu'elle nous permet d'appliquer de multiples comportements sur les mêmes données sans modifier les entités ou les propriétés. On remarque que les systèmes de collisions, de physiques et de rendu traitent tous de la même propriété Position. Les systèmes ne se soucient pas de l'identité des entités, mais seulement des entités qui possèdent les propriétés qui les intéressent, pouvant les traiter d'une manière abstraite. La figure 6 présente l'architecture logique du 10 système, qui sépare la logique des données par design afin de renforcer l'approche dirigée-donnée. 1.1.1 Core engine framework Même si les systèmes offrent un bon degré de flexibilité et d'extensibilité, nous voulons réussir des 15 designs plus componentiels pour faciliter une vue de l'architecture comme un diagramme de blocs. Nous nous sommes donc intéressés à des techniques d'inversion du contrôle (IoC). En opposition à des contrôles conventionnels de l'exécution plus impératifs, l'inversion du contrôle délègue 20 des tâches de bas niveau, comme l'assemblage d'interfaces des composants à une entité ou agent externe, dans notre cas le framework Genome. Ainsi, le framework se charge d'assembler les interfaces requises et fournies de tout composant (logique) qui est rajouté dans le système. 25 L'invention concerne à ce titre une architecture informatique pour la production de jeux sérieux, comportant un ensemble cohérent de composants logiciels structurels, ces composants logiciels étant génériques caractérisé en ce que ledit ensemble comprend cinq sous-systèmes : 30 - un gestionnaire de processus, contrôlant le temps réel (échelle, avancement) et la mise à jour des composant implémentant l'interface de processus, - un gestionnaire d'entités chargé de centraliser le cycle de vie des entités, - un gestionnaire de propriétés chargé de centraliser le cycle de vie des propriétés - un gestionnaire de dépendances chargé de gérer l'injection de dépendances - un gestionnaire des systèmes chargé de centraliser tous les systèmes d'entités. Le framework coeur du moteur est donc composé de cinq sous-systèmes : ^ Le manager de procès: se charge de contrôler le temps réel (échelle, avancement) et de mettre à jour tout composant implémentant l'interface IProcess. ^ Le manager d'entités est chargé de centraliser le cycle de vie des entités ^ Le manager de propriétés est chargé de centraliser le cycle de vie des propriétés ^ Le manager de dépendances est chargé de gérer l'injection de dépendances ^ Le manager des systèmes est chargé de centraliser tous les systèmes d'entités L'architecture et design de chacun de ces sous-25 systèmes contribue à la qualité d'intégrabilité des données et, donc, à une approche dirigée-donnée. Aussi, on peut trouver une analyse plus profonde sur les mécanismes de synchronisation du moteur, très pertinents dans une architecture si basée sur le temps réel. La figure 7 est une 30 version simplifiée du framework coeur du moteur. 1.1.2 Sous-système de gestion de ressources Jusqu'ici nous avons un runtime capable de mettre en mouvement une simulation temps réel d'agents (entités avec des comportements en temps réel). Donc, nous avons un runtime qui est prêt pour une approche dirigée-donnée (vue d'objet centrée-propriété, création abstraite et personnalisable d'entités et propriétés). Mais ceci n'est pas suffisant. Pour vraiment exploiter la puissance de l'approche dirigée-donnée, il nous faut un management flexible des ressources (les données persistent en forme de fichier ou base des données) qui nourrisse ce runtime avec les assets de jeu créés par les développeurs (game designers, designers de contenu, level designers, etc.). Le dégrée de flexibilité du management des ressources et assets va déterminer la productivité de l'approche d'underdesign. Les éléments principaux de notre système sont les entités et les mondes (worlds). Le système se charge de la gestion des références croisées entre ressources. Ainsi, une ressource monde ne sera prête à l'utilisation que quand toutes les entités qui le constituent le seront aussi. Les mondes de jeu nous permettent de structurer nos mondes d'une manière logique et d'une manière statique. Ceci signifie que nous sommes capables de découper nos niveaux de jeu en plusieurs fichiers distincts. Nous pouvons par exemple, séparer les entités décrivant la scène de jeu (arbres, bâtiments, personnages, etc.) et les entités décrivant le scénario (triggers, évènements, objectifs, etc.). Ceci permettrait à plusieurs game designers de travailler en parallèle sans se gêner. Ce système offre de grandes possibilités pour architecturer les données afin de nous adapter aux besoins concrets de production et level design. La figure 8 l'illustre. Jusqu'ici, le lecteur aura remarqué qu'il n'y a aucune trace des jeu-sérieux dans l'architecture de notre moteur. Comme nous l'avons déjà dit, d'un point de vue technique, rien ne distingue les jeux-sérieux des jeux conventionnels, au moins dans le bas niveau : les deux nécessitent un runtime capable de maintenir un modèle d'objets de jeu sur lequel appliquer des comportements en temps réel, ainsi qu'un sous-système de management des ressources qui nous permet de charger facilement des niveaux de jeu. De cette manière, les applications et composants spécifiques au jeu-sérieux doivent être basées sur les systèmes de fondation gameplay (Gregory 2009), que nous introduisons par la suite. Ces fondations fournissent des composants logiciels qui permettent aux développeurs de définir l'épine de notre jeu. Fondamentalement, ces composants permettent la création de comportements de haut niveau afin de créer la séquence d'objectifs du joueur. Elles sont donc essentielles pour la génération de la jouabilité à travers les challenges. Elles permettent d'évaluer l'accomplissement d'objectifs, et d'envoyer le joueur d'une région de jeu vers la suivante. Aussi, elles devraient permettre de changer de modes de jouabilité. La plupart des moteurs fournissent un langage de script pour permettant aux non programmeurs de créer des comportements sans avoir à les compiler. En définitive, ces fondations permettent la création du flux et la progression dans le jeu.. La figure 9 présente l'architecture dure typique d'un de nos développements. Elle distingue également les composants qui font partie du framework coeur des managers de bas niveau, dont les sous-systèmes des ressources sont les plus importants, et les systèmes d'entités de bas niveau. Comme on peut le constater, le diagramme situe les fondations logicielles de gameplay et les systèmes d'entités de mécaniques de jeu à un niveau d'abstraction plus élevé. Architecture souple de Genome L'architecture présentée auparavant se concentre sur les systèmes de bas niveau, et est habituellement facilement réutilisable entre projets. L'architecture souple 5 ou architecture du game design est plus concernée par les mécaniques spécifiques à notre projet, et est plus difficilement réutilisable entre projets. Ainsi, le design de l'architecture souple consiste essentiellement en un design de systèmes d'entités. Naturellement, le gameplay est 10 fondamentalement construit autour des mécaniques de jeu, et les systèmes d'entités sont le moyen de les implémenter. La flexibilité de design des systèmes d'entités se manifeste pleinement à ce niveau d'architecture. En fait, dans notre travail, nous présentons plusieurs exemples concrets qui 15 illustrent les bonnes pratiques afin de définir la bonne granularité de nos propriétés et systèmes, de représenter des associations entre entités, etc. Aussi, nous présentons un projet d'exemple qui illustre comment ces systèmes d'entités permettent de décomposer la complexité en plusieurs systèmes 20 plus simples. Un des buts de l'invention est la réutilisation de composants logiciels à ce niveau d'architecture. Comme le constatent plusieurs auteurs, l'architecture souple est normalement propre à un jeu, et rarement réutilisée (Rollings 25 and Morris 2003). Les fondations de gameplay sont largement réutilisées entre projets puisque tous les projets ont besoin de créer des scénarios de jeu et des challenges. Dans Genome, ces systèmes permettent la création de niveaux de jeu, de 30 déclencheurs, d'évènements de jeu et d'objectifs de jeu. À mesure que le niveau d'abstraction augmente, le design de systèmes d'entités devient plus complexe puisqu'il implique des systèmes qui opèrent sur une majeure partie des propriétés des domaines spécifiques. Ceci ne veut pas dire qu'ils ne soient pas réutilisables, mais plutôt que leur réutilisation dépend du domaine d'application. Comme exemple, nous avons créé un module de systèmes d'entités pour mettre en place des simulations économiques. Nous pouvons créer des stockages, des convertisseurs, des producteurs, des consommateurs et des traders de ressources de jeu. Ainsi, en composition avec des propriétés spécifiques à notre domaine d'application (une ferme par exemple) elles permettent la création d'économies complexes. Par contre, sa réutilisation dépendra du domaine de notre simulation. Un jeu-sérieux sur les technologies cosmétiques va rarement requérir sa réutilisation. La figure 10, illustre l'architecture souple d'un jeu-sérieux selon l'invention. Il utilise les fondations 15 gameplay ainsi que le module économique afin de créer une simulation d'exploitation agricole : Dans notre travail nous analysons plus en détail ce design. Nous pouvons observer une nouvelle représentation des systèmes d'entités. Dans ce projet, nous avons expérimenté la 20 flexibilité des systèmes d'entités, et sa puissance pour la création de systèmes de systèmes. Nous pouvons voir comment un système est composé de plusieurs systèmes grâce au partage de certaines propriétés (Country). De plus, ce design concret démontre comment les systèmes d'entités contribuent à la 25 localisation de connaissances. Dans ce développement, nous avons d'abord créé les systèmes d'économie. Une fois construits et testés, nous avons entrepris la modélisation de la simulation agricole grâce à l'extensibilité des systèmes et la composition des entités. 30 Grâce à la nature industrielle de ce travail, nous avons évalué et testé le moteur avec le développement d'une dizaine de jeux-sérieux, dans des conditions de production réelles. Par contraintes de temps, nous n'avons pas eu la possibilité de complémenter nos évaluations qualitatives des statistiques qui les quantifient. On a constaté comment, à mesure que les projets se succédaient et que la librairie des composants grandissait, 5 les développements pouvaient se concentrer sur des fonctionnalités spécifiques du jeu en question. Aussi, naturellement, l'équipe de développement a acquis de l'expérience et s'est adaptée à ce nouveau mode de fonctionnement. Les membres de l'équipe ont mis en place des 10 automatismes d'une manière naturelle, ce qui est une preuve de la bonne adaptation du moteur à des méthodologies agiles. L'approche dirigée-donnée, renforcée par une gestion flexible des ressources, a aussi beaucoup contribué à créer des espaces de design pour des développeurs non- 15 programmeurs. Sur certains projets, une dizaine de développeurs ont été capables de travailler en parallèle sur des fichiers XML distincts. En termes de développement, l'architecture de systèmes d'entités facilite énormément la répartition des tâches et le développement incrémentai. 20 Afin d'évaluer comment Genome favorise la collaboration au sein d'une équipe multidisciplinaire, parcourons les différentes activités de développement une par une : ^ Recueil d'exigences: la librairie des systèmes d'entités est 25 son principal facilitateur. A mesure qu'elle augmente, augmente aussi l'expérience des gaine designers et des ingénieurs, qui peuvent réutiliser le savoir-faire acquis dans des projets précédents. ^ Modélisation du système : comme on l'a vu, le design de 30 l'architecture dure du système est assez- standard et requiert des petits changements entre projets. La modularité du framework facilite aussi une création agile des modèles du système (diagrammes de blocs). Aussi, à mesure que les game designers se familiarisent avec les abstractions et systèmes du moteur, la communication et la collaboration deviennent plus fluides. ^ Design du produit: L'approche centrée-propriété contribue au design collaboratif des systèmes d'entités qui implémentent les mécaniques de jeu. ^ Construction du produit: C'est dans cette activité que l'approche dirigée-donnée prend son plus grand sens. Les données constituent l'espace fondamental de travail collaboratif. L'architecture des mondes renforce la collaboration. K Usage du produit: une approche dirigée-donnée peut être aussi intéressante pour permettre la modification du jeu en temps d'utilisation. Par exemple, des professeurs d'école, avec l'aide d'un éditeur simple, seraient capables de modifier le scénario du jeu afin de l'adapter à leurs besoins pédagogiques spécifiques. - Les résultats sont prometteurs: consolidation de l'API du moteur, gestion plus automatisée de systèmes d'entités composés, création des templates XML des architectures dures 20 et souples des jeux-sérieux types, développement d'extensions spécifiques aux jeu-sérieux. REVENDICATIONS1 - Architecture informatique pour la production de jeux sérieux, comportant un ensemble cohérent de composants logiciels structurels, ces composants logiciels étant génériques caractérisé en ce que ledit ensemble comprend cinq sous-systèmes : - un gestionnaire de processus, contrôlant le temps réel (échelle, avancement) et la mise à jour des composant 10 implémentant l'interface de processus, - un gestionnaire d'entités chargé de centraliser le cycle de vie des entités, - un gestionnaire de propriétés chargé de centraliser le cycle de vie des propriétés 15 - un gestionnaire de dépendances chargé de gérer l'injection de dépendances - un gestionnaire des systèmes chargé de centraliser tous les systèmes d'entités. 20