Part 1.2 - Des maquettes à foison

Article précédent : Le Game Design dans le création d’un jeu vidéo

Précédemment : une carte mentale a permis de mettre en évidence des idées, parmi celles-ci seules quelques une ont été conversées et ont permis la rédaction d’un concept. Enfin, le game concept a permis de structurer et travailler ce concept.

Pour aller plus loin et mettre en situation ces écrits, cette étape consiste à montrer les choix d’implétation à travers des maquettes, et par conséquent la réflexion en terme d’IHM menée en amont.

L’importance de l’IHM

Clé de voûte du jeu, l’interface est fondamentale. En effet, elle a la lourde responsabilité de présenter des informations et permettre l’interaction avec celles-ci. Les chances de succès d’un bon concept mal présenté sont quasi nulles.

Ce travail de forme est primordial, c’est pourquoi l’IHM constitue aujourd’hui une discipline à part entière. L’objectif étant de concevoir (quel est l’objectif ? quelles sont les contraintes ?) et évaluer une interface et les interactions qui en découlent.

Fenêtrage

J’ai choisis de baser l’interface graphique sur un système de fenêtrage car :

  • cela permet de réduire considérablement la prise en main de l’interface parce que tout le monde connaît et utilise ce genre d’interface tous les jours. Pour un jeu de gestion où les menus et informations à l’écran règnent, ce choix peut s’avérer judicieux.
  • cette manière de faire est utilisée dans Her Story (figure ci-dessous). L’interface n’est certainement pas la cause du succès du jeu, mais c’est toutefois intéressant de savoir qu’un jeu avec cette interface peut fonctionner.
  • personnellement face à cette interface j’ai une impression de liberté, de pouvoir faire ce que bon me semble, comme un sur ordinateur en somme. De ce fait, cette idée est en adéquation avec l’intention de ‘jeu ouvert’ énoncée dans la carte mentale (cf article précédent).

Le modèle de fenêtrage s’est avéré être naturellement la réponse à la question comment permettre à l’utilisateur d’effectuer plusieurs tâches simultanément ?

Her Story de Sam Barlow (2015)
“Before window managers, people had to remember their various activities and how to switch back and forth”.
B. Myers. A taxonomy of window manager user interfaces

Il existe plusieurs modèles de fenêtrage :

  • avec/sous superposition
  • hiérarchique.

Il est question ici de superposition parce que, par définition, dans un jeu de gestion les activités en paralléles se multiplient, mais pas de hiérarchie pour risquer de ne pas complexifier l’interface de jeu.

Les fenêtres

Les caractéristiques des fenêtres sont minimalistes : pas d’option pour réduire la fenêtre, pas de redimensionnement possible, juste un déplacement en restant appuyé et la fermeture de celle-ci via la croix.

La barre des tâches

Le menu comporte deux types de fonctionnalité : celles qui permettent d’effectuer une action (créer un objet), d’autres qui permettent de visualiser des résultats. Les options permettant de visualiser ou surveiller un résultat sous-entendent d’avoir besoin de garder en arrière-plan la fenêtre concernée afin d’éviter de répéter une action.

Pour autant, j’ai choisi de ne pas implémenter une barre des tâches parce que, certes si celle-ci a l’avantage d’offrir une solution pertinente en vue de surveiller les activités en cours, elle complexifie cependant le développement de l’interface. En revanche, avec le nombre important de fonctionnalités que pourrait proposer le menu, l’utilisation d’une telle barre à l’avenir pourrait se justifier.

Créer une chose

Le défi du projet étant de permettre au joueur de répondre à la question naïve que veux-tu créer ?, le menu est à cette image. Sans fioritures, il permet d’interagir (créer/gérer) sous quatre axes : les objets, les individus, l’argent et les entreprises.

Menu principal

Dans un premier temps, la première version du jeu est simplifiée au possible. Ainsi, seule l’option Things est disponible. Cette option permet de créer des ‘choses’.

Écran de création d’un objet

Le terme ‘chose’ est capital parce que l’objectif du jeu étant de laisser libre recours à l’imagination dans la création et ainsi ne pas fournir, comme à l’accoutumée, une liste finie d’objets prédéfinis.

Ici une ‘chose’ peut être un bâtiment ou un objet. La distinction est importante parce que les propriétés sont différentes. En effet, comme l’illustre la figure ci-dessous, ils ne répondent pas aux mêmes besoins.

Le problème avec ce concept étant que premièrement on ne constate pas les modifications des propriétés sur la forme (cf capture ci-dessous), deuxièmement en jeu cela ajoute des informations à l’écran et naturellement la question où afficher ces informations ? se pose.

Les propriétés et leurs effets

Une réponse naïve serait d’afficher une popup au survol avec la souris d’un objet en jeu (cf capture ci-dessous) mais cette solution pollue inutilement l’écran de jeu puisque le joueur risque d’avoir que très rarement besoin de ces informations.

Bulle info

Une autre solution serait d’ajouter un bloc d’informations à l’écran visible en permanence (cf capture ci-dessous) mais encore une fois, il s’agit d’une pollution visuelle compte tenu du rapport : information visible à l’écran/besoin de joueur de voir cette information.

Bloc d’informations

Une autre solution est un compromis consistant à reprendre la première solution mais activer la bulle d’information uniquement aux cliques. Cette solution a été retenue.

Menu

Le choix du type de menu (barre de menus, menu contextuel, ligne de commandes, raccourcis, boîte à outils, etc.) est une décision à ne pas négliger. C’est utilisé par tous et sur l’ensemble des systèmes parce qu’il s’agit d’un moyen permettant d’accéder aux commandes. De plus, quel qu’il soit, on l’utilise sans cesse, de ce fait tout laisse présager qu’il faille chercher à faire gagner du temps, chose rendue possible avec les raccourcis mais avec cette dernière solution le temps de mémorisation dudit raccourci fait perdre tout gain de temps. C’est pourquoi il n’y a pas de solution miracle.

Menu principal

Compte tenu du contexte, j’ai opté pour une classique barre de menus de manière à

  • faciliter l’exploration des commandes possibles (il est fort probable que les niveaux du menu se multiplient avec l’implémentation du nombre de fonctionnalités à l’avenir)
  • profiter du texte afin d’expliciter la fonctionnalité
  • rendre visible ces options sur demande de l’utilisateur

Cela permet finalement une réduction drastique du temps d’apprentissage par l’utilisateur en vue d’utiliser d’une commande et ainsi, je l’espère, gagner en efficacité.

L’éditeur

L’idée dans un premier temps est de ne pas permettre la possibilité d’éditer une forme ainsi chaque objet créé est un carré uniforme. En revanche, à terme l’idée est d’implémenter une version simplifiée d’un éditeur avec la possibilité de tracer une forme et choisir la couleur comme suit :

Palette d’outils

En terme d’IHM, cette palette d’outils est un mode d’interaction dit temporel. C’est-à-dire un état de l’interface dans laquelle les actions sont interprétées par rapport au mode sélectionné.

En d’autres termes, la même action au même endroit sera différente en fonction du mode sélectionné. Le problème étant que cela oblige à faire un effort de mémorisation. Etant donné le peu de possibilités avec cet éditeur de formes et la renommée de ces icônes, j’estime cette contrainte de mémorisation acceptable.

Feedback et signes

Un signe est une indication avant l’action du joueur. A contrario un feedback est un retour lié à l’action. Plus le feedback est important, plus l’importance donnée à l’action est importante.

En jeu, cela se traduit par la barre en bas de l’écran dont l’unique utilité est d’afficher un message textuel à titre informatif à l’utilisateur (que ce soit un signe ou un feedback).

Zone dédiée aux feedback

Par ailleurs, on retrouve également des retours d’infos mineurs -sur des boutons, par exemple- lorsque celui-ci est sélectionné.

Metagame

Toutes les mécaniques de jeu non fournies directement au joueur encouragent les discutions autour du jeu, notamment des stratégies en vue de “contourner” le jeu. Le but étant de permettre les interactions entre les joueurs.

Ces mécaniques feront l’objet du prochain article.

La charte graphique

Le style épuré et dessiné permet d’insister sur le côté créatif. En effet, on retrouve ce style dans la phase de conception d’un projet. Symbole que le jeu n’attend qu’à être développé.

Questions en suspens

  • Comment sera géré l’ajout de l’objet, préalablement créé, dans le cadre de jeu ? A priori via j’ajout d’un calque pour cadrier la zone de jeu et ainsi fournir un feedback au joueur, grâce à la couleur de ce quadrillage, quant à la possibilité ou non d’ajouter sa création à une position.

J’estime que cette question est à fixer après un premier prototypage.

  • Quant à la barre tâches, va-t-elle se révéler indispensable ? Si oui, où la placer ? Sinon, quelle autre alternative est envisageable ?

Logiciel utilisé : Pencil Project.

Like what you read? Give aristide a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.