Solarlune: Ce que j'aurais aimé qu'on me dise avant de sortir mon premier jeu vidéo

par | 4 Juin 2020

Solarlune, c’est un développeur qui m’a pas mal inspiré pour mon premier livre sur Blender. En février 2020, il a publié son premier jeu « commercial » sous Steam: Bloody Rally Show. Le jeu a été réalisé sous Unity, sur son temps libre. Estimant avoir fait de nombreuses erreurs, il a sorti une vidéo dans laquelle il s’est exprimé à ce sujet. Voici une petite traduction rapide de ce qu’il nous confie, c’est-à-dire, la liste de tout ce qu’il aurait aimé que quelqu’un lui dise avant de commencer à travailler sur son premier jeu. De bons conseils pour créer un jeu vidéo.

Solarlune : Introduction

“Hé gamedevs!  Au cours des deux dernières années, j’ai réalisé un projet de jeu sur mon temps livre que j’ai sorti sur Steam il y a quelques mois. J’ai fait beaucoup d’erreurs tout au long du processus de développement et je tenais une liste de notes pour mon «moi passé». Cette liste peut ne pas s’appliquer à votre jeu en particulier, ni à votre moteur / langage (j’utilisais Unity / C #), mais je crois que quelqu’un pourrait trouver une ou deux choses ici qui l’aidera, alors je vais partager.

Les 60 conseils pour créer un jeu vidéo

Ce que j’aimerais que quelqu’un me dise quand j’ai commencé à travailler sur mon jeu:

  1. Faire un jeu complexe et raffiné qui mérite d’être publié et qui a même une faible chance de succès sera 100 fois plus difficile que vous ne l’auriez jamais imaginé. Je ne saurais trop insister sur ce point.
  2. Utilisez l’échelle d’unité correcte dès le début, surtout si vous avez de la physique dans le jeu. Dans Unity, 1 unité = 1 mètre. Ne pas définir l’échelle correcte rendra votre physique bizarre.
  3. Les sprites doivent être créés et importés avec une taille / DPI / PPU cohérente
  4. Assurez-vous que les sprites sont soit POT (Power of 2: 32×32,64×64,128×128,etc.), ou emballez-les dans des atlas
  5. Activez la compression crunch sur tous les sprites que vous pouvez (POT + crunch peut facilement transformer 1,3 Mo en 20 Ko)
  6. Créez votre interface utilisateur à partir de composants réutilisables
  7. Nommez vos composants d’interface utilisateur réutilisables de manière cohérente afin qu’ils soient faciles à trouver
  8. Avoir un document de guide de style dès le début
  9. Utilisez des espaces de noms en C # et divisez votre code en assemblys dès le début. Cela impose une architecture plus distinctement séparée et réduit les temps de compilation à long terme.
  10. N’utilisez jamais de magic strings ni même de string constants. Si vous utilisez des chaînes identifier un objet, arrêtez. Utilisez des enums.
  11. Préférez des sessions plus longues que multiplier les sessions. 2 heures sont bien plus productives que 4 sessions distinctes de 30 minutes
  12. Le Design ne doit pas faire partie d’un prototype. N’essayez pas de le rendre joli, vous devrez le jeter de toute façon.
  13. Ne perdez pas de temps à créer de « l’art façon développeurs ». Si vous savez que cela ressemblera toujours à de la merde, peu importe vos efforts, concentrez-vous plutôt sur ce que vous savez faire de mieux. Vous achèterez plus tard des assets ou trouverez quelqu’un qui se joindra à l’équipe et le fera pour vous (et mieux).
  14. Évitez les public static en C#.
  15. Essayez de faire moins de POO, surtout si vous n’êtes pas trop bon dans ce domaine. Gardez les choses isolées. Avoir moins d’état. Échangez des données, pas des objets avec des états et des hiérarchies. Greg: Je ne suis pas d’accord, mais en même temps, je fais de la POO depuis longtemps. J’utilise pour ma part massivement la POO (sous UE4, c’est un peu normal) et ce qui est commun à plusieurs classes, j’utilise des composants.
  16. Évitez les grandes classes et les méthodes à tout prix. Séparez par responsabilités et faites-le tôt. 300 lignes, c’est probablement trop pour une classe, 30 lignes, c’est trop pour une seule méthode. Split split split.
  17. Organisez les illustrations de la même manière que vous organisez le code. Il doit être clairement et logiquement séparé, espacé et avoir une convention de dénomination.
  18. Ne vous contentez pas de copier et de modifier légèrement le code de vos autres jeux, construisez-vous une bibliothèque partagée de choses atomiques qui peuvent ensuite être utilisées dans vos autres jeux.
  19. Si vous utilisez des ScriptableObjects, ils peuvent être facilement sérialisés en JSON. Ceci est utile pour activer le modding.
  20. Pensez à permettre le modding le plus tôt. Présentez l’architecture noyau du jeu initial de manière à pouvoir créer vous-même votre jeu principal en tant que mod ou ensemble de mods. Le contenu du jeu doit être une architecture «douce», il doit être facilement modifiable et enfichable.
  21. Si vous prévoyez d’avoir un multijoueur en ligne, commencez à construire le jeu avec lui dès le premier jour. En fonction du type de jeu et de votre code, le multijoueur au sommet d’un projet presque terminé sera très difficile à presque impossible.
  22. Ne proposez pas de premières versions inachevées de votre jeu aux streamers et aux créateurs de contenu. Ces vidéos de votre jeu manquant de contenu, merdique vous hanteront très longtemps. Greg: Je ne suis pas certain. Oui, il ne faut pas partager si c’est mauvais, mais il faut aussi communiquer le plus tôt possible, donc à vous de juger.
  23. Développez une communauté sur Discord et Reddit.
  24. Créez des versions pour tous les systèmes d’exploitation (Win, Linux, Mac) et téléchargez-les sur Steam en une seule opération. Vous pouvez créer pour Linux et Mac à partir de Windows avec Unity.
  25. Arrêtez de tester votre jeu après chaque changement, ou de livrer des builds avec des bugs à votre communauté. Écrire des tests d’intégration (selon l’outil) pour automatiser les tests. Les tests peuvent jouer à votre jeu à une vitesse 100x et détecter les plantages et les erreurs pendant que vous vous concentrez sur des choses plus importantes.
  26. Nommez vos GameObjects de la même manière que vous nommez vos classes MonoBehaviour. Ou au moins faire une convention de dénomination cohérente, il sera donc trivial de trouver un objet de jeu par le nom de la classe de comportement. Oui, vous pouvez également utiliser la recherche, mais une hiérarchie d’objet de jeu bien nommée est bien meilleure. Vous pouvez également renommer les objets de jeu lors de l’exécution à partir de scripts, et vous devriez, si vous instanciez des préfabriqués.
  27. Créez-vous un système d’interface utilisateur solide à l’avance, puis utilisez-le pour construire le jeu entier. Il est difficile de créer une interface utilisateur solide et flexible.
  28. Ne câblez jamais vos boutons d’interface utilisateur via Unity Editor, utilisez plutôt onClick.AddListener à partir du code.
  29. Essayez d’avoir autant que possible de « defined » dans le code, plutôt que de compter sur Unity Editor ou les prefab serialization. Les fichiers unitaires YAML vous feront passer un mauvais moment. Utilisez l’éditeur pour trouver rapidement un bon ensemble de valeurs lors de l’exécution, puis mettez-le dans le code et supprimez [SerializeField].
  30. N’utilisez pas de variables publiques, si vous devez exposer une variable privée à Unity Editor, utilisez [SerializeField]
  31. Soyez super cohérent dans la dénomination et l’organisation du code.
  32. Ne prenez pas de raccourcis, ou ne faites pas de compromis sur les parties les plus importantes et les plus difficiles de votre jeu – mécanique de base, génération procédurale, inputs des joueurs (s’ils sont complexes), etc. Vous le regretterez plus tard. En prenant des raccourcis, en bâclant le code, copier-coller quelques trucs plusieurs fois, écrire une longue méthode avec beaucoup d’instructions if, etc. Tout cela vous coutera fort quand vous devrez refactoriser. Et si vous ne le faites pas,il sera difficile de changer quoi que ce soit par la suite.
  33. Réfléchissez bien avant de définir un nom définitif pour votre jeu. Prenez le temps de la réfléxion, une semaine ou deux. Le renommer plus tard peut facilement devenir un véritable cauchemar.
  34. Nommez très tôt votre projet avec un prototype de nom de code générique. Ne commencez pas par le nommer, acheter des domaines, configurer des comptes, acheter une application Steam, etc. Tout cela peut être fait bien plus tard. Greg: Bon, ok, mais je le répète, il faut communiquer le plus tôt possible, alors c’est délicat.
  35. Lorsque vous effectuez une génération procédurale, visualisez chaque étape du processus de génération pour le comprendre et le vérifier. Si vous faites des hypothèses sur le déroulement de l’une des étapes, les bogues et les erreurs dans ces étapes de génération vont tout gâcher, et ce sera un cauchemar de déboguer sans visualisation.
  36. Définissez les polices TextMeshPro par défaut et de secours dès le début.
  37. N’utilisez pas iTween. Utilisez LeanTween ou une autre solution performante.
  38. Évitez la physique Unity 2D même pour les jeux 2D. Construisez-le en 3D, vous obtiendrez un Nvidia Physx multi-thread au lieu de Box2D beaucoup moins performant. Greg: Sous Unreal, la question ne se pose même pas, puisque le moteur de physique 2D a été retiré de mémoire…
  39. Utilisez Debug.Break () pour attraper des erreurs bizarres et les analyser. Fonctionne très bien en combinaison avec des tests. Il existe également « Error Pause » dans la console qui le fait en cas d’erreur.
  40. Faites des builds aussi vite que possible. Investissez du temps pour comprendre où vos builds prennent le plus de temps… et vous vous épargnerez beaucoup de temps à long terme. Par exemple, vous n’avez pas besoin de compiler des variantes de shader 32K à chaque build. Utilisez des shaders préchargés pour obtenir une accélération significative (Edit > Project Settings > Graphics > Shader Loading).
  41. Transformez tous vos éléments d’interface utilisateur en prefabs. Il a quelques bizarreries, comme l’ordre des éléments avec LayoutGroup, mais il existe des solutions de contournement.
  42. Évitez LayoutGroup et tout ce qui déclenche la reconstruction de Canvas, en particulier dans la méthode Update, surtout si vous prévoyez de porter votre jeu sur des consoles.
  43. Nested Prefab, c’est top !
  44. Commencez à créer votre jeu avec la dernière version bêta d’Unity. Au moment où vous aurez terminé, cette version bêta sera stable et obsolète. Greg: Mouais… Vous pourriez aussi tomber sur des soucis qui n’auront pas de réponse avant longtems… Il y a parfois des régressions bloquantes. Et sous UE4, je vous déconseille fortement à cause des plugins qui ne seront pas compatibles.
  45. Essayez toujours d’utiliser la dernière unité stable à la fin de votre projet.
  46. Les assets du magasin doivent être appelés passifs. Moins vous utilisez, moins vous aurez de problèmes. Greg: C’est peut-être vrai pour Unity, mais j’estime que ce n’est pas le cas sous UE4. On gagne beaucoup de temps à utiliser des assets existants. Lui parle probablement surtout de « code » – et là, ça dépend forcément de votre profil. Parfois, prendre en main un code fait par quelqu’un d’autre, c’est plus long que de l’écrire soi-même… Mais heureusement, ce n’est pas toujours le cas.
  47. Faites un usage intensif de Unity Crash Reporting. Vous n’avez pas besoin de demander aux gens de vous envoyer des journaux en cas de problème. Demandez simplement leur modèle de carte OS / Graphics et trouvez les rapports de plantage avec les journaux dans le tableau de bord en ligne.
  48. Augmentez la version de votre application à chaque fois que vous effectuez une génération. Cela devrait être fait automatiquement. Très utile lorsqu’il est combiné avec Unity Crash Reporting, car vous saurez si vos nouvelles versions obtiennent d’anciens problèmes que vous pensez avoir corrigés, etc. Et lorsque quelque chose provient d’une ancienne version, vous saurez que ce ne sont pas vos utilisateurs payants, mais un pirate avec une ancienne copie du jeu. Si vous ne renseignez jamais votre version, ce sera un cauchemar à suivre.
  49. Une interface utilisateur dynamique sophistiquée n’en vaut pas la peine. Rendez l’interface utilisateur simple et simple à construire. Elle doit être conviviale pour le joueur. N’utilisez jamais de dispositions diagonales à moins que vous ne vouliez souffrir le martyr.
  50. Si vous construisez un jeu où l’IA utilisera un contrôleur PID (joystick virtuel), commencez par faire vos inputs, et seulement après, travaillez sur l’IA, ou vous devrez la réécrire à chaque fois que votre physique / manipulation du jeu changent.
  51. Utilisez un éditeur de code qui affiche des références sur les classes, les variables et les méthodes. Visual Studio Code est génial, il fait cela, et cette fonctionnalité particulière est cruciale pour naviguer dans votre code de jeu lorsqu’il grandit. Greg: Intellisense quoi.
  52. Beaucoup d’exemples de code qui peuvent être trouvés en ligne sont absolument horribles. Ils peuvent être réécrits pour être beaucoup plus courts et / ou plus performants. Un exemple notable – Steamworks.NET
  53. Les exceptions non interceptées dans les coroutines Unity entraînent des plantages impossibles à déboguer. Tout ce qui fonctionne dans une coroutine doit être absolument à l’épreuve des balles. Si une référence peut être nulle, vérifiez-la, etc. Et vous ne pouvez pas utiliser try / catch autour de tout ce qui a un rendement, alors réfléchissez bien. Divisez les coroutines en sous-méthodes, gérez-y les exceptions.
  54. Construisez-vous un système de gestion coroutine. Vous devriez pouvoir savoir quelles coroutines sont en cours d’exécution, pendant combien de temps, etc.
  55. Créez un mode photo dans votre jeu dès le début. Vous pourrez alors faire des gifs, de belles captures d’écran et des trailers avec facilité. Greg: Sous UE4, les screenshots sont supportées via la console, mais on peut aussi utiliser Ansel pour faire des screenshots en très haute résolution ou à 360°.
  56. Construisez-vous très tôt une console développeur. Essayer les choses rapidement sans avoir à créer une interface utilisateur jetable est fantastique. Et plus tard, vos joueurs peuvent utiliser la console pour modding / cheats / etc. Greg: Le mode console est inhérent à Unreal, il suffit d’avoir par exemple un event dans un level blueprint pour qu’il soit possible de l’appeler directement via la console, en préfixant par « ce  » (custom event) pour la recherche.
  57. Ne comptez pas sur PlayerPrefs. Sérialisez votre configuration de jeu avec tous les éléments réglables dans un format de texte brut.
  58. Ne testez jamais plus d’un changement à la fois.
  59. Ne vous levez pas à 4h du matin pour trouver le temps de faire votre jeu. Ne craquez pas. Prenez quelques jours de congé. Exercice. Mangez bien (maximisez l’apport en protéines, évitez les glucides + les graisses, c’est le pire). Ne vous tuez pas pour faire un jeu. Ayez une vie en dehors de votre passion. Greg: Ahah… c’est vrai, mais c’est pas évident à suivre 😉
  60. À moins que vous ne soyez déjà une célébrité avec plus de 10 000 abonnés, le spam sur votre jeu sur Twitter sera une cause perdue. La balise #gamedev se déplace à quelques messages par seconde, et très probablement personne ne se souciera de votre jeu ou de ce que vous avez fait récemment. Concentrez-vous plutôt sur la construction d’un meilleur jeu. Greg: Et de super gifs animés de Gameplay comme vu ici.

Voilà, c’est une liste non-exhaustive et assez personnelle de conseils pour créer un jeu vidéo. En fait, il y a tellemment de choses à savoir, et à plein de niveaux, que j’ai l’impression qu’on ne fait qu’égratinier la surface. Mais si ça peut servir déjà à d’autres, j’avais envie de le partager avec vous.

Pour finir, je vous laisse avec le trailer de son jeu qui a l’air sympathique:

Découvrez nos derniers numéros !

2 Commentaires

  1. Benoit

    Liste très intéressante, bien que je ne sois pas trop d’accord avec certains points comme toi et que d’autres points ne sont pas vraiment justifiés. 😉

    Réponse
    • greg

      Salut Benoit. Oui, en effet, c’est assez subjectif et tout est ouvert à la discussion. C’est son ressenti, ça donne des pistes 🙂

      Réponse

Laisser un commentaire

Ces articles pourraient aussi vous intéresser …