Nous travaillons avec Unity depuis longtemps et ne pouvions pas empêcher d'inviter leurs gars à Pixonic DevGAMM Talks, qui était en septembre. L'ingénieur de terrain Valentin Simonov a expliqué comment planifier l'architecture des jeux en tenant compte des avantages des nouvelles technologies. Unity y travaille depuis plusieurs années pour atteindre un niveau de performance jusque-là inaccessible. Vous pouvez écouter la présentation sur YouTube et lire la transcription avec des diapositives juste sous la coupe.
Et si je dis que vous pouvez augmenter la productivité de votre jeu de 10 fois? En fait, ce n'est pas entièrement vrai, mais il y a du vrai dans chaque blague. Je veux parler de ce sur quoi nous travaillons actuellement, de l'avenir de Unity et de ce que vous pouvez utiliser maintenant.
Unity crée des jeux complètement différents. Voici quelques exemples que je joue moi-même. Ils utilisent des fonctionnalités différentes et ont besoin de performances différentes, d'une approche différente du développement.
Et nous travaillons sur un projet que nous appelons Performance par défaut. Ce sont quelques fonctionnalités spéciales qui, si elles sont utilisées correctement, augmenteront considérablement les performances. Dans certaines tâches, nous avons mesuré x10 et même x11. Surtout dans les problèmes de simulation d'un grand nombre d'objets qui interagissent entre eux.
Mais lorsque nous parlons de la performance par défaut, nous voulons dire que vous devrez changer l'approche du développement, changer considérablement l'approche de l'architecture des jeux. Et, en fait, tout le monde n'en a pas besoin.
Une question populaire: «Que faites-vous dans votre ECS? Vous supprimez tous les GameObject, supprimez tous les Transform, hiérarchie et composants? " Non, nous la quittons tous. Vous pouvez travailler avec Unity exactement de la même manière qu'aujourd'hui, mais si vous voulez plus de performances, vous devez connaître les technologies dont je veux parler brièvement.
Et je veux mentionner une autre technologie appelée Scriptable Render Pipelines (SRP) - elle vous permet d'écrire plus efficacement un pipeline de rendu pour votre jeu. Vous avez probablement vu la démo que nous avons montrée sur l'un d'Unite. Ici sur PC en temps réel, un nombre géant d'unités est simulé, quelque chose autour de 60 000 (il atteint 100 000 et commence à ralentir un peu):
Et les nouvelles fonctionnalités dont je veux parler sont: Entity Component System (ECS), C # Job System, notre nouveau supercompilateur Burst et Scriptable Render Pipelines (SRP).
Je le répète: c'est à vous de choisir si vous voulez aller de l'avant avec nous, apprendre de nouvelles technologies, ou vous êtes d'accord pour développer des jeux qui rapportent bien et qui sont tout simplement faits.
Afin de comprendre ce que nous essayons de résoudre, il est important de comprendre l'état du fer en 2018.
Remarquez comment les performances et le nombre de cœurs de processeur augmentent. D'un certain point, les performances sur un seul thread ont même baissé. Autrement dit, nous avons maintenant de nombreux cœurs, mais leur productivité n'augmente pas si rapidement. Par conséquent, nous aimerions utiliser la puissance de tous les cœurs.
Mon téléphone a 8 cœurs: 4 forts et 4 faibles. Et un téléphone moderne peut fonctionner aussi vite qu'un ordinateur moderne (mais pas très longtemps en raison d'une surchauffe). Vous devez également comprendre que l'augmentation des performances n'utilise pas seulement tous les cœurs, mais également l'optimisation des performances monocœur.
Et la dernière image, que nous donnons toujours comme exemple de la façon dont les performances du processus augmentent et la vitesse d'accès à la mémoire n'augmente pas tellement:
On peut voir que maintenant l'accès à la mémoire est extrêmement lent. Les fabricants de processeurs font beaucoup pour niveler cette différence - ajoutez des caches, les processeurs sont engagés dans des calculs spéculatifs, essayant de prédire quel code sera exécuté ensuite. Et si vous n'y pensez pas lorsque vous créez votre jeu (ou lorsque nous créons un moteur pour vous), nous ne pouvons pas profiter pleinement des processeurs modernes.
Vous êtes nombreux à passer des heures à regarder une image similaire dans Unity:
Ici, vous pouvez voir qu'il existe du multithreading, mais les cœurs et threads restants ne sont généralement pas occupés. Quelque chose se fait, mais je voudrais les occuper complètement.
Maintenant, nous avons le rendu, c'est une telle boîte noire. Vous avez le choix: avant ou différé, ainsi que divers paramètres pour les matériaux, les shaders, les tampons de commande, etc. Vous pouvez faire une belle image, mais de nombreux algorithmes sont extrêmement difficiles à mettre en œuvre.
Et nous connaissons tous l'architecture dans Unity: composants, GameObjects, hiérarchie des transformations, tout le code, toutes les données dans MonoBehaviour et chaque composant traite ses données.
Mais il y a des problèmes avec l'état actuel des choses. Tôt ou tard, vous tombez sur cela et comprenez comment vous en avez besoin ou non. La hiérarchie des objets elle-même a une certaine surcharge, et certaines entités ne doivent pas du tout être des GameObjects. Et si vous avez un grand nombre de composants et de mises à jour, tout devient beaucoup plus lent. J'ai déjà écrit
cet article , qui est toujours d'actualité si vous voulez savoir comment ne pas le faire.
Et la chose la plus importante dans le contexte des processeurs est que tous les composants, toutes les données sont dispersés dans la mémoire, ce qui rompt l'utilisation du cache du processeur.
Maintenant, je veux passer rapidement en revue de nouvelles fonctionnalités.
Je ne me concentrerai pas beaucoup sur ce qu'est ECS et sur son fonctionnement. Le fait est que nous avons Entity, qui n'est que l'ID de certaines entités dans le jeu - elles stockent des données sous forme de composants, c'est-à-dire données uniquement, pas de code. Et les systèmes traitent Entity avec certains composants et modifient en quelque sorte ces données.
Pourquoi faisons-nous notre ECS et comment sera-t-il meilleur que ses concurrents? Il y a quelques points. Tout d'abord, pas tout à fait officiellement, mais nous pensons que nous ferions le moteur maintenant. Il est clair que nous ne voulons pas nous débarrasser de GameObjects, les composants actuels d'Unity, tout jeter complètement et installer ECS. Mais nous voulons évoluer vers un meilleur moteur.
Nous comptons sur des performances élevées. Il n'y a pas si longtemps, Mike Acton nous a rejoint (si vous êtes en développement C ++, vous savez qu'il est l'un des évangélistes de la programmation orientée données). Et nous voulons que tout le système fonctionne aussi vite que possible - plus rapidement que C ++.
Nous réfléchissons également à la façon d'intégrer différentes choses de manière native dans ECS. Il y a quelque temps, nous avons annoncé que nous faisions un nouveau réseau et qu'il est également basé sur ECS - il sera possible de faire un jeu multijoueur sur ECS et de partager le code entre le client et le serveur.
Travail sur les outils de débogage dans Unity. C'est-à-dire alors qu'ECS existe, pour ainsi dire, séparément de GameObjects et des composants, ce qui est très gênant. Nous voulons simplifier les choses.
Maintenant, il y a un DebugView qui ressemble à ceci:
Ici, vous pouvez voir quel type d'entité vous avez, quels systèmes combien de temps il faut pour traiter, quels systèmes fonctionnent avec quels composants et pour chaque composant que vous pouvez voir dans l'inspecteur, quelles données chaque entité a dans les composants (je note que l'API change souvent et beaucoup Les didacticiels sont peut-être déjà obsolètes).
De plus, si vous avez entendu parler de notre nouveau développement Unity for Small Things (il s'agit d'un très petit runtime qui vous permet de créer des jeux pour les messageries instantanées) - tout est également basé sur ECS.
Récemment, le boom du développement et de la transition vers ECS est une technologie très populaire et tout le monde doit la connaître.
Nous avons une conférence pour les programmeurs, il est donc difficile de se passer d'une diapositive de code. Il y a beaucoup de code là-dedans, donc il est difficile de sortir une sorte de morceau intelligible pour clarifier quelque chose.
En fait, j'ai pris un système de l'exemple qui fonctionne avec le système de travail C # (plus à ce sujet plus tard), et nous faisons beaucoup pour réduire la quantité de code, ajoutez un shugar de syntaxe.
Il existe un système qui fonctionne avec les composants RotationData et il a également besoin de transformations GameObject, qui sont représentées par un TransformAccessArray spécial. Et chaque mise à jour du système que nous créons Job, exécutons ce Job, il se met à jour quelque part, peut être divisé en plusieurs groupes et exécuté sur différents threads.
Comment utiliser dans le projet? Tout comme dans d'autres implémentations ECS, vous devez comprendre que vous devez penser d'une manière complètement différente (contrairement à GameObjects et Transforms). Et habituez-vous à cette idée. Il est clair que vous devez commencer dès le début du projet, car je reçois très souvent des questions comme «nous avons créé le jeu et nous voulons passer à ECS - comment?». Dans le jeu terminé, c'est très difficile à faire.
Nous devons réfléchir à l'interaction avec Unity, car ECS vit séparément, dans son petit monde. Nous donnons quelques opportunités d'interaction avec GameObjects et Transforms, mais la physique, le rendu, etc., ici ça devient de plus en plus compliqué. Et bien que vous ayez à supporter le fait qu'une grande partie de l'interface familière ne sera pas disponible, mais nous y travaillons également.
Et immédiatement, vous devez penser au fait que vous écrirez des systèmes dans le Job System, qui est beaucoup plus efficace.
Quelques mots sur Job System. Nous voulons créer un moyen très simple d'écrire du code multi-thread. En même temps, écrivez en C #, vérifiez tout pour vous, ne donnez pas la possibilité de faire des erreurs ou de montrer pourquoi, où et comment vous les avez faites. Nous limitons les fonctionnalités de langage que vous pouvez utiliser dans les Jobs et appelons ce sous-ensemble C # High Performance C #. Vous n'avez pas de références dans votre code de travail, pas de lignes, toutes les données doivent être copiées - vous ne pouvez pas utiliser un grand nombre de fonctionnalités linguistiques, ce qui rend beaucoup plus difficile la prise de vue multi-threading dans votre jambe.
Nous présentons également des collections et une intégration très rapides avec ECS. Cette structure ECS et Job System permet une exécution de code très rapide.
Dans le même temps, nous ne vous offrons pas seulement la possibilité d'utiliser ces technologies - nous travaillons avec ces systèmes nous-mêmes et créons de nouvelles API afin qu'elles puissent être utilisées dans les Jobs.
Nous avons fait des Raycasts Async pour la physique, avec lesquels vous pouvez dire "Je veux 600 rakecasts, faites-le moi un jour, s'il vous plaît." Nous nous efforçons de faire en sorte qu'en utilisant ces technologies, il soit possible d'étendre les systèmes actuels, par exemple l'animation via l'API Playbles. Et nous envisageons de créer de nouveaux systèmes dans Unity qui ne seront pas fermés en C ++, et dont le code sera en C # et disponible pour vous.
Si vous prenez le code de Job, c'est assez simple. Job est une structure dans laquelle il existe une méthode Execute, dans laquelle nous effectuons certains travaux en exécutant ce Job. En conséquence, notre planificateur interne comprendra un jour où il vaut mieux l'exécuter, résoudra toutes les dépendances. Ici, nous obtenons un JobHandle, que nous pouvons utiliser comme dépendance pour certains autres Jobs.
Comment utiliser dans le projet? C'est bien si vous utilisez Jobs dès le début, mais ce n'est pas nécessaire ici. Si vous avez une sorte de système critique pour les performances, par exemple des simulations, la recherche de chemin, la mise en réseau ou autre chose - vous pouvez trouver comment l'optimiser en utilisant cet outil.
Mais pour cela, vous devez prendre quelques grandes mesures, comprendre comment stocker correctement les données. ECS, en fait, nous permet de stocker les données correctement, car nous séparons les données du code et notre implémentation d'ECS stocke les données des composants linéairement en mémoire, et, en parcourant ces composants par un système, vous utilisez toutes les capacités du processeur, tout est stocké dans le cache et etc. Nous essayons de le faire très rapidement.
Ensuite, vous divisez ce travail en tâches parallèles, écrivez le code du travail et exécutez-le. Et (probablement) tout fonctionne pour vous. Bien sûr, vous devez tester et, surtout, tester sur la plate-forme cible, en fonction du nombre de cœurs, etc. Mais l'utilisation de Job System et ECS, comme je l'ai dit, affecte également considérablement la façon dont vous planifiez votre architecture de jeu.
Ensuite, tout est beaucoup plus simple. Burst Compiler est notre technologie unique, un compilateur spécial de ce sous-réseau C # (High Performance C #) dans le code machine de la plate-forme actuelle, que vous publierez dans votre projet.
Les gars ont fait de la magie que personne, sauf eux, ne comprend probablement, mais cette chose accélère 10 fois le code du travail, ce qui est super cool. Et le plus cool est qu'il ne nécessite aucune action de votre part - si vous avez un code Job, vous ajoutez simplement l'attribut [BurstCompile], Burst compile votre code et vous obtenez des performances «gratuites». Il s'agit de notre nouvelle technologie et vous pouvez l'essayer maintenant.
Et la dernière chose que je veux mentionner brièvement est le pipeline de rendu scriptable (SRP), sur lequel nous travaillons depuis très longtemps et qui est conçu pour vous donner la possibilité d'écrire un rendu très personnalisé pour votre jeu spécifique.
Render Pipeline est un algorithme qui fait la suppression (quels objets seront dessinés), le rendu et le post-traitement. Maintenant, nous avons une boîte noire, qui vers l'avant ou différée - ils sont déjà bons, nous obtenons des graphismes très cool sur les téléphones mobiles, sur PC, sur les consoles. Mais ils ont beaucoup de restrictions, car ils ne peuvent pas être étendus. En utilisant cette nouvelle fonctionnalité, SRP, vous pouvez écrire votre Pipeline, vous pouvez supprimer quelque chose à partir de là, ajouter, faire tout ce que vous voulez.
Nous travaillons actuellement sur deux exemples de pipelines. Un LWRP, que nous ciblons sur les téléphones mobiles et les appareils faibles, et HDRP, que nous ciblons sur les PC, les consoles et sur lesquels travaillent des personnes très célèbres de l'industrie. Avant cela, ils ont fait des jeux AAA. Vous avez sûrement vu notre démo Book of the Dead.
Ici, nous avons utilisé HDRP pour montrer toute la puissance de cette technologie.
Pour l'utiliser, vous devrez également prendre un assez grand nombre de mesures héroïques, car avec le nouveau Pipeline, presque rien n'est compatible avec ce que nous avons maintenant. C'est-à-dire si vous effectuez une mise à niveau avec Legacy, nous vous proposons un utilitaire qui mettra à niveau la plupart des matériaux pour vous, mais vous devrez réécrire vos shaders, c'est-à-dire les textures seront très probablement différentes.
Très cool si vous pouvez recommencer à zéro et expérimenter avec votre Pipeline. Si vous souhaitez faire quelque chose sur votre Pipeline, veuillez nous contacter.
Encore une fois, comprenez ce dont vous avez besoin, car maintenant vous avez plus d'occasions de faire quelque chose, mais vous aurez besoin de personnes qui peuvent le faire ou vous devrez apprendre à le faire.
À mon avis, c'est cool, car ceux qui nous proposent ces nouvelles technologies seront plus en demande sur le marché. C'est tout, j'espère que quelqu'un ira voir ces technologies, fera de beaux jeux sympas.
Questions du public
- Quand puis-je obtenir ECS et le développer?- Vous pouvez utiliser ECS, le problème est que dans sa forme actuelle, il est plus ciblé sur les personnes axées sur la performance, c'est-à-dire une sorte de projet AAA. Et la tâche d'Unity est de rendre les performances par défaut accessibles à tous. Par conséquent, nous avons besoin d'un certain système, un complément à ECS, qui nous permettrait d'utiliser ECS avec la même facilité que nous utilisons maintenant MonoBehavior. Bien qu'il n'y ait pas un tel module complémentaire, je ne pense pas que ECS sera publié dans une version complète. Et il s'avère que nous avons créé une fonctionnalité que 1% de nos utilisateurs utiliseront. Et ce n'est pas une tâche Unity. Je connais des gens qui utilisent déjà ECS en production, gardez à l'esprit que cette fonctionnalité est encore en développement et que nous résolvons maintenant la question de savoir comment créer l'interface la plus pratique. Et la tâche suivante (non moins difficile) est de savoir comment créer une sorte d'API qui vit au-dessus de cet ECS et vous permet de l'utiliser avec la même facilité que MonoBehaviour. C'est-à-dire il n'y a pas de réponse à la question «quand exactement».
- ECS et le reste des éléments se concentrent sur la prise d'un GameObject de base et la création de 150 000 de ses clones et leur gestion. Mais que faire si j'ai peu d'objets, mais qu'ils ont des entités différentes?- Vous ne pouvez en principe rien faire, cette technologie ne vous oblige pas à l'utiliser. Si vous pouvez obtenir une amélioration des performances en utilisant ces technologies, vous devez les utiliser. Si cela ne vous concerne pas, vous continuez à utiliser Unity tel quel. Par conséquent, ne paniquez pas.
- Nous avons un client sur Unity, un serveur sur .NET, nous avons essayé un serveur sur Unity, rien ne vient. Mais en même temps, je veux aussi utiliser les technologies qui sont dans Unity sur le serveur.
- Nous y travaillons et comprenons que maintenant nous ne pouvons pas fournir une solution de serveur efficace. Nous avons acheté la société Multiplay il y a quelque temps afin de proposer un hébergement de haute qualité pour les jeux Unity. Nous travaillons en réseau séparément et nous nous engageons séparément à optimiser le moteur afin que plus de choses puissent en être éliminées. En conséquence, lorsque tout se réunira, nous aurons une excellente solution multijoueur.
Plus d'entretiens avec Pixonic DevGAMM Talks