Revenir au blog

[Postmortem] Burning Ship

Concept et prototype réalisé pour le projet de fin de 2ème année (Juin 2016) de formation au Game Design à Aries.

Résumé

Burning Ship est un jeu de combat en équipe en arène dans un univers de pirate. Inspiré des mécaniques des MOBA, il oppose 3 joueurs contre 3 joueurs, chacun dirigeant un navire de guerre disposant de compétences propre.

Le prototype présente les mécaniques de jeu principal du concept. Il s’agit une version à deux joueurs (un contre un) en écran splitté qui ne reflète pas le rendu final du concept, mais qui a permis de tester les mécaniques en situation réelle.

J’ai rejoins ce projet composé de six personnes (trois game designers et trois game artists) lors des sélections de projet de seconde fin d’année. Les intentions du jeu étaient posées, mais nous avons établis en groupe l’ensemble du game design. Le groupe avait un délai de d’environ quatre mois.


pi__ce

 

Description du concept

Les mécaniques de jeu sont semblables à un MOBA-like. Les parties opposent deux équipes dont les héros, chacun contrôlé par un joueur, sont représentés par des navires.

BurningShip - presentation2
Boucle de jeu globale

BurningShip - presentation3Avant de débuter une partie, le joueur a plusieurs choix à faire :

  • Modèle de navire : chacun disposant de statistiques différentes (Mana, santé, manoeuvrabilité, etc…).
  • Équipement du navire : représente les compétences
  • Capitaine : procure un passif au joueur

Puis il sélectionne le mode de jeu :

  • Destruction de port : partie de MOBA classique, deux équipes s’affrontent pour détruire le camp adverse.
  • Capture de drapeau
  • Deathmatch

 

BurningShip - presentation7Le déroulement d’une partie suit les standards d’une partie de MOBA, à quelques exceptions près :

  • Il n’y a pas de système de sbire comme on peut le voir couramment, mais des tours et des ports disposés sur la carte. Ceux-ci, neutre au début de la partie, pourront être capturés par les équipes pour prendre du terrain. Ils peuvent également être améliorés, procurant divers avantages (téléportation, marchands, etc…).
  • L’expérience gagnée durant la partie est regroupée sous une seule ressource qui est l’or. Cet or peut être dépensé dans les statistiques du navire, ses compétences, le passif du capitaine du joueur ou encore dans les différents tours ou port disposés sur la carte.

A la fin de la partie, le joueur accumule une ressource qui peut être dépensée dans l’achat de nouveaux navires, capitaines ou compétences.

Procurer une expérience de versus intéressante

Nous nous sommes posés beaucoup de questions quant aux rendu de l’expérience de jeu. Nous avions la chance de développer un concept au genre très codifié, avec beaucoup de références connus, mais chaque changements apportés amenaient des conséquences que nous essayions de prévoir.

Notre challenge était de mélanger un type de gameplay aux informations connues et précises (comprendre : calculs de dégâts pouvant être effectué de tête) et disposant de peu d’aléatoire avec la problématiques des mouvements de navires et tout le hasard qui peut être impliqué. Afin de répondre à notre intention qui est de créer un jeu de versus, nous avons écartés tous réalisme nautique pouvant nuire à une expérience de jeu dynamique : pas de gestion de courants marins, de vent, de voiles, etc… Nous avons en revanche privilégié une expérience plus proche d’un gameplay dynamique  comme des compétences loufoques (submersion, dash…) ou une vitesse accrue.

 

BurningShip - prototype2Un choix intéressant est en rupture avec la convention des MOBA : la gestion de l’attaque de base. Dans la plupart des MOBA classiques, l’attaque automatique a une quantité de dégâts connue et ne peut que réussir ou échouer, alors que les navires de Burning Ship tirent des boulets qui infligent chacun leurs dégâts à la cible touchée.

Un autre challenge fût d’adapter les commandes essentielles à un jeu multijoueur à des inputs manette. Nous souhaitons atteindre un gameplay fun à prendre en main, tout en restant précis et procurant un challenge à maîtriser.

Autant que possible, nous essayons de nous appuyer sur nos observations des MOBA du marché pour imaginer une expérience satisfaisante. La possession des tours par une équipe est par exemple une réponse directe à l’absence de sbire, qui pourrait permettre de rendre une expérience similaire de conquête du territoire jusqu’à la base ennemi. Le choix des compétences est également évalué en fonction de leur combinaisons possible et des effets envisagés sur le gameplay.

Conception du prototype

Dès que j’ai rejoins le projet, j’ai pris en charge la conception du prototype, avec Unity pour moteur de jeu imposé. Les recherches effectuées lors de la réalisation de Graybox m’ont permises d’évaluer sereinement la charge de travail.

Répondre aux contraintes techniques

Il a fallu prendre une orientation dès la phase de recherche : je connaissais mes compétences techniques et ne voulait pas risquer l’apprentissage de la conception du jeu en lui-même, mais aussi de la surcouche réseau nécessaire pour le multijoueur.

Après quelques hésitations de notre part, notre chef de formation nous a imposé une version à deux joueurs, en écran splitté. Cela nous a notamment permis de playtester notre jeu en situation presque-réelle mais a surtout apporté des éléments de réponses cruciaux à des problèmes que nous avions. Une fois cette orientation prise, nous avons pu aborder sereinement l’implémentation des features.

Architecture

BurningShip - architecture baseBurningShip - PlayerManagerJ’ai tenté de définir dès le début une architecture globale, que j’ai pu étoffer au fur et à mesure que le projet avançait. Je me suis imposé des standards inspirés de ce que j’ai pu trouvé sur le net et tenté de bâtir une architecture modulable, autant pour des questions d’équilibrage que de sécurité.

Ainsi, j’ai écris plusieurs Managers, dans le but d’y rassembler les données qui nécessitent d’être partagée. J’ai également créé plusieurs héritage de classes lorsque cela me semblait approprié.

Ces méthodes m’ont permises d’optimiser de nombreux aspects du développement :

  • Réutiliser les méthodes identiques pour différentes entités
  • Rassembler les données importantes au même endroit, ce qui a plusieurs avantages :
    • Simplifier les dépendances entre scripts
    • Favoriser un système modulaire.
    • Simplifier la maintenance du code (effectuer un unique changement pour affecter tous les éléments concernés)
    • Permettre, au sein du même script, de sortir en public les variables intéressantes pour l’équilibrage
  • Simplifier la relecture du code et la recherche de bugs par l’uniformisation des techniques utilisées
  • Permet de travailler sur plusieurs features à la fois sans que celles-ci n’interviennent entres elles.

Itération du concept

Le début de mon travail a été partagé par la recherche d’une part et les tests effectuées avec de simples cubes comme placeholders. Quand j’eus réuni un début de features éparses, mon rythme de travail s’est stabilisé jusqu’à la fin du projet. J’avançais l’implémentation de plusieurs features, puis je choisissais celle qui me semblait le plus urgente à développer et j’entrais dans une phase de rush jusqu’à la terminer.

Quand le jeu a commencé à prendre forme, des décisions de design ont se sont imposées. Nous réévaluions le comportement de la feature et modifions en conséquence jusqu’à obtenir le satisfaction.

A la fin d’une période de rush, je reprenais les features mises de côtés, et je recommençais le processus.

Le rythme s’est bien évidemment accéléré vers la fin du projet.

Intégrations

BurningShip - mapNous avons fait en sorte de tester tôt le bon fonctionnement de chaque élément à l’intégration. Ainsi, certains problèmes bloquant rencontrés comme des problèmes d’import d’animations ont pu être résolus tôt dans la production. Chacun des assets tardifs nous ont d’ailleurs posés problème, ce qui m’encourage à prévoir un temps de test pour chacune des étapes inconnues.

J’ai travaillé conjointement avec le directeur artistique sur les demandes spécifiques des assets, tel que l’organisation les éléments du navire. Nous avons fais en sorte de suivre des normes, tel qu’imposer une limite de nombre de polygone pour une question d’intégration ou l’utilisation de normalmap. Nous avons essayons ensemble différentes méthodes, tâchant de nous adapter au travail de chacun.

Le level conçu par un autre game designer a été intégré quand les assets ont pu être disponible, remplaçant les placeholders.

Équilibrage

BurningShip - balance triple canonsLe split screen mis en place, il a permis d’organiser des playtests afin d’évaluer les préférences de chacun, manettes en main.

J’ai ainsi pu écrire de nombreuses méthodes de déplacement, de gestion de la camera, de tirs… et le groupe débattait ensemble après avoir réuni des avis externes.

Ces phases ont donné lieu à plusieurs problématiques d’équilibrage :

  • Les leviers devaient être significatifs afin de ne se perdre dans une liste exhaustive de valeurs (et ainsi éviter l’écriture d’une documentation)
  • Les valeurs possibles doivent être restreintes pour prévenir les bugs de configuration.

Parmi les bénéfices de l’architecture, les leviers des tours et des bases disposent de profils pouvant être customisées. Les données sont centralisés en un seul script et distribués aux tours lors du chargement de la partie. Cette méthode a grandement facilités les tests lors de l’équilibrage.

Nous avons également décidé de réduire fortement les distances entre les éléments du level pour dynamiser la rencontre entre les deux joueurs.

Polish

Nous avons intégré une bonne partie du polish du navire en cours de production afin de pouvoir tester les signs et feedbacks qui en ressortaient. Nous nous sommes essentiellement concentrés sur la lisibilité du gameplay plutôt que sur la performance graphique :

  • De nombreuses particules réagissant aux actions du joueur (écumes en déplacement, en saut, en submersion…, fumée / feu en réaction aux tirs, différents types d’impacts, etc…)
  • Des sprites, aussi bien en GUI (capitaine, compétences, cooldown…) que dans le monde (portées, visée, etc…).

Vers la fin du projet, nous avons pu avoir quelques jours pour parfaire le polish du prototype. Nous avons du optimiser le traitement des lights et des ombres et réduire le nombre de polygones du décor afin d’avoir une expérience fluide à tout endroit du level, puis nous avons effectué les dernières retouches (tonemapping, ajustement du fog…).

Gestion de projet

BurningShip - slack screenshotTout au long de la réalisation du concept, nous avons utilisés divers outils de communication, comme Trello, Slack ou Skype.

J’ai maintenu un planning de production du prototype sur excel, permettant d’avoir une vision d’ensemble de l’avancée. Parallèlement, je remplissais des fiches de suivi pour tenir au courant le chef de projet de mon avancée, mais il a été difficile de mettre à jours tous les documents au fur et à mesure. Nous avons décidé d’abandonner les fiches de suivi pour des prises de contact directes et régulière.

trello - prog recherche

Nous avons rencontré tout un tas de problèmes typiques de production :

  • Les outils de communication se sont avérés difficiles à coordonner pour l’ensemble de l’équipe
    • Trello a été largement sous-utilisé au profit de la communication directe entre les membres de l’équipe. Cela a permis des avancées fulgurantes lors des rushs, mais à causé de nombreuses problèmes ensuite. La séparation des tâches a été mal comprise par une partie du groupe, et son utilisation a été abandonnée vers la fin du projet. J’ai néanmoins pu m’en servir comme bloc note pour toutes les recherches effectuées.
    • Slack a été adopté tardivement par l’ensemble du groupe, mais a pu accueillir nos communications dans des canaux dédiés. Pour pallier au manque d’utilisation de Trello, les mises à jours de tâches furent envoyée sur Slack.
    • Skype a été utilisé pour les communications vocales durant l’ensemble du projet.
  • En conséquence, certaines informations ont été bloquées, avec quelques ennuis :
    • L’oubli de demander un asset de la base à détruire, nous avons pallié dans l’urgence en adaptant un bout de modélisation qui avait été retiré auparavant.
    • Les quelques intégrations tardives qui ont été effectuées se sont avérées problématique pour la cohésion de la direction artistique (style graphique, modélisation, texture…), mais a également eu des impacts sur le gameplay (tour installée sur un promontoire empêchant le joueur de tirer sur celle-ci, etc…).
  • La nomenclature libre a ralenti la production, mais la forte communication entre les membres de l’équipe a pu permettre une organisation efficace. Des améliorations peuvent être faites pour la prochaine année.

Si nous avons pu constater les limites de la communication directe, elle a néanmoins permis de maintenir une certaine cohésion. Ayant la chance d’habiter en colocation avec le DA du concept, cela a grandement facilité nos échanges. Si au début, cela a pu causer des problèmes d’informations pour tout les membres de l’équipe, nous avons pris ensuite l’habitude de rapporter chaque échange en ligne afin que chaque membre du groupe puisse réagir.

Communication des ressources

Je déplore l’absence de l’utilisation d’un système de version type SVN ou Git, qui rendrait les backup moins fastidieux et faciliterait grandement la communication des ressources. J’oriente mes recherches dans le but de pouvoir en utiliser un la prochaine année.

Pour Burning Ship, j’ai maintenu un standard concernant mon travail, mais l’unification avec le groupe s’est faite petit à petit, entraînant des confusions et des retards qui auraient pu être évités. Les transferts furent fastidieux, effectués par disque dur ou un système de stockage hébergé (dropbox ou drive).

 

death_match

Rendu final

Une partie oppose deux joueurs avec pour but de détruire le camp adverse. Si la vie du joueur descends à zéro, il doit atteindre la fin d’un court décompte pour rejoindre la partie. Les tours (disposant d’une allégeance à un camp dès le début de la partie) peuvent être détruites, puis reconstruites par leur camp.

Les compétences implémentées sont :

  • Triple canons : trois bordées de deux boulets sont tirées successivement, le dernier doublant les dégâts infligés.
  • Éperon : Le navire adverse est propulsé à l’utilisation. Cette compétence inflige des dégâts au tick lorsque l’éperon est collé à l’adversaire.
  • Dash avant / arrière : Existe en deux versions, propulse le navire du joueur dans une direction.
  • Jump : Au premier appui sur la touche de compétence, le navire est propulsé dans les airs. Le joueur disposent d’un court instant pour choisir son lieu d’atterrissage dans un rayon autour de son navire, suite à quoi celui-ci atterit sur l’endroit choisit.
  • Mine : Permet de déposer jusqu’à 5 mines simultanément qui explosent au bout de trois secondes.
  • Submersion : Submerge le navire pendant quelques secondes, le rendant insensible au dégâts mais tout autant désarmés.
  • Shield : Procure un bouclier durant quelques secondes, protégeant le navire des attaques.
  • Bigboy : Compétence puissante, aux effets variés. Le bigboy implementée à été surnommé la “Batteuse”, s’agissant d’une zone à poser sur la mer déclenchant pendant quelques secondes une volée de boulets venus du ciel.

Quelques placeholders ont été néanmoins oubliés, comme lors de la défaite du navire du joueur ou les informations de parties dans le menu principal.