Conférence au Game Camp 2018 par Nicolas Cannasse de Shiro Games.

Son parcours

Co-fondateur à l'origine du studio Motion Twin, il a en 2005 crée la technologie open source Haxe et Haxe Foundation, qu'il utilise depuis sur l'ensemble de ses projets.

Il a quitté Motion Twin afin de créer Shiro Games.

Il a essayé de réunir des profils différents, car il existe différents types de développeurs.

Par exemple, si vous donnez une boîte avec pleins de boutons à un développeur :

• l'artiste va commencer par appuyer sur un bouton et regarder ce qu'il se passe. Il va ensuite essayer de comprendre ce que fait la boîte dans le but ultime de s'en servir et pourquoi pas de la dépasser.
• l'ingénieur va aussi expérimenter mais il va directement essayé de comprendre le fonctionnement, puis il va la démonter dans le but ultime de l'améliorer.

Dans une équipe vous avez besoin à la fois d'artistes et d'ingénieurs.

L'importance des outils dans un studio

Elle est vitale car :

• Il y a peut-être de bonnes idées de jeu mais si à la fin on n'arrive pas à exécuter nos idées correctement, l'idée ne vaudra rien. Les outils vont aider à l'exécution des idées.
  Exemple : pour monter un meuble Ikea, si vous avez besoin d'un tournevis et que vous n'en avez pas vous ne pourrez pas continuer.
  
• Quand on développe ses propres outils, en cas de bug on maitrîse notre outil et on peut ainsi facilement corriger. On peut ajouter toutes les features que l'on souhaite.

Si actuellement vous n'avez personne pour faire des outils dans votre équipe il faudrait quelqu'un. Cela permettra à l'équipe de fonctionner de manière optimale.

Les erreurs à éviter

Quand on fait son outil il faut faire attention à ces différents points :

• On avance sur les outils au lieu d'avancer sur le jeu, et on termine par devoir faire un outil pour l'outil.
  
• On fait un outil tellement instable et rempli de bugs qu'il devient inutilisable. Quand on s'engage dans un outil il y a une certaine quantité de travail à faire pour qu'il soit utilisable.
  
• Le syndrome de l'"horrible user interface" : à force d'ajouter des features sans réflexion global on finit par avoir des trucs dans tous les sens.

L'outil doit servir le jeu et non pas l'inverse.
Il va servir d'échange entre votre gamecode/script/engine et les parties bas niveau.

Différents types d'outils

Votre outil produit des données et votre jeu les consomme.

Il faut que vos données soient orientées collaboration car vos outils doivent permettre d'éviter les aller-retour. Donc plus votre outil sera ouvert aux autres métiers (GD/LD/Dev/Art) plus votre outil sera utile.

Vos données doivent être lisibles pour voir ce que fait l'outil et pour à la fin obtenir une histoire de données. Vous pourrez ainsi merge vos données dans Git et garder un historique / backup de vos données.

Le format de données est donc très important, à Shiro Games ils utilisent le JSON.

• Les outils de runtime

Avec ces outils, il faut faire attention aux performances et ne pas hésiter à faire du cache.

Ce type d'outil n'est pas lié à un jeu, il est développé pour être utilisé quelque soit le projet.
Il devient agréable car plus on l'utilise plus on le maitrise mais il faut faire attention aux outils trop génériques.

Il vaut donc mieux partir d'abord sur un outil spécifique et ensuite, lors d'un nouveau projet, voir les différences. Si il a 25% de différences, alors il vaut mieux dupliquer l'outil et faire un spécifique au nouveau projet. Sinon vous pouvez enrechir l'outil initial.

À Shiro Games ils ont mis en place un outil open source de Static Database (Castel DB) qui permet à tout le monde de lire / d'écrire des données mais le jeu ne pourra y accéder qu'en lecture.

Les langages

Au niveau des langages il y a pour chaque partie son bon niveau de code.

Engine : C++
Outils : C#
Gamecode : C#
Contenu : Lua

A Shiro Games ils utilisent du coup leur techno, le Haxe, car c'est un langage qu'ils peuvent compiler vers des levels plus ou moins haut.

Engine : Haxe C/C++
Outils : Haxe JS
Gamecode : Haxe
Contenu : HScript

Le time to play

Le time to play c'est le temps à partir duquel je peux voir mes changements en jeu.

Pour le réduire il faut :

• Optimiser les temps de chargement
• Avoir un live reload pour les données
• Une option CTRL+S pour enregistrer l'état actuel du jeu
• Un cheatcode pour passer les menus
• Avoir une compilation rapide

Ce n'est pas spécialement le temps gagné qui est important mais c'est l'attention / le focus du développeur car quand on doit attendre qu'une tâche se termine, on va faire autre chose en attendant et on va perdre notre attention.

L'Open source

L'industrie est de plus en plus tourné vers l'Open Source mais le secteur du Jeux vidéo est encore très en retard. Pourtant l'Open source permet la modification du code, la collaboration et la compétition entre les différentes équipes.

Les conseils de la fin

• Toujours se poser les bonnes questions
• Aller voir les jeux / outils des autres pour savoir si c'est une bonne idée, les erreurs qu'il faut éviter, etc...
• Discuter de nos outils avec le plus de personnes de notre équipe
• Ne pas hésiter lorsqu'on a pris la décision de créer un outil d'aller au bout de notre idée.