Pourquoi n’avez pas tous les « gros » jeux sortis qui utilisent l’unité?

Sur le plan pratique, architecture de l’unité a deux problèmes cruciaux pour la construction de grands jeux.

Du côté du tech, moteur de base de l’unité est en C++, mais la majeure partie des jeux de l’unité sont écrits en c# ou UnityScript JavaScript à l’identique de l’unité.   C# gère l’allocation de mémoire et de la désallocation pour vous, qui est une aubaine pour les simples mortels qui ne veulent pas s’inquiéter mal compter un pointeur et bleu-dépistage PC de quelqu'un.  Toutefois, le système automatique de la mémoire (connu en tant que le garbage collector) a la mauvaise habitude de coup de pied quand il se sent comme elle, introduire des pauses imprévisibles (parfois de mesure en secondes, au lieu de millisecondes).  Dans un genre d’action comme FPS, de course ou de sport, c’est une éternité.  Vous pouvez éviter le pire par une planification minutieuse et une utilisation prudente des actifs - mais c’est certainement un dis-incitatif pour les équipes de planification des grands jeux dans le sens de biens volumineux et coûteux.

Par ailleurs c# n’est pas aussi rapide que le C++ utilisé dans d’autres moteurs de jeu comme Unreal.  Les nombres réels sont difficiles à trouver car ils sont très situationnels, mais C++ se situe entre 15 % et 50 % plus rapide que c#.  Pour de nombreuses applications qui ne font la différence : mais c’est assez important pour un titre de bord saignement.

Sur le côté de la production, l’unité exige que chaque développeur localement recompiler tous les actifs et tout le code de jeu.  Si vous revenez au bureau après vacances une semaine d’et récupérer les données les plus récentes pour votre jeu de contrôle de code source, vous pouvez attendre assez longtemps pour l’unité de recompiler l’actif et le code.  L’unité a été travaillé là-dessus pendant un certain temps , mais les résultats ne sont toujours pas vraiment acceptables pour les jeux avec des bases de très gros atout (si rien d’autre, quand vous avez une équipe de 150 travaillant sur votre jeu et ils sont tous perdent une heure par jour à la fois, de construire vous êtes effectivement perdre un mois de travail tous les jours!)  Étant donné que l’architecture de l’unité n’est pas vraiment conçu autour de fermes de construction centralisée ou précuit actif il n’est pas un choix naturel pour les grandes équipes avec beaucoup de biens.

En outre, l’unité a seulement récemment a commencé à jouer gentil avec les systèmes de contrôle d’actifs professionnels comme Perforce, qui sont l’épine dorsale de la gestion d’actifs dans des projets de gros gibier.  Forcément, prise en charge est uniquement en ligne en 2013 et c’est encore un peu bancal.  Les fichiers .meta unité utilise pour suivre l’état de l’actif au fil du temps sont aussi difficiles pour les collaborateurs.  Plus la méthode préférée de l’unité des importateurs actifs (garder vos fichiers raw modèle et les textures dans le projet de l’unité) est vraiment irréalisable pour les grands projets où jonque aléatoire comme des couches supplémentaires de Photoshop, modèles de référence et tester le contenu apparaissent tout le temps.

TLDR : L’unité est un grand moteur, mais elle a évolué sur une communauté axée sur les petites équipes et des petits projets. Il est toujours de trouver son chemin lorsqu’il s’agit de performance lourds-fer et collections de gros atout.   Il peut rattraper, mais il faudra un certain temps.


Tags: Développement de jeux vidéo, Jeux vidéo, Unity (moteur de jeu)