Ressource externe à kb.zoroark.guru importée en accord avec la licence de la ressource.

Projet Informatique : Guide de survie

Voici un petit condensé des problèmes rencontrés lors de notre projet, la résolution de ces problèmes, des conseils et les choses à éviter. Ce rapport n’est pas un document officiel, mais un retour d’expérience. Lire ceci permettra d’éviter au moins 75% des erreurs classiques, libre à vous de les suivre ou non…

Conseils à la réalisation de votre projet de jeu vidéo

Réaliser un jeu vidéo est difficile, pour vous faire gagner du temps voici une compilation de conseils mis en forme de liste afin d’être plus lisible.

Pré-conception du jeu

• Une idée trop ambitieuse est une mauvaise idée. Vous ne chamboulerez pas le monde du jeu vidéo.

• Un projet multijoueur en ligne peut s’avérer très complexe à mettre en place.

• Se mettre en équipe avec une personne hors de son cercle d’ami peut s’avérer plus productif.

• La première impression est importante, mais évitez de réaliser une coquille vide. La qualité de la modélisation 3D, des sprites 2D ou des cartes est tout aussi importante que le code. Essayez d’obtenir un bon équilibre entre le code et la qualité graphique.

Gestion d’équipe

• Toujours aider une personne en difficulté. Bien sûr, celle-ci ne doit pas se reposer entièrement sur quelqu’un pour faire son travail à sa place.
• Vous avez le droit de ne pas savoir comment réaliser une chose en particulier. Faites une rapide évaluation de chacun des membres de l’équipe afin d’exploiter les talents de chacun. Il est rare qu’une équipe soit parfaitement homogène.

• Discord, IRC ou Slack ne permettent pas toujours de communiquer efficacement. Privilégiez un endroit calme où toute l’équipe peut s’installer et échanger, surtout lors des périodes de soutenances.

• Réaliser un planning, même incomplet / imprécis.

Contrôle de version et gestion du code source

• Utilisez un système de contrôle de versions tel que Git/Mercurial/SVN. L’échange de clés USB est à proscrire, c’est une perte de temps. De plus, si vos ordinateurs sont volés ou endommagés et que ne vous possédez pas une sauvegarde, vous avez tout perdu.

• Ne travaillez pas sur la branche principale. Il est courant et “plus aisé” de développer sur la branche principale. Or, dès que quelqu’un fait un commit et push, tout le monde perd ses changements lors d’une mise à jour. Il est recommandé de faire une branche par personne.

• Faites des push réguliers.

• Fusionnez régulièrement les différentes branches de l’équipe. Si vous travaillez par branche, vous devez fusionner au minimum chaque semaine et vérifiez que tout fonctionne. Pensez aussi à mettre à jour ou à recréer des branches pour tous les membres de toute l’équipe.

Multijoueur

• Si votre projet possède un mode multijoueur, celui-ci doit être implémenté en priorité. La plus grosse erreur lors de la réalisation d’un jeu possédant un mode multijoueur est de l’implémenter au milieu du développement de votre jeu. Ainsi, il y a de fortes chances que votre projet soit scindé en deux: Une partie à un seul joueur et une autre intégrant les fonctionnalités multijoueur. Cette dernière aura toujours du retard sur la version à un seul joueur. Sans compter la fragmentation du code.

• Le mode à un seul joueur doit être un serveur local privé à un joueur. Utiliser des Sockets directement est du suicide. Des bibliothèques telle que Photon peuvent vous aider. Celle-ci dispose de nombreux tutoriels et d’une documentation correcte.
• N’utilisez pas UNet. UNet est en cours d’abandon, il est possible que des fonctionnalitées ne fonctionne plus du jour au lendemain. (https://blogs.unity3d.com/2018/08/02/evolving-multiplayer-games-beyond-unet/)

Unity

• Évitez d’intégrer des assets venant de l’Asset Store juste pour prendre un seul asset. Ceci alourdit considérablement la compilation, la taille du projet et le temps de synchronisation si vous utilisez la collaboration d’Unity.

• Réaliser des assets pour votre jeu peut prendre du temps. Vous pouvez prendre les assets libre de droits sur des sites internets tel que OpenGameArt ou FreeSound.

• Si vous avez des messages d’erreur sur l’outil de Collaboration d’Unity sans rien modifier, vérifiez si les serveurs sont hors-ligne et évitez de faire des push. Des doublons de commits peuvent apparaître.

• Utilisez la dernière version stable de Unity lors de la création de votre projet.

• Ne changez pas de version en cours de route, Unity ne supporte pas l’importation d’ancien projet. Il sera nécessaire de refaire beaucoup de prefabs à la main. De plus, il est possible que Unity ne prenne plus en charge certaines fonctionnalités sur lesquelles vous vous reposez.

• Utilisez des tutoriels utilisant une version très proche de la vôtre. Par exemple, si vous utilisez la version 2017.3, utiliser un tutoriel utilisant Unity 2017.2 peut être un bon choix. Il est recommandé d’éviter l’utilisation des des tutoriels utilisant une version supérieure à celle que vous utilisez, sauf si la fonctionnalité détaillée dans le tutoriel existe et fonctionne de la même façon que la version d’Unity que vous utilisez.

• Évitez les abus de tutoriels. Lire la documentation officielle d’Unity peut parfois bien plus vous aider.

• Compilez régulièrement une version hors éditeur (“Stand-alone”). Ce qui peut marcher sur l’éditeur d’Unity ne fonctionnera peut-être pas sur une version compilée à part et vice versa.

• Sauvegardez votre projet compilé et ne faites pas confiance à l’éditeur de Unity. Il est recommandé de toujours posséder une version compilée et fonctionnelle de votre projet même si celle-ci est ancienne. Si par malheur, vous n’avez plus de temps pour implémenter une fonctionnalité et que votre jeu ne fonctionne plus du tout, vous devez posséder une version jouable de votre jeu. Si vous utilisez les services de Unity proposant le Cloud Build, vous n’avez pas de soucis à vous faire, mais vérifiez régulièrement si la compilation se passe sans encombre : Il est possible que votre jeu ne compile plus du tout. Pensez à activer les notifications par mail et à activer “Autobuild”.

• Concentrez vous sur la version Windows. Unity est un moteur de jeu multiplateforme, mais rien de vous empêche d’adapter votre jeu sur d’autres supports. Une version Windows pleinement fonctionnelle vaut plus que des versions Windows, Mac et Linux boîteuses.

• Anticipez le temps de compilation. Au fur et à mesure du développement de votre projet, votre jeu va s’alourdir. La compilation, logiquement, va être de plus en plus longue. Compiler une version de démonstration au dernier moment peut être fatal. Pensez à désactiver les “lightmaps” et à retirer les cartes de jeu que vous n’utilisez pas afin d’accélérer la compilation de dernière minute de votre jeu.

• Forcez vous à garder une structure de dossier cohérente. Il n’y a rien de plus énervant que d’avoir des assets en double ou des scripts dans des dossiers de modèles 3D. On s’y perd rapidement.

• Si votre jeu comporte beaucoup d’éléments graphiques ou de scripts, l’exportation WebGL peut casser. Vous pouvez tomber sur une erreur de manque de mémoire après quelques minutes de jeu.

Code

• Évitez de trop dépendre du code des autres. Essayez de séparer votre code du code des autres. Si une fonctionnalité repose beaucoup sur le travail d’un autre et que celui-ci s’effondre, vous aurez deux fois plus de boulot. Bien sûr, il y a des cas où utiliser le code des autres est indispensable.

• Des fonctions sont plus coûteuses que d’autres. Debug.Log, StartCoroutine sont des fonction dites coûteuses, celles-ci peuvent ralentir parfois considérablement votre jeu sur de petites configuration. Utilisez un débogueur au maximum à la place de Debug.Log. De plus, si vous compilez votre jeu avec les Debug.Log cette fonction va écrire dans un fichier de Log, mobilisant inutilement le disque dur. StartCoroutine permet d’exécuter en différé une fonction. Cette fonction peut s’avérer suffisante pour ouvrir, par exemple, une porte quelques dizaine de secondes plus tard. Mais elle reste inadaptée pour des choses se répétant plusieurs fois par seconde. Une bonne alternative peut être Delta.DeltaTime : (https://docs.unity3d.com/ScriptReference/Time-deltaTime.html, https://unity3d.com/fr/learn/tutorials/topics/scripting/delta-time, https://pressstart.vip/tutorials/2018/07/20/45/building-a-timer.html).

• Une classe comportant plus de 1000 lignes de script ou une fonction comptant plus d’une centaine de lignes nécessite probablement un re-découpage.

• N’hésitez pas à utiliser l’héritage. Une arme, un pistolet par exemple, peut être le fils d’une classe abstraite appelée “Arme”.

• Il ne sert à rien d’optimiser prématurément votre code. Du “code qui marche” est également dangereux c’est à dire du code qui est illisible mais fonctionnant correctement.

• Mélanger du F# et C# est une mauvaise idée. Le C# est le seul langage “officiel” d’Unity.

• Commentez votre code.

Rapport de soutenance

• Ne sous estimez pas la durée de rédaction du rapport de soutenance. Pensez à commencer à rédiger le squelette du rapport au moins deux semaines à l’avance.

• Une bibliographie ou des sources sont recommandées.

• LaTeX est à la fois votre ami et votre pire ennemi. LaTeX met en forme automatiquement votre document. Il est recommandé de ne pas essayer de “forcer” une mise en forme particulière sauf si celui-ci génére mal une partie de votre document (un tableau par exemple).

• Un dépôt Git, Mercurial ou SVN peut être très utile pour les rapports. En effet, ces outils peuvent être très puissants sur des fichiers textes. Dans la majorité des cas, il sera aisé de fusionner des branches. Une fusion manuelle est normalement simple. De plus, GitLab ou GitHub proposent des outils de fusions complets, sans mettre directement la main à la pâte à l’aide de Vim ou Emacs. Mais si Git vous effraie, vous pouvez utiliser un éditeur de document LaTeX en ligne tel que Overleaf.

• Utiliser un convertisseur OpenDocument/Word/Google Doc vers LaTeX n’est pas une bonne idée. En revanche, vous pouvez rédiger votre document sur un logiciel de traitement de texte classique pour bénéficier d’un correcteur orthographique puis intégrer vos parties du rapport dans un document LaTeX.

• Il est plus facile de créer, éditer et compiler des documents LaTeX sur un système Unix (GNU/Linux, BSD ou macOS) que sous Windows.

La présentation

• Une combinaison de touches permettant de tricher est recommandée. Si votre jeu est trop difficile, pensez à ajouter des codes de triche permettant de passer un niveau ou de gagner des vies.

• Découpez logiquement votre démonstration. Si vous choisissez une démo-présentation pour la soutenance finale, c’est à dire que votre jeu est la présentation, décrivez les éléments du jeu dans l’ordre tel que vous le voyez. Présentez ce que le jury voit, introduisez au fur et à mesure les fonctionnalités de votre jeu. Un exemple : vous montrez que vous avez une caméra pouvant être déplacée avec la souris, ensuite que le joueur peut se déplacer et enfin courir. De plus il est important de scénariser votre démonstration afin d’éviter les blancs ou les oublis. Prenez plusieurs ordinateurs avec vous, chacun disposant d’une copie du jeu et des diapositives.

• Beaucoup de projecteurs et de salles sont toujours câblés en VGA. Pensez à amener un adaptateur HDMI / DisplayPort vers VGA, ce connecteur commence à s’effacer des ordinateurs portables.

• Testez votre présentation sur un projecteur. Votre présentation est peut être magnifique, mais n’est pas forcément lisible sur un projecteur. N’hésitez pas à vous déplacer au fond de la salle afin de vérifier la bonne lisibilité de votre présentation.

Le site internet

Le site internet n’est pas un élément à négliger pour votre projet. Celui-ci peut être statique ou dynamique. Un site statique n’est pas modifiable sans toucher le code source. En revanche, un site dynamique permet d’être modifié sans intervention sur le code source. Pour réaliser votre site internet, vous pouvez utiliser un outil tel que Hugo, Hexo, Gatsby ou Jekyll permettant de réaliser un site statique. Créer un outil sur mesure à partir de zéro n’est pas obligatoire et peut prendre du temps. Le principal avantage de ces générateurs de sites internet statiques est de pouvoir rédiger le contenu de votre site dans un langage de balisage plus pratique que l’HTML tel que le Markdown (https://fr.wikipedia.org/wiki/Markdown) et donc de ne pas nécessiter de grosses connaissances en HTML/CSS. Un cours interactif d’introduction est accessible ici: (https://www.markdowntutorial.com/). Attention, le Markdown est une spécification ouverte. Chaque développeur est libre de l’implémenter comme il le souhaite. En voici un court rappel:

Il est possible de combiner plusieurs tags Markdown en fonction des implémentations : **__Texte en gras et en italique__**.

Vous pouvez louer un serveur web pour héberger votre site internet. Vous pouvez vous tourner sur des alternatives gratuites tel que Dyjix ou AlwaysData.

Si vous êtes bricoleur, vous pouvez vous même héberger votre site sur un ordinateur. Faites juste attention à la bande passante, la sécurité de votre serveur et à sa consommation d’électricité. Un Raspberry Pi ou équivalent peut largement suffire. L’achat d’un nom de domaine pour votre équipe n’est pas nécessaire. Il existe des noms de domaines gratuits profitant d’extensions un peu exotiques tels que ceux proposés par Freenom.

Remarques :

• Pensez à faire des sauvegardes régulières de votre site. Un accident de votre côté ou de votre hébergeur peut tout à fait arriver.

• Prendre un serveur dédié pour votre site internet est inutile. Sauf si vous souhaitez réutiliser ce serveur plus tard.

Petit guide pratique sur Git

Personne n’est parfaitement à l’aise sous Git. Voici un rappel des commandes les plus utilisées.

Pour plus d’informations, veuillez consulter le manuel de Git.

GitHub et GitLab

Pour votre projet, vous allez probablement utiliser Git. Git permet de travailler de pair-à-pair, mais par sécurité, il est recommandé de choisir une solution d’hébergement Git pour le code source de votre projet. Les deux plus grandes plateformes sont GitHub et GitLab. Chacune de ces plateformes a ses avantages mais aussi ses inconvénients. La plus populaire, GitHub, héberge plus de 69 millions de projets.

Si l’on en reste strictement à la version gratuite de ces deux services (largement suffisante pour un projet scolaire en groupe), la différence majeure entre GitHub et GitLab est que ce dernier permet d’en faire un peu plus. Depuis peu la création de repos privées sur GitHub est devenue gratuite et illimitée mais uniquement pour les utilisateurs seuls (et jusqu’à trois collaborateurs) mais sur GitLab, non seulement la création de repos publiques et privées est illimitée mais elle est aussi ouverte aux organisations (groupe d’utilisateurs avec nombre de collaborateurs illimité) ce qui est plus pratique pour un travail en groupe. L’autre avantage majeur de GitLab est l’intégration en continue (ou CI pour Continuous Integration), même si celle-ci n’est pas vraiment utile avec Unity, elle peut l’être pour un site web ou pour vos différents rapports rédigés en LaTeX. La CI intégrée à GitLab permet d’éxecuter et déployer votre application automatiquement à chaque mise à jour de votre code, ce qui peut s’avérer très utile pour déployer un site web statique sans avoir à l’héberger de manière classique. À noter que GitHub peut également héberger des sites web statiques (avec GitHub Pages) et faire de la CI (via des services tiers).

En résumé, le choix entre GitHub et GitLab est avant tout une question de préférence, tout ce qui peut être fait sur l’un des deux services peut aussi être fait sur l’autre et inversement. La formule gratuite de GitLab en propose un peu plus que celle de GitHub, mais cela ne vous empêchera pas de collaborer convenablement si vous préférez utiliser ce dernier.

Problèmes courants

Git et GitLFS

Problème: Problème de pointeur de fichiers. Des fichiers disparaissent ou sont vides.

Solution 1: Supprimer et ajouter manuellement les fichiers à nouveau. Attention : Ceci ne corrige pas nécessairement le problème.

Solution 2: Refaire un repo et vérifier que tous les membres de l’équipe ont l’extension GitLFS correctement installée.

Unity Collaborate

Problème : Tout le monde peut publier ses changements. Mais il arrive que Unity perde le projet en cours de route.

Solution : Vérifier sur le Dashboard Unity si l’outil Collaborate est bel et bien activé.

Problème : Unity perd le projet en route, mais Collaborate est bel et bien activé. Solution : Désactiver et réactiver Collaborate.

Problème: Unity semble avoir perdu la collaboration. Solution: Cliquer sur ‘Start now’ sur l’onglet Collab, Unity va réessayer de vérifier les changements.

Licence

Ce travail est soumis à la licence “Licence publique Creative Commons Attribution - Utilisation non commerciale 4.0 International”.

Rédigé par Benoît “SheatNoisette” et Luca “iralorucrie” Corrieri.