L'approche Chaos Goblin du développement de jeux dans Unity

L'un des sentiments les plus paralysants lorsque vous démarrez un projet de développement de jeu est celui que vous ressentez juste après avoir terminé la conception initiale de votre jeu, qu'il s'agisse de quelques idées notées sur des serviettes pour un game jam ou de la conception traditionnelle de 10 pages. document.

Parce qu'après avoir décidé que votre jeu sera un ROGUELITE-RTS-MMORPG, vous devez en fait construire le truc, vous voyez ?

Et disons que vous avez décidé que la première chose que vous allez construire est la partie RTS. Vous notez donc la user story, les tâches ou toute autre unité de travail que vous utilisez pour vous organiser.

Ensuite, disons que le premier élément de cette liste est "Implement Scrollable Map".

Et oups ! Vous n'avez jamais implémenté une carte déroulante. Mais pas la peine, Google à la rescousse, n'est-ce pas ?

Mais que se passe-t-il si la solution que vous trouvez en ligne ne fait pas exactement ce dont vous avez besoin ? Ou la solution que vous trouvez a 15 ans ? Ou il y a des tas de commentaires en dessous disant à quel point une solution est mauvaise mais sans qu'un seul en spécifie une meilleure[^0] ?

Donc, vous ne pouvez pas trouver de référence de code pour ce que vous essayez de construire. Qu'est-ce qu'un développeur de jeux doit faire ?

La réponse est d'entrer en mode Chaos Goblin.

Entrer en mode Gobelin du Chaos

Pour ceux d'entre vous qui ne connaissent pas les gobelins, il s'agit d'une race souvent représentée dans plusieurs œuvres de fantaisie, généralement représentée comme un cousin plus petit de l'orc ou du hobgobelin plus sérieux. Dans certaines autres propriétés, ils sont décrits comme étant mécaniquement compétents d'une manière très spécifique. Et cette façon n'est pas fiable. Cela signifie que les choses que les gobelins font fonctionnent parfois, pas tant parce qu'elles sont bien conçues ou fabriquées, mais plutôt par pure ingéniosité et intransigeance.

C'est l'essence même de l'approche Chaos Goblin du développement de jeux. Maintenant, je suis sûr que je commence à vous perdre un peu ici, alors laissez-moi revenir et résumer l'essence de Chaos Goblin :

Pour illustrer davantage ce point, laissez-moi vous parler de Presidential Metro Head de Fallout 3 (vous pouvez lire l'histoire complète ici ). L'essentiel est que lors d'une scène du jeu où le joueur pense qu'il se tient dans un métro, le couvre-chef du joueur a en fait été remplacé par le modèle d'une voiture de métro, et c'est le propre modèle du joueur qui se déplace sur un piste prédéterminée.

Certains joueurs pourraient lire ceci et penser que les développeurs étaient paresseux. Mais la vérité est que les développeurs font ce genre de choses tout le temps.

Et c'est précisément ce genre de pratiques qui forment les principes du mode Chaos Goblin, qui sont les suivants.

Ce que le joueur ne sait pas ne peut pas lui faire de mal

Disons que dans une partie de votre jeu, le joueur se tient à l'intérieur d'une tour de château et tire des flèches sur un dragon qui vole à l'extérieur. De temps en temps, le dragon s'approche et passe sa tête par la fenêtre pour essayer de mordre le joueur.

Maintenant, en ce qui concerne le joueur, le dragon vole réellement là-bas. Mais nous, en tant que développeurs de jeux, aurions peut-être utilisé quelques astuces pour aider à cette illusion et optimiser la situation.

Certaines choses qui pourraient être faites sont les suivantes :

• Utilisez différents modèles en fonction de la distance entre le dragon et le joueur. Le joueur ne peut voir les détails du dragon que lorsqu'il est proche, alors pourquoi ne pas remplacer le modèle 3D du dragon par quelque chose qui a moins de détails, mais qui occupera également moins d'espace en mémoire ?

  
  

• Éteignez le dragon lorsque le joueur ne le regarde pas. En gardant une trace de l'endroit où le joueur regarde, nous pouvons activer et désactiver de manière sélective les modèles 3D pour économiser sur le rendu.

  
  

• Empêcher le joueur de voir le travail inachevé. Disons que pour une raison quelconque, l'art de l'environnement à l'extérieur de la tour est inachevé. Ainsi, si jamais le joueur sort sur le rebord de la fenêtre, il ne verra rien. Pour aider à cela, les concepteurs du jeu ont décidé que le rebord de la fenêtre deviendrait un point de mort instantané. Ainsi, lorsque le joueur se tient sur le rebord, un son de 3 secondes de rugissement de dragon retentira et l'écran du joueur commencera à s'assombrir. Une fois le son de 3 secondes terminé, nous jouons une animation rapide du dragon mangeant le joueur (peut-être en réutilisant celui que nous avions déjà). En ce qui concerne le joueur, le rebord n'est qu'un endroit où le dragon peut les enlever ; ils n'ont pas besoin de savoir que cela a été fait pour les empêcher de voir le travail inachevé.

  
  

• Peut-être que lorsque le dragon passe sa tête par la fenêtre, nous remplaçons le modèle de dragon complet par un modèle de tête plus petit mais plus détaillé. Cela nous permettrait de libérer de la mémoire d'un modèle que nous n'utilisons pas tout en offrant au joueur une expérience améliorée.

  
  

Si vous êtes dans l'industrie du jeu depuis un certain temps, vous reconnaissez probablement ce qui précède comme des pratiques standard, mais il fut un temps où ces techniques étaient considérées comme des ruses intelligentes et assez innovantes.

C'est maintenant à vous de trouver de nouvelles façons de tromper vos joueurs en leur faisant croire qu'il y a bien plus que ce qu'ils voient.

La meilleure solution est celle qui fonctionne actuellement

De nombreux développeurs de jeux sont bloqués parce qu'ils essaient de trouver des solutions qui couvrent tous les scénarios futurs possibles. Cette attitude peut être précieuse dans les bonnes circonstances, mais lorsque vous êtes en mode Chaos Goblin, l'objectif est de faire fonctionner quelque chose le plus rapidement possible.

Un complément à ceci :

Un prototype défectueux a plus de valeur que n'importe quel chef-d'œuvre inachevé

Semblable au point ci-dessus, de nombreux développeurs sont bloqués lorsqu'ils essaient d'implémenter une fonctionnalité car ils essaient d'optimiser trop tôt.

L'optimisation doit être laissée jusqu'à ce que le projet ait besoin de s'exécuter sur des machines hors du contrôle des développeurs[^1].

Que dois-je savoir avant de faire X ? La réponse est, quelle que soit la quantité de connaissances que vous avez en ce moment est suffisante

C'est une autre pierre d'achoppement que de nombreux développeurs de jeux débutants rencontrent. Ils retarderont la mise en œuvre d'une fonctionnalité afin de pouvoir suivre un cours de plus, un didacticiel en ligne de plus, regarder une vidéo de plus, puis ils seront prêts à mettre en œuvre leur jeu.

Je suis particulièrement coupable de cela et je sais à quel point cela peut être insidieux.

Pour vous donner un exemple plus concret, disons que vous avez été chargé de programmer un jeu Pong à partir de zéro.

Selon ce que vous savez ou ne savez pas, il peut y avoir différentes approches à adopter pour cela :

• Si vous êtes familier avec le système physique d'Unity, c'est une entreprise relativement simple. Vous pouvez simplement utiliser quelques corps rigides et des collisionneurs, appliquer des forces et des vitesses, utiliser un matériau physique pour le rebond de la balle et c'est tout. Un clone barebone de Pong.

  
  

• Mais disons que vous n'êtes pas familier avec le système de collision d'Unity, vous savez seulement comment utiliser les composants de transformation d'Unity, donc tout ce que vous pouvez obtenir est la position et la taille d'un objet.

  • Mais! C'est suffisant pour implémenter Pong, vous pouvez écrire un script qui garde une trace de la position et de la taille de la balle et la compare avec la position et la taille de la raquette pour vérifier s'il y a une collision.

    
    

• Ou peut-être que vous ne connaissez même pas Unity, tout ce que vous savez, c'est C++ et comment imprimer sur la console.

  • Mais c'est aussi suffisant ! Vous pouvez utiliser la ruse du terminal pour imprimer des lignes et des colonnes de symboles pour représenter la balle, les pagaies et l'aire de jeu. Cela, avec le concept d'une boucle de jeu, est suffisant pour programmer une interface utilisateur rafraîchissante qui répond aux entrées.

    
    

• Ou vous ne venez même pas d'une formation en informatique ou n'avez pas suivi de cours de C++ et ne connaissez que Javascript ?

  • Aucun problème! Vous pouvez utiliser Phaser qui utilise JS comme langage principal et est livré avec des composants de rendu et de physique.

    
    

• Vous ne savez même pas programmer ? Absolument aucun problème.

  • Gamemaker est un moteur de jeu commercial avec une version gratuite, et il a une option sans code.
  • GDevelop est un moteur de jeu open source gratuit avec une option sans code également.

Vous avez compris où je veux en venir, n'est-ce pas ?

Il n'y a pas de projets ratés, juste des piles de ferraille attendant d'être réutilisées

La plupart des développeurs de jeux ont généralement un ou deux (ou 10 000) projets abandonnés qui traînent quelque part. Inutile de les gaspiller. S'il y a du code là-dedans comme un système de pause, réutilisez-le. Inutile de réécrire la même chose. Même si vous vous rappelez exactement comment l'écrire, copiez-le ; s'il est difficile de s'adapter, réitérez-le pour que ce soit plus facile la prochaine fois.

Peut-être avez-vous même un projet d'atelier[^2] qui contient plusieurs morceaux de code que vous pouvez réutiliser.

Vous voyez quelque chose de brillant ? Prends un truc brillant

Besoin d'un système de dialogue ? Trouvez-en un open-source et réutilisez-le. Répond-il à toutes vos exigences ? Non? Est-ce qu'il atteint plus de 50 % ? Oui? Ensuite, cela vaut la peine de l'utiliser au lieu d'en créer un nouveau à partir de zéro.

Systeme d'inventaire? Trouvez un jeu open-source sur itch.io et adoptez leur système.

Besoin d'une caméra à la première personne ? Utilisez un élément prédéfini pour le gérer[^3].

Il existe de nombreux développeurs de jeux brillants, sans aucun doute plus compétents que vous ou moi.

Sauf si vous avez une raison particulière, tout doit être considéré comme un candidat à l'utilisation d'un système préconstruit. Cependant, des exceptions raisonnables existent, telles que : n'utilisez pas de code que vous avez simplement copié-collé comme colonne vertébrale de votre jeu (assurez-vous au moins de le comprendre, de le nettoyer et de le commenter), et évitez d'utiliser un module vieux de dix ans, avec son auteur vraisemblablement allongé dans un endroit tropical, sirotant des Mai Tais avec Elvis, Tupac et Marilyn Monroe dans un paradis sans paparazzi.

En cas de doute, copiez

Si vous n'êtes pas sûr de l'implémentation d'une fonctionnalité, trouvez un jeu qui a fait quelque chose de similaire à ce que vous voulez et imitez-le.

Par "copie", j'entends les aspects de conception tels que la gestion des commandes, les vues de la caméra et la mécanique, plutôt que le style artistique, l'histoire ou les personnages.

Par exemple, à quelle vitesse le défilement devrait-il être dans notre hypothétique ROGUELIKE-RTS-MMORPG maintenant oublié ?

Au lieu de deviner, vous pourriez voir comment un autre RTS a réussi. Supposons que vous observiez Age Of Empires II (un RTS historiquement significatif) et que vous découvriez qu'il permet aux utilisateurs de contrôler la vitesse de déplacement de leur curseur. Vous pouvez même placer votre jeu côte à côte avec AoEII et ajuster votre curseur jusqu'à ce qu'il soit équivalent. Vous seriez étonné de voir combien de développeurs s'appuient sur des solutions simples et low-tech comme celle-ci pour atteindre leurs objectifs.

Pensées d'adieu

Alors, que devriez-vous faire après avoir terminé vos bouffonneries de Gobelin du Chaos ? Eh bien, respirez, préparez-vous une tasse de thé et revenez à votre code plus tard.

Après avoir laissé reposer votre code (sous une serviette humide si le temps est trop sec), vous devriez l'embellir un peu et le partager. Oui! Partagez-le, idéalement avec un développeur senior, un collègue, un camarade de classe ou, dans le pire des cas, avec une communauté en ligne[^4].

Pourquoi le partagez-vous ? Parce qu'être un Gobelin du Chaos ne consiste pas à créer quelque chose de durable ou d'optimal ; il s'agit de construire quelque chose qui FONCTIONNE. Il n'a pas besoin de fonctionner parfaitement ou d'être beau, il doit juste FONCTIONNER. Ce type de développement produit des résultats, mais les résultats sont rarement immédiatement prêts pour la production. Ainsi, consulter quelqu'un pour fournir des commentaires est d'une importance cruciale.

Selon l'étape de votre projet, vous n'aurez peut-être pas le temps de mettre en œuvre immédiatement les commentaires de cette personne. Si tel est le cas, vous devriez au moins documenter ces commentaires dans le code[^5].

Et c'est tout! Vous possédez maintenant la technique n°1 utilisée par les développeurs de jeux professionnels du monde entier pour résoudre des problèmes.

Je dirais qu'il est temps pour une deuxième tasse de thé, n'est-ce pas ?

Remarques

[^0] - C'est un phénomène étonnamment commun et il est dénommé "La parabole de Denver", pour plus d'informations, reportez-vous à l' article scientifique suivant .

[^1] - Il s'agit d'une généralisation et, comme la plupart des généralisations, elle peut ne pas être aussi utile qu'une analyse approfondie des exigences de votre projet. Cependant, c'est une bonne règle de base de reporter l'optimisation jusqu'à ce qu'elle soit vraiment nécessaire. De nos jours, l'optimisation des jeux vidéo est considérablement moins intimidante qu'auparavant. Certaines sociétés de moteurs de jeux, comme Unity, peuvent même proposer de vous aider avec des consultations gratuites. Après tout, il est dans leur intérêt que vous lanciez votre jeu avec succès.

[^2] - L'atelier est l'un des katas ou pratiques que j'utilise pour accroître ma compréhension de l'Unité. Vous pouvez en savoir plus à ce sujet et sur d'autres techniques ici .

[^3] - Vous pouvez trouver un très bon package de contrôleur FPS aux côtés d'autres outils utiles dans cet article

[^4] - Cela comporte une mise en garde : environ 95 % des commentaires que vous recevrez en ligne pourraient être inutiles, incomplets, obsolètes ou refléter les convictions profondément personnelles de l'auteur, quelles qu'elles soient. Par conséquent, abordez toujours ces commentaires avec un certain scepticisme. Essayez de rechercher des commentaires utiles, ignorez ou éliminez le reste et faites un véritable effort pour trouver quelqu'un avec qui vous pouvez partager votre code.

[^5] - Différentes équipes respectent des normes différentes concernant l'endroit où elles conservent leur documentation de code, et vous devez vous y conformer. Cependant, en général, je préconiserais que la documentation du code réside à côté du code lui-même. Si ce n'est pas possible, envisagez d'utiliser un sous-module git ou son équivalent dans le système de gestion des versions de code que vous avez choisi. Si la documentation ne peut pas être dans le référentiel principal, elle doit au moins résider dans le sous-module git.