Godmorgon: Spooky Ride – Devlog 3

Bonjour à tous, et bienvenue dans ce nouveau devlog ! Normalement, nous en postons un toutes les deux semaines, mais exceptionnellement, celui de la semaine dernière a été reporté à aujourd’hui. Et oui, en plus des contraintes de production « habituelles », nous devons aussi nous adapter à notre emploi du temps de cours. Mais ne vous en faites pas, nous avançons bien sur Godmorgon: Spooky Ride, et notamment grâce à vous ! Tous les participants aux playtests nous ont été d’une grande aide pour la suite de l’aventure, donc merci à tous ! Dans ce quatrième devlog, nous allons donc revenir sur ces tests : à quoi servent-ils, comment les organiser, et surtout : qu’en avons-nous tiré ?

Comme nous vous le disions dans notre article de recrutement pour les playtests, il s’agit d’un moyens courant de tester le jeu directement auprès de futurs joueurs. Cela permet de savoir si les mécaniques fonctionnent bien, de tester des problématiques que l’équipe veut valider ou identifier, de remonter des bugs, mais aussi de savoir si le jeu plaît aux joueurs. Ainsi, cela aide les game designers pour le design, peut guider les artistes sur certains détails, mais cela peut aussi aider à orienter le marketing en général.

Il existe sûrement plusieurs façons de gérer des playtests, selon la taille et les spécialisation d’une équipe, la plateforme utilisée, le genre de jeu soumis au test, etc… L’organisation que nous avons définie a bien fonctionné, donc nous voulions vous expliquer comment nous avions fait ! A noter que ces playtests ont été organisés par les game designers et la live producer.

Avant de commencer à préparer tous les documents et de lancer la machine, il est important de savoir ce que l’on souhaite analyser, les informations que l’on souhaite en ressortir. Dans notre cas, nous voulions principalement tester le potentiel « fun » du jeu, vérifier la compréhension des mécaniques de jeu, et la variété des cartes que l’on propose aux joueurs.

En parallèle de ça, nous avons beaucoup testé la dernière version du jeu qui a été présentée aux joueurs (fixer des bugs, repérer ceux que l’on n’aura pas le temps de résoudre, améliorer quelques effets visuels, etc…).

Ensuite, on peut commencer l’organisation et les documents ! Tous ces documents existent en anglais et en français, pour pouvoir accueillir le plus de joueurs possibles ! Voici la petite checklist que nous avions établie :

  • Le serveur Discord : mettre en place un discord communautaire, avec des canaux privés pour les tests. Vous pouvez très bien faire ceci en conversations privées, mais nous préférions tout faire au même endroit pour faciliter l’organisation.
  • Le formulaire d’inscription : un formulaire contenant toutes les informations nécessaires pour comprendre le profil d’un joueur avant un test (âge, habitudes de jeu, connaissances de jeux similaires, disponibilités, …)
  • Le protocole de test : un document qui décrit tout le déroulé du test. Il est très important que tous les superviseurs aient le même discours pour que tous les tests puissent être analysés correctement. On y précise également quand le superviseur peut parler pendant le test et ce qu’il a le droit de donner comme indication dans des situations particulières, car cela peut aussi avoir un grand impact sur les analyses.
  • Le document d’accueil des joueurs : un document que l’on donne à chaque joueur avant son test, pour lui donner toutes les indications à suivre : où se connecter, où télécharger le jeu, le but du test, … Comme nous avions prévu les sessions mi-octobre, nous avons créé deux versions de ce document : une pour les tests sur place, et une autre pour ceux à distance, afin d’être préparés à chaque situation.

Enfin, la dernière étape de préparation est l’invitation des joueurs. Nous avons donc rédigé un article d’invitation, que nous avons ensuite partagé sur les réseaux du jeu, mais aussi sur nos réseaux personnels, et sur ceux de notre école. Le but était de toucher le plus de joueurs potentiels !

Le gros point positif de ces sessions de test est que tous les joueurs ont eu l’air de s’amuser et ont trouvé que le jeu avait du potentiel. Ayant rencontré quelques soucis dans la production (dont nous parlerons dans un devlog post-mortem fin décembre ou début janvier), ça a fait très plaisir à l’équipe.

Pour ce qui est des observations in-game, les game designers ont pu remarquer que le jeu fonctionne bien, donc nous n’avons pas rencontré de crise en design. Les joueurs ne sont pas autant bloqués que ce que nous pouvions penser, mais le temps de partie est un peu long, ce qui signifie que le level design est sûrement trop grand. Et enfin, les comportements des joueurs sont très différents selon leurs habitudes de jeu. Par exemple, les joueurs habitués aux jeux deck-building étaient déroutés car ils voulaient mettre leur carte n’importe où sur l’écran puis cliquer pour faire l’action. Alors que les joueurs moins friands de ce genre de jeux ont apprécié pouvoir déposer la carte à l’endroit de l’action, et ont d’ailleurs tout de suite compris la mécanique.

Concept UI : sélection de carte

Il a également été relevé que les joueurs n’étaient pas très enthousiastes à l’idée de se balader à l’aveugle, dans un labyrinthe rempli de brouillard. Ils préfèrent aller droit au but, à savoir : trouver la sortie. Ceci est notamment dû au fait que le principe d’exploration, bien que pilier du design, n’est pas assez récompensé lors des parties.

Pour finir, la plupart des joueurs ne faisaient pas attention à la mécanique de timeline (4 prochaines actions performées par le Ringmaster, grand ennemi du jeu), qui est pourtant le petit plus de Godmorgon: Spooky Ride, qui lui donne un côté original.

Toutes ces observations sont, pour la plupart, des choses dont l’équipe avait plus ou moins l’intuition, et souhaitait vérifier (notamment pour la compréhension de la timeline). Grâce aux tests, nous avons pu valider que les cartes fonctionnent bien, que ce soit les actions qu’elles permettent à elles seules, ou leur synergie avec les autres cartes, et surtout : nous avons pu confirmer que le deck (ou ensemble de cartes données au départ) est polyvalent et fonctionne bien pour avancer dans le jeu.

Concept d’UI pour la sélection de carte

Les stratégies optimales mises en place par les joueurs sont également celles qui avaient été pensées par les game designers lors de la production (utiliser une carte lorsque son trust correspond au trust en cours, éviter les ennemis, …).

Enfin, comme prévu, les game designers vont devoir continuer à améliorer l’expérience utilisateur (dont nous parlions dans le dernier devlog !). Bien qu’elles étaient déjà prévues mais pas encore implémentées, les info-bulles donnant les informations sur les cartes et d’autres éléments d’interface sont vraiment primordiales à la bonne compréhension du jeu.

Certaines observations nous ont ainsi amenés à appliquer des changements au jeu, dont trois majeurs.

En termes de design, le jeu demande deux choses au joueur : explorer et anticiper. Cependant, le brouillard de guerre empêche de prévoir, et donc ne donne pas envie au joueur d’explorer. Pour les Game Designers, le plus important était la mécanique d’anticipation. Ils ont donc décidé d’enlever le brouillard de guerre cachant toute la carte, pour que le joueur puisse anticiper chaque situation et ose se balader dans le labyrinthe sans être frustré.

Mais cela enlève une part du challenge du jeu. Ainsi, vu que l’on ne peut plus explorer à l’aveugle (un des piliers principaux du gameplay), il a été décidé de modifier le comportement des ennemis. Cela permet de les rendre plus intéressants et dangereux, et surtout de retrouver cette part de challenge qui n’existait plus sans le brouillard de guerre.

A gauche : avant, avec brouillard de guerre / A droite : après sans le brouillard (Concepts UI)

Enfin, le système de boutique a été annulé. Les joueurs pouvaient y accéder via leur interface, et y acheter des cartes ou encore en enlever de leur paquet en utilisant des pièces d’or gagnées sur leur chemin. Cette fonctionnalité n’était pas entièrement implémentée pour les playtests, donc ne pouvait pas être utilisée. Les Game Designers se sont ainsi rendu compte que les joueurs n’en avaient pas eu besoin et que ce n’était donc pas nécessaire au fonctionnement du jeu. Cette mécanique a donc été supprimée, ce qui a permis à l’équipe de se concentrer sur la refonte des ennemis. Dorénavant, comme les joueurs pourront prévoir leurs déplacements et anticiper, ils pourront se diriger vers des salles spéciales dans le labyrinthe, où ils pourront supprimer des cartes de leur main.

Les playtests se sont tous très bien passés, et l’équipe remercie énormément les joueurs pour leur temps, mais aussi leur bienveillance. Comme vous avez pu le voir, ces tests nous ont permis de souligner des points importants du jeu, et de faire des changements majeurs pour améliorer l’expérience. Quelques bugs ont eu lieu pendant les sessions, mais on peut noter que trois joueurs ont assez approché la sortie pour considérer le niveau comme fini !

Il nous reste beaucoup de travail pour vous proposer un jeu jouable dans quelques semaines, mais nous sommes confiants, et nous avons hâte que vous puissiez tous le prendre en main ! Le jeu ne sera d’ailleurs finalement pas sur Steam, suite à un contre-temps avec la plateforme, mais ne vous en faites pas, il sera accessible gratuitement et à tous sur itch.io !

D’ici là, attachez vos ceintures, gardez les bras dans votre wagon, et n’essayez pas de sortir de l’attraction en cours de route… !

Un commentaire sur “Godmorgon: Spooky Ride – Devlog 3

Ajouter un commentaire

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Créez un site ou un blog sur WordPress.com

Retour en haut ↑

<span>%d</span> blogueurs aiment cette page :